累积流图 CFD

如果你负责向你的客户交付结果，并且你还没有使用过累积流图（cumulative flow diagram - CFD）管理项目或者服务的开发，那么请你仔细看看这个 工具。你很快就会每天都希望看到它。

一项工作何时才算完成？只有被交付到客户手中，才算完成，因为只有这时我们才能从中收取费用。

正因如此，敏捷团队用交付给客户的功能/用户故事的数量来度量项目进度。最初，Scrum开始使用燃尽图来展现完成剩余待办工作所需的小时数（或故事点数）。之后燃烧图也开始被使用。这些图将团队每天完成的功能数量绘制了出来。

这些信息连同速率数据可用于展现某个Sprint/迭代的完成度。

然而，仅考虑到已经完成的工作还不够。

里特定律（ Little’s law ）告诉我们交付时间（Delivery time）依赖于在制品数量（Work In Progress, WIP）。WIP是指所有已经初始但还未完成的工作，例如：所有在分析（Analysis）与完成（Done）之间的工作。

因此，必须要首先留意的就是WIP。

如果WIP增加了，你的交付日期就会有风险。

因此，用更短的Sprint待办列表/迭代范围（批量）尺寸比长待办列表好。此外，保持更少的WIP数量可以降低由任务切换带来的花销。

缩小批量尺寸提高交付速度。

作为一个好的经理，不仅要知道什么是正在被开发的工作，你还需要了解这些工作的状态，哪些工作项正处于困难之中，哪些有缺陷，以及哪些阻碍了其他工作的进行。你的工作室确保清除障碍并使工作流程持续顺畅。

根据约束理论（ Theory of Constraints, ToC），每个系统有且只有1个约束（瓶颈）。所以你必须：

• 识别约束
• 决定如何消除约束
• 使所有其他的过程遵从于第2步的决定的开展
• 如果在第2、3步之后，需要更多产能提升，要放宽约束
• 回到第1步

如何才能识别出工作流程中的瓶颈？

根据瓶颈法则（Law of the bottleneck），你会在吞吐量最低的位置找到瓶颈。通常，在这个位置之前会有一个队列，并且在那个环节之后环节的效率并不高。例如：一个在高速路上的限高梁、高峰时段的立交桥或者机场的安检点。

回到我们软件开发的流程上，我们可以将其中每个不同环节（分析、实现、测试、部署、完成）的工作项数量用不同颜色的带状区域可视化出来。

 

现在观察一下，是否有一个区域在变窄，同时在流程中相对于这个环节之前的环节正在变宽（说明队列正在增长）。

如果你看到了这种情况，就可以用上面提到步骤来解决瓶颈。

要留意的是，当我们看到了一个瓶颈，我们会本能的认为，我们需要更多资源。但是，这通常是代价最大的方法，并且通常不是最好的解决方法。关于如何消除瓶颈的详细内容请见David Anderson的《看板方法》一书的第17章 瓶颈与持续可用。也许你还会很喜欢《Esteban, the Bottleneck》的故事。

在《Cumulative Flow Diagram》中，Pawel Brodzinski 展示了许多其他的当你使用CFD的时候可能会发现的情况。

接下来，

累积流图是一个实践工具，可以帮助我们看到WIP的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。

手工绘制一幅CFD需要专注和良好的数字表现技能。尽管如此，大多数看板方法工具都会自动绘制CFD，你还可以选择需要跟踪哪些环节。

对于使用传统管理方式的组织：

如果你正在尝试按照计划来跟踪进度并基于项目的关键路径（里程碑）来估算最终时间，使用CFD依旧对你有用 ：

• 在得到下次项目状态汇报之前识别延期风险
• 找到工作流程中的障碍并在它们影响到项目计划完成之前进行消除
• 完整的看到当前工作的状态以及项目的步调

此外，绘制CFD所需的数据也很简单，只有工作项（任务、需求、故事、单据、事故）的状态和已经处理的时间（前置时间，lead time）。团队协同工具通常都会保留这些数据。当然，保证数据的正确不被作假是至关重要的。