看板的度量工具 ：同其数器，壹其度量

度量和管理

彼得德鲁克说“没有度量就无法管理”，是的，听起来很有道理，没有度量，没有数据，我们怎么知道在哪儿改进，改进的结果是什么。但是同时还有一句话是“度量什么，你就会得到什么，但一定不是以你期望的方式”，这是因为一旦把度量设为目标，度量结果就容易失真。那么我们到底还需要度量吗？答案是YES，我们依然需要度量，只是需要更谨慎和科学的度量方式，以及如何使用度量的结果。在看板的使用中，我们有一些工具用于帮助我们度量一些好的指标，并帮助管理我们的项目，当然这里所谈的这些工具是基于看板的。

燃尽图

Scrum中经常被使用的一个工具。横轴是时间，纵轴是剩余的工作量（单位是故事点数或者人天，小时数等）。纵轴的含义是一个很有意思的概念，就是“剩余工作量”，这个概念揭示了在daily的同步中我们关心的重点不再是“做了多少”，而是“距离完成剩余多少”。这个改变意义很大，是从关心完成多少任务到完成目标的转变。如图所见有一条理想的“Baseline”的线，它是理想状况下每天剩余的工作量。而另外一条线是每天实际上剩余的工作量。

Sprint Burndown Chart的概念来自于飞行员（Jeff Sutherland就是一个飞行员）试图降落飞机的场景。飞机需要知道目前的高度，到跑道末端的距离和下降率。一旦降落到跑道末端之外，飞机就会出事故。

这个场景和我们一个迭代的开发非常相似。具体到某一天，我们需要知道我们所处的高度（Reminding Effort），到跑道末端的距离（Sprint的剩余时间）和下降率（斜率），一旦Sprint结束，燃尽曲线还不能归零的话，说明我们这个Sprint的目标没能实现，我们的commitment 失败（至少最后一个US）了。所以在Scrum的实践中很多团队会使用燃尽图。一旦发现燃尽图实际的曲线跟理想曲线有了较大的偏差就需要采取行动。

在实际使用中，燃尽图需要有人手工维护（物理看板）或者准确的更新每个任务的状态（电子看板），否则燃尽图就不能反映出团队真实的状态，也就是这张图失去了意义。我们能看到一些奇奇怪怪的燃尽图，比如陡升陡降这样的，除了一部分确实反映了团队的问题，比如陡升说明团队一开始没有能识别一些任务，有很多就是状态更新不准确造成的。

 

累积流图

累积流图是精益看板中较长使用的一个工具。为了方便理解，我做了一个excel记录一段时间内的任务数量分布。

 

	Backlog	Dev	Test	Done
day0	5	0	0	0
day1	5	2	0	0
day2	5	2	0	0
day3	5	3	2	0
day4	3	3	2	0
day5	3	3	1	1
day6	5	3	3	2
day7	6	3	2	3
day8	5	1	2	5
day9	6	3	0	5
day10	5	2	1	5
day11	5	4	3	5
day12	6	4	2	6
day13	5	2	2	8
day14	5	3	2	10
day15	5	3	2	10

 并根据这个记录做出下面的累积流图。

累计流图的绘制方法比较简单，X轴是时间，Y轴是需求/任务的数量，每一条色带代表看板上的一列，所以每一条色带的宽度就表示在这个状态上一个具体时间点有多少任务。最下面“Done”这个曲线可以当成燃起图来使用。理想状态是这个图是平滑上升的，一旦不是这样，就意味着项目中存在问题需要我们去解决。

上面所示的几个指标通常被用于看板的度量，这些度量指标可以帮助我们发现问题，指出解决问题的方向。

1. Lead Time。 就是从需求进入backlog list 到交付的时间。这是一个非常重要的指标，因为它是用户可感知的，Lead Time越短意味着团队可以越快的把需求交付给客户。

2. WIP。在上图中是Dev的宽度和Test宽度之和，具体含义见文章。如果WIP变得很宽，说明团队在当前任务没有完成的情况下又拿了过多的任务，需要考虑限制在制品，否则会减慢整体的需求吞吐量。理想情况WIP应该是接近一个常数。

3. Cycle Time。这是从需求进入开发到交付的时间。同样是一个很有意义的一个指标，

4. Delivery Rate。交付速率，或者说是需求吞吐率。角度越大，我们的交付速率越高，反之则交付速率下降。

5. Backlog。也就是待办列表。

 

我们来看看上图可以看出哪些问题，当然这只是一个示例，提示我们可以从哪些角度去解读累计流图。

1. Day1到Day3，开发进程平稳，backlog增加，开始有积压。

2. Day3到Day5，WIP数量下降，需要检查是否可以拉过去更多的任务；

3. Day11的WIP很多，需要检查在day11是否有任务堆积，WIP限制是否合理。

4. Day9的WIP很少，但是Day8到Day11完成数量没有变化，Delivery rate为0，相关工作停滞，SM/PM需要跟团队一起寻找RC并协助团队移除障碍。

5. Day1进入的需求Lead time到Day13，而Day5进入的需求Lead time是到Day14，需要检查Lead Time优化的原因并固化好的实践；

6. Cycle Time从Day3到Day8变化为Day6到Day13，速率变低，需要查找障碍；

 

这些工具尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性。实际上不使用这些工具的团队有很多，用了工具用不好的也大有人在，看板本身就已经是把任务的状态可视化出来的一个工具了，瓶颈和问题大可以从看板上读出来并给予解决。然而还来学习这些工具的目的一是通过理论更好的了解流程框架的定义，因为工具一定是为了解决问题出现的，是按照其为之服务的框架来设计的，所以从某种意义上来说，工具也是其理论体系的一种显式化展现；二是丰富我们的工具箱，在需要的时候，我们可以拿出恰当的工具来解决问题。

最后，数据本身不能说明问题，趋势才有意义；考核团队虽然也有意义，但从图表中得出行动项才更有意义。发现瓶颈，消除瓶颈，再寻找下一个瓶颈！关于瓶颈的消除，TOC是威力强大的武器，当然这是另外一个话题。

 

参考文章：https://goois.net/43-sprint-burndown-chart-a-scrum-book.html