前言
如今Scrum之花正如火如荼，开遍大江南北。
然而实施Scrum却是一个英雄之旅。
它需要团队高成熟度，业务市场高稳定度，以及个人和组织的高承诺度。
任何一个因素不够稳定，就需要在这个维度上放上此领域能力非常强的角色做支撑。任何一个角色的能力有所欠缺，后面的风险和问题就会成指数级增长。
Scrum Master解决团队成熟度不够的问题。
经验丰富的大PO解决业务市场稳定度问题。
对技术精通和业务经验丰富的工程师团队解决承诺问题。
曾经参加过一次Globle Scrum Gathering 的 Scrum Master Clinic 诊断室。当时我正在一个Customer Focus团队处理客户问题，客户问题是随机到来的，团队的目标是高效的处理并解决客户问题，通过重现客户问题、找到问题根源、产生解决方案，通过热补丁方式实施解决方案，测试热补丁，发布热补丁给客户，达到让客户满意的服务效果。
我向这位敏捷教练讲述了我们的业务特点以后，她笑着说，你们并不适合做Scrum，而更适合做Kanban。回去没多久，我们的Customer Focus团队就开始使用Kanban的方式进行用户问题的排队和处理。团队自己认领任务，解决问题，并提交完成。
Kanban
Kanban是一个不同于Scrum的存在。它产生于精益生产思想。
如果你公司的业务遇到以下情况超过5个，你可以考虑Kanban的方式：
计划总是跟不上变化
随时有高优先级的任务插进来
技术难点造成细节不可预知，无法准确的估计和计划
范围总不能有效的控制
节奏经常被打断
中途发生的任务造成迭代内任务总是无法完成
新的迭代因为前面任务的阻塞造成没办法开始
Kanban和Scrum的共同点都是：尽早交付高价值、高效协作、自组织、持续改进。
只是理论背景和方式有不同。
今天介绍最重要最基本的理论核心，利特尔定律（Little's Law）。
如果不懂利特尔定律，你所实施的Kanban有可能是只有空壳而没有灵魂。当然也不是绝对。
利特尔定律（Little's Law）
利特尔定律是以麻省理工学院教授约翰·利特尔的名字命名的，他于1961年首次用数学方法证明了该定律。
L = λ W
L：队列中的个数
λ ：吞吐量（到达率和离开率）
W：在队列中平均停留时间
这个定律后来被运用于所有跟排队相关的实践中。它强大在于简单，但是却可以应用于千万种场景，并且在这三个值中两个值稳定可知的情况下，能够得出第三个值的最佳预测。
美国国防部曾经将利特尔定律应用于的B-2轰炸机（隐形轰炸机）的使用。当时的B-2轰炸机是核威慑的重要组成部分。虽然数量不多(只有20个)，但这些设备必须处于最佳状态，随时可以使用，而且还要记录正常飞行时间，可用来培训飞行员或进行常规测试。
不幸的是，为了保持隐形状态，这些复杂的飞机必须在一定的飞行时间后(或者在遭受损伤后)进行大量的维护。这种维护可能需要18到45天的时间，因此在使用和维护之间产生了微妙的平衡。
通过对飞行计划的观察和分析，计算出在任何时间都需要有三架B-2轰炸机处于维修状态。轰炸机进入维修区的速度也被计算为大约每7天一次。所以:
L = WIP(维保数）= 3
λ =到达/离开率=每7天1次= 1/7天
平均维修时间= ??
你算出来了吗？
平均维修时间= L/λ=21天
所以，对于20架数量有限和维护复杂的B-2轰炸机，要维持正常使用，维修时间要平衡在21天一架的速度。这对于管理来说，很容易判断出，如何通过正确的投入资源和改进提升效率。改进目标就是将轰炸机的维修时间保持在21天以内一架的速度。
前面说了，一般维护一架飞机需要18到45天的时间，如果所有维护时间都压缩到18天，会造成资源浪费，和工程师疲于奔命。21天是最好的平衡点，是节奏，也是改进目标。
Google和facebook是如何使用利特尔定律来实现业务上的成功的？
L =正在使用该服务的人数
λ =这些人到达站点的速度
W =他们使用该服务的时间
作为热门的搜索引擎，谷歌的到达率非常高，但是他们的用户不会停留太久。这就是为什么谷歌的收购和发展的重点是让用户停留更久更久，以进一步增长。
他们的“λ”已经很高，所以现在的注意力集中在“W”。
与此同时，Facebook正好相反。它们的到达率要低得多，但是它们的会话时间要比谷歌高得多。因此，他们在发展和收购方面的重点将更多地放在“λ”上，而不是“W”上。
提高“λ”或者“W”，维持另外一个已经很高的值，可以最终提升“L”正在使用的用户数。
运用利特尔定律对Kanban进行度量
实施Kanban有三个原则：
工作流：可视化当天的任务，展示全局信息
WIP（Work in progress）：限制正在进行的工作量
提高流动性：当一个任务完成后，下一个高优先级的事情开始
Kanban源于精益思想，而精益思想专注于减少浪费，提高效率，全局视角，尽可能快的交付有价值的产出。
一方面要以紧迫合适的节奏来适应不断变化的市场需求。
另一方面要减少赶工和疲劳所造成的质量问题。
因此，利特尔定律就和Kanban结合起来了。
Kanban有两个度量值：
Lead Time：客户视角，从端到端的时长
Cycle Time：价值流内的每个阶段的时长
我们可以通过Kanban计算出三个度量值，首先要把利特尔定律的三个值和Kanban的度量值之间建立联系：
L = λ W
L：队列中的个数=》WIP
说明：这里的WIP可以理解为整个端到端的所有在Kanban上流动的卡片，这个维度上计算出来的就是端到端的吞吐量和发布周期；也可以是一个队列的WIP，这样可以计算出单个任务在该队列的停留时间和拉动频率。
λ ：吞吐量（到达率和离开率） =》Throughput 用户需求到来的频率（需求发布的频率）
比如：每5天来一个用户需求， λ = 20%
比如：每一个月（20个工作日）发布10个用户需要求， λ =10/20=50%
W：在队列中平均停留时间=》Leadtime：一个用户故事端到端的时间
这里以端到端为例：
吞吐量：每5天需求采集一次用户需求，每次产生10个用户故事，吞吐量为10/5=2。
通过经验观察，一个开发团队从端到端交付一般要3周（一周5个工作日）， LeadTime为3*5=15天。
WIP=2*15=30，代表按照当前团队能力在Kanban上流动的用户故事为30个。
公式变换如下：
WIP = Throughput x Lead Time
Throughput = WIP / Lead Time
Lead Time = WIP / Throughput
WIP在制品、Throughput生产量、LeadTime交货时间
Throughput = WIP / Lead Time
举例：
通过经验观察，一个开发团队从端到端交付一般要3周（一周5个工作日）， LeadTime为3*5=15天。
通过团队自主拉动任务，目前Kanban上正在流动的用户故事为15个。
吞吐量=15/15=1
代表需求如果按照一周（5个工作日）为周期获取需求，要符合团队的处理团队速度，目前只能每周往需求池加入5*1=5个需求。
Lead Time = WIP / Throughput
举例：
PO或者客户希望直到目前团队能力下，团队实现15个需求的端到端发布，需要等多长时间？
WIP值一定的情况下，WIP=15
如果保持Troughput为1，代表每周可以处理5个需求，3周时间可以完成15个需求的梳理。
发布15个需求LeadTime=15/1=15天=3周
但是如果一周就给团队推送15个需求，代表Troughput=15/5=3
发布15个需求LeadTime=15/3=5天=1周？？？
单纯的增加需求进入队列的速度就可以代表Troughput？No。
这时候整个Kanban的薄弱环节——瓶颈，就起作用了。所以，平时在测量的时候注意测量每一个环节的Cycle time可以帮助提升Kanban的整体流动速度Troughput。
而且，如果瓶颈不在需求这个地方，而在其它地方，增加需求的进入量，还有可能让发布周期长于3周。
为什么时间更长了呢？ 因为超出团队的能力，造成一些浪费和阻塞。就好像堵车的道路前进更慢。
利用利特尔定律为团队改进制定目标
一般交货时间Leadtime就是我们的市场目标。要有效运用利特尔定律，需要更好的预测另外两个值。
WIP在制品如何测量？
首先得要知道每一列的WIP值如何计算和预测？
每一列得WIP=该项任务类别可用资源的最高能力。
比如，每一项任务估时为4小时。每个人每天可以处理1~2个任务。团队有两个可用资源，这一列任务的WIP=2*2=4
按照这个规律，计算出所有任务列的WIP，加起来就等于总的WIP：在制品。
听起来有点道理，是不是细想还是觉得哪里怪怪的？
我们再进一步分析，Kanban里面有三个基本元素，Todo，Doing，Done：
思考一下：
是不是Todo、Doing、 Done都应该有WIP？？
也许你已经有答案了，如果还没有想出来，没关系，文章后面会有答案。
接着往下讲。
然而，实际工作中，我们的Kanban并没有这么简单，而是这样的：
像上面的图，有很多工序流程，每一个流程都分为Doing，Done。
Todo去哪里了？
为了避免Kanban太长，Todo被简化了，和上一个工序的Done重合。也就是上一个工序的Done就是下一个工序的Todo。
是不是Todo、Doing、Done都应该有WIP？
答案是，不。
既然WIP叫在制品，Working in Progress，那么它就只有Doing计算WIP才有意义。
因此，我们首先要识别出Kanban上每个工序到底是Doing还是Done，还是Todo。
只对Doing状态的列计算WIP。
而Todo，Done状态的列，我们根据需要和重要程度进行增减。
这样计算出来的所有Doing状态的任务栏WIP之和才是准确的端到端在制品度量值。
得到准确的WIP，比如WIP=15。
Throughput值如何测量？
首先可以通过观察测量，如果团队保持纪律，按照WIP规则进行拉动任务，通过一段时间可以看到团队的平均Throughput值。
其次也可以通过瓶颈来计算Throughput值，瓶颈在需求设计，还是在开发实现。就是看一个用户故事在哪个阶段停留时间更长。
如果瓶颈在需求设计，那么重点关注需求设计在5天内的处理速度，就是端到端Throughput值。
依此类推，如果瓶颈在开发实现，那么重点关注开发团队在5天内的处理速度，就是端到端Throughput值。
Lead Time = WIP / Throughput
通过WIP和Throughput的计算，可以预测出端到端交付的时间。
也可以通过提升瓶颈的速度，来缩短交付时间。
当然实际工作中还是要运用系统思维。
