累积流图让价值流动
什么是累积流图 ？如果说看板方法是将价值可视化，那么累积流图就是辅助看板方法将价值度量化的一种实践工具。使用累积流图能带来什么？书里和网上有很多总结，在这里我想结合自己的实践经验来与大家分享累积流图使用过程中到底给我和团队带来了什么。
一、迭代过程中呈现的状态更加清晰。
在使用累积流图之前，各个团队在迭代过程认知上不是很统一，比如一些团队会划分为：立项、开发、测试、验收、发布；而有些团队会划分为开发、测试、发布，并且每个团队对每个阶段的准入准出的条件可能也不是一致的。在使用了累积流图后，由于累积流图的数据是从禅道的电子看板获取，而禅道上的电子看板已经对迭代过程进行了较明细的划分（已立项、研发中、研发完毕、测试中、测试完毕、已验收、已发布），并且阶段跟阶段之间也都是根据任务状态的更新而改变，所以各阶段流转更新更加明确，对团队之间的阶段认知也能保持一致。
图1
二、将需求价值度量化
使用看板（无论电子看板还是物理看板）是将需求流转过程可视化，但是看板也会有它的局限性，看板只能反映需求当前实时性，无法追溯无法分析问题，而累积流图能够反映整个交付过程，并且是可量化的用以辅助项目经理来对交付过程进行管理和分析。
图2
如上图所示，我们能通过累积流图看到每天每个阶段在制品变化情况，从而根据在制品数量以及斜率变化情况去分析迭代过程中的风险在哪里，瓶颈在哪里。
三、风险识别
当然我们之前用的燃尽图也是能够识别风险，但是燃尽图识别风险会存在一定的偏差，这是因为燃尽图准确性取决于任务估时，工时依赖于：需求数量，需求颗粒度，预估偏差，这三个都会影响燃尽图中预估工时的评估，需求的拆分粒度越小则越能反映真实的状况，但有时候拆分和预估并不一定准确所以会造风险暴露失真。那使用累积流图就不会存在这种问题。因为累积流图是需求状态的累积流转，如果需求流转顺畅，每个阶段平稳爬升，每天都有累加，阶段与阶段之间面积逐步变窄，如图：
图3
而一旦流转不顺畅则就会出现阶段性需求堆积，爬山缓慢甚至是停滞，这个时候就会出现项目风险，我们就要去分析到底是什么原因，如图所示：
图4
图中圈出来的就是一个明显的停滞状态，这时候就要第一时间去分析到底出了什么问题，可能是需求过大，可能是技术瓶颈，可能是人员负荷过重等等。
四、瓶颈识别
众所周知不管多大规模的团队，都是由人组成的，而人处理事情的精力是有限的，到一定程度就会出现瓶颈，而项目管理中很重要的一环就是发现瓶颈解决瓶颈提升团队效率，那该如何做呢？累积流图因为是需求度量工具，自然就能通过数据算法来进行计算。在这里要引入几个概念：
吞吐率（Throughput），（如果对于吞吐率不好理解的话，可以用更通俗的一种说法来代替，那就叫产能）。一定时间内完成的需求数量。比如：1个/天
在制品数量（WIP），从广义上可以理解为进入迭代后到交付之前被处理中的需求数量；从狭义上可以理解为迭代过程中每个阶段里还未流转到下一个阶段的在处理中的需求数量。
另外再讲下里特定律，里特定律源自排队理论，是IT性能建模中常被使用的定律，一句话就能概括叫：交付周期依赖于在制品数量（假设团队吞吐率/产能稳定），看起来好像这是个常识性，但是深入到实际工作中我们会发现经常有吊诡的事情发生：
比如：为了提升效率，我们会让开发或者测试同时并行多个任务，因为潜意识里我们会觉得并行是提升效率有效的办法，但是按照里特定律说的，交付周期依赖在制品数量，你同时并行多个任务势必增加了一个阶段周期内的在制品数量，那大家仔细观察会发现在这过程中其实要同时应付多个任务，任务间上下文的切换会占用相当的额外时间，效率不升反降。
再比如：产品经常会为了冲业务迭代多安排些需求，总觉得团队加加班总能做完，但其实就像里特定律说的，交付周期依赖于在制品数量，你的数量增加了，但是交付周期一定的情况下你的团队吞吐率（产能）必须要增加才能吃的下，但是每个人的精力是有限的，团队产能是一定的，你是无法突破这个规律的。
详见公式：
交付周期（T）=在制品数量（WIP）/吞吐率（Throughput）
通过里特定律的公式我们就可以去计算团队整体的吞吐率情况，或者某一阶段的吞吐率情况是怎么样的，它能够开展的需求任务到底是多少，一旦超过那么就会产生瓶颈，我们需要为团队保持平衡。
以上是引入累积流图能够给我们带来的价值，我再来谈谈实际应用过程中的体会：
一、累积流图较燃尽图更加的直观
这里没有贬低之意，燃尽图当然是很好的度量工具，只是燃尽图一个是我上面说的准确性取决于需求数量，需求颗粒度，预估偏差，另外我们现在的燃尽图是任务工时燃尽图，并不是需求故事点数的燃尽图，所以不熟悉团队的人乍看燃尽图很难看出目前迭代过程到底怎么样，处于哪个阶段。而通过累积流图我们就能更加直观的反映迭代过程和状态，比较明显的就是在周会上大家都能根据累积流图状况更多的提出自己的问题或者建议。
二、测试阶段经常迅速爬升
基于现状我们基本上都是固定一个或几个提测时间节点去开始测试，而一般测试阶段开始的都比较靠后，所以一旦前置环节（开发）或者中间环节出现什么问题（一般是测试环境不稳定问题），往往就需要测试经常加班去测试把前面的补回来。很少见到正常爬升最后验收上线，总是通过短时间加班增加产能提升斜率，这其实很不健康，对测试的体验也很不好。一定要多增加测试自动化和单元测试，尽量测试环节前置，不要把风险放到最后。
三、需求颗粒度问题
这是一个一直被pm和团队诟病的问题，需求颗粒度不细，不能提供mvp给团队，不管是使用燃尽图还是累积流图或者其他的一些项目管理度量工具，总归会产生偏差，我们的目标是每天都能看到状态更新，但是如果颗粒度过大，那就会好几天状态都不变，图上就会反映出来一直是停滞，这样就会失去它的价值。所以我们效能改进团队一直在进步一直在努力发现团队瓶颈和提升团队效率，产品侧的能力也要跟着去提升，不应该只是停留在业务能力的提升，身为产品经理还应该提升自己的产品规划能力，以及对于团队产能效率的了解，两边相辅相成才能效率价值最大化。
四、商务团队吞吐率情况
虽然基于需求粒度问题，对计算吞吐率有一些影响，但是从3月开始使用一直到目前12月，我还是去算了一下商务团队整体的一个吞吐率，商务整体来说，基本上团队吞吐率在1.5个/天，也就是每天能交付（从研发测试到上线）1.5个需求，按照我们目前一个月一个发布窗口（也就是整个交付周期差不多20天）来看，以目前商务的人员配置情况，可交付的需求数基本上在30个左右（当然还要具体看颗粒度大小），如果超过30个基本上就风险比较高了，开发测试瓶颈（尤其是测试）就会凸显的比较明显。也希望这能给产品侧同学一个参考，在后面规划需求的时候要考虑团队能力量力而为，切莫杀鸡取卵。
以上就是我对累积流图的一些认知以及使用过程中的体会，其实不管是用什么工具，使用什么方法，项目经理还是要牢记我们的责任和使命：发现问题，暴露问题，提升效能。切记项目经理的价值取决于团队的价值，只有团队更好了，项目经理才能好。
