累积流图
1. WHAT 实践简介
累积流图（Cumulative Flow Diagram）是敏捷项目管理中的一种面积图，可以用于表示任务在工作流程中不同阶段的变化，它也是敏捷迭代管理的重要工具之一。团队可以通过累积流图可视化当前任务进展情况，从而发现瓶颈，识别潜在问题。团队也可以通过累积流图跟踪工作流程中每个阶段中的任务数量以及每个阶段工作的持续时间。同时，累积流图可以帮助团队优化工作流程，确保任务以稳定的速度完成，并最终为客户交付卓越的产品。通过对任务进展情况的监测，团队可以分析当前工作流程的有效性并进行必要的调整。团队可以根据项目的需求，以每日、每周或每月的时间段在累积流图中调整对项目进度的观测。
对于 BeeArt V4.0 来说，累积流图是一个非常有效且使用最频繁的项目管理工具之一。累积流图可以将项目中潜在的问题以图的形式直观地暴露出来。
在 BeeArt V4.0 中，每个迭代周期为两周，项目成员会轮流作为 IM（迭代经理）这个角色，在当天结束时更新累积流图，并在每日站会时向团队呈现最新的累积流图，并通过识别团队当前遇到的障碍或困难来分析和推进问题被解决。此外，迭代经理角色的轮换是也是 BeeArt V4.0 上一个非常有效的实践，它可以让团队成员轮流地去更新累积流图，并持续关注项目进度。
使用累积流图的首要前提就是得确定项目上任务的工作流程。BeeArt V4.0 里的工作流程包括「待开始」、「开发中」、「测试中」和「已完成」四个阶段。然后，团队可以更具实际情况，选择一个合适的观测周期，如每日、每周或每月去记录每个阶段完成的任务数量，可以使用电子表格或其他跟踪工具来计算指定时间间隔内每个阶段的工作项数量。此外，可以使用类似 Google Sheets 或 Excel 等图表应用程序创建累积流图。
2. HOW 如何运用
2.1 观测指标
累积流图的一些指标可以用于观测任务在项目中随时间变化的情况:
- 进行中的任务（WIP）：指当前正在进行的工作量，通常位于“开发中”和“已结束”之间。如果临近交付日期，累积流图显示 WIP 水平很高，很可能意味着项目存在交付瓶颈或延期的风险。
- 交付时间（Lead Time）：从任务进入迭代到完成完成所需的时间。它包任务在工作流程中花费的时间以及工作流程之外的等待时间或延迟时间等。交付时间可用于确定工作流程的整体效率，并评估完成某一任务所需的时间。
- 循环时间（Cycle Time）：在进入工作流程后，任务从开始到结束所需的时间，不包括工作流程之外的任何等待时间或延迟时间。循环时间可用于确定工作流的效率并评估完成任务所需的时间。
- 吞吐量（Throughput）：任务在给定时间内完成的速率，通常以每天、每周或每个迭代来衡量。吞吐量可用于评估团队的生产力，并确定可能影响其有效完成工作项的潜在问题。
- 计划任务数量（Scope）：当前工作流程中的的所有任务，通常在每个迭代开始时会进行调整。
- 预计交付日期（Estimated Delivery Date）：任务完成并交付给客户所需的时间。通常基于多种因素，包括任务涉及的范围、团队的能力以及任何已知的限制或依赖等。
尽管一些其他的指标在 BeeArt V4.0 的累积流图中没有被使用到，但它们仍然很重要。团队可以根据项目实际情况选择合适的观测指标，进行有针对性的迭代管理。总的来说，通过这些观测指标，项目可以了解团队成员和任务的情况，并确定是否需要进行有针对性的改进。通过将关键的数据指标与迭代管理技术相结合，团队可以不断改进其工作流向客户提供更好的价值。
2.2 迭代速率与累积流图
迭代速率（Velocity）是根据迭代期间内完成的用户故事点数除以可用人天计算得出。在准备迭代任务时，我们可以根据历史迭代速率设置一个较为合适的目标速率，从而评估团队可完成的工作量以及预计交付时间。制定和跟踪团队迭代速率在每个迭代都非常重要，因为迭代速率本身就是一个很有效的迭代管理工具，在累积流图中的也有观察迭代速率的方式。
累积流图和迭代速率是通常可以一起用来跟踪项目情况。迭代速率衡量团队在特定时间内可完成的任务数，而累积流图显示了在特定时间段内每个阶段所完成的任务数量。通过结合累积流图和迭代速率，团队可以有效地监控任务进度，并识别可能阻碍完成任务的问题。通过查看累积流图上的斜率，可以确定每个阶段在不同时间段的实际速率和目标速率，从而评估工作效率和生产力，团队能够进行必要的调整，以确保项目按时交付。通过迭代速率，团队还可以更有效地管理其工作量，分配资源，并预测项目完成的时间等。因此，在敏捷迭代管理中使用累积流图时，迭代速率也是一个关键指标。
2.3 常见模式
累积流图中出现的四种常见模式是线性（Linear）、高原（Plateau）、曲棍球棒（Hockey Stick）和混乱（Chaotic）。理解这些模式并利用它们分析团队目前面临的问题是累积流图的最为关键的用途。一般来说，这些模式会在累积流图中一起出现，但是团队可以根据某一时间段出现的异常模式来分析问题和瓶颈，以下是每个模式的简要描述。
- 线性模式（Linear）是指随着时间的推移，在每个工作流程中，任务都处于稳定逐渐增加的模式，且不同阶段的增长速率几乎一致。这个模式可以表明计划任务在每个流程中都正常且有效运作，并以一致的速度完成。这通常是团队表现良好的标志，因为它表明任务按时完成，流程有效。但如果斜率在某段实践内处于下降状态的话，可能表明当前工作流程中的任务或整个团队遇到了与工作流程相关问题，如项目内的流水线或测试环境出现问题等，团队可以通过累积流图显示的瓶颈并根据项目实际情况定位和发现潜在问题，并进行有针对性的改进从而解决问题。
- 高原模式（Plateau）中，每个工作流程步骤中的任务数量在某一段内时间上没有变化。这不是一个乐观的模式，因为它表明任务在某一阶段的一段时间内的速率是零，项目上可能存在需要解决的障碍。出现这种模式一般来说会由两种情况导致：1.可能是由于一个很严重的问题，使得所有人都无法正常进行开发、测试等任务，所以任务会在工作流中一直停滞不前；2.也可能时由于一次漫长的假期，没有人在工作。总之，出现这个模式可能没有问题出现，也可能是由于重大问题导致的。
- 曲棍球棒模式（Hockey Stick）的特点是在初始阶段有相对稳定的增长，但在后期任务数量会急剧增加。这种模式可能意味着任务在工作流程的初始阶段被拖延或阻塞，但在后期阶段可能由于各种原因，使得任务涌入某一阶段。由于任务数量的快速增加，团队的工作量也会因此突然增加，这可能会对团队的工作质量产生影响。产生这个问题的原因可能是迫于交付压力，在临近交付日期前团队成员都有尽快完成交付任务的一致的想法，降低了开发任务或测试的质量。往往出现这种模式时，需要尽可能分析出产生问题的原因，从而避免再次发生。
- 混沌模式（Chaotic）下，随着时间的推移，每个工作流程阶段中任务的数量和速率的变化都没有明显的规律，表明项目没有按计划或规律以恒定增长的速度进行。造成这种模式的因素有很多，可能是由于需求不清晰、频繁的范围变更或无效的团队沟通等导致任务没有在与其时间内在工作流中变化，这可能会对整个团队的效率产生负面影响。
2.4 典型示例
事实上，累积流图可以通过分析之前提到的观测指标和常见模式来跟踪和评估项目的健康状况。一般来说，如果对这些指标和模式有一定的熟悉程度，项目管理者可以快速有效地根据累积流图定位和发现项目潜在的问题和瓶颈，当然这也是需要经过反复多次的刻意练习才能达到的程度。此外，由于各种因素，一个实际项目上的累积流图不会特别「好看」，可能是各种模式混杂而成。以下是六个常见的累积图的简单示例：
示例 A
示例 A 的问题主要在于越来越多的任务进入到「开发中」，且增长的速率远远高于「测试中」和「已完成」，而且可以明显地看出「开发中」和「已完成」之间的差距很大。在这个例子中，交付时间（Lead Time）会变得越来越长，提高了项目的交付风险。那么，造成这个问题的潜在原因是什么呢？在进行中的任务则没有稳定完成的情况下，越来越多的任务进入开发中，可能导致多人同时在多个任务上。如果当前团队处于扩大的状态且开发资源逐渐增加的时期，这可能不是一个主要问题。但如果开发数量保持不变，可能需要注意下是否每个开发都严格专注于一个任务上。
示例 B
与示例 A 相比，示例 B 中测试任务会完成地更好一点，因为「测试中」和「已完成」两条线线几乎重合，大部分任务处于开发阶段，而且开发任务不断增加积压，一直没有进入到「测试中」。示例 B 间接表明了开发团队的速率是稳定的，因为进入到「测试中」的任务数量以稳定的速率在增长。造成这个问题的原因可能是开发资源不足造成，如果开发人数不足，即使有更多的任务进入到开发中，开发团队也只能以相同的速率完成。在这种情况下，「测试中」和「已完成」阶段很可能会出现曲棍球棒模式（Hockey Stick），也就是在交付后期，测试的压力会急剧增加。如果是这个问题造成的，团队可以考虑增加开发资源，加快任务完成速度并减轻测试的负担。
示例 C
示例 C 的「已完成」这条线是最引人注目的，以阶梯式的形式增长。这张图一眼望去可能会觉得是测试人员的问题，因为很多任务都处于「测试中」的阶段，没有稳定地进入到「已完成」阶段。但如果进一步调查发现，更有可能是开发人员的问题。如果开发任务质量不高，在测试过程中会发现许多缺陷，这可能导致任务一直处于「测试中」或返工到「开发中」，所以可能会在某一阶段中停留很长时间。如果开发人员在「测试中」的工作还没有测试完成转移到下一个阶段的情况下，又继续开始了新的开发任务，那么会造成开发人员承受新任务和有缺陷的任务未完成的双重压力，这将会阻碍任务进入到「已完成」的阶段。如果新任务正在开发过程中，「测试中」的任务也返工，会造成一个开发人员工作到多个任务上的情况，那么某些任务在一定程度上会被忽视。这其实是一种很常见的情况，在 BeeArt V4.0 中的某些迭代内也发生过类似的场景。比较好的解决办法是严格根据工序将开发任务分解成多个合理大小的的可测试的任务，然后通过测试驱动开发确保每个任务的功能都正常工作且不会被破坏。这样可以很大程度上保证开发质量，减少返工率。
示例 D
示例 D 中展示的也是一种很常见的情况，它也对应于高原模式（Plateau）。在一段时间内，没有任务移动到下一个阶段。实际项目中应该都会出现这种情况，比如节假日，没有人工作在任何任务上，自然就会出现任务不增长的情况。然而，这种模式也可能表明项目出现了较为严重的问题，例如整个团队因测试环境失败或 CI / CD 流水线问题而停滞不前，使得所有人无法正常工作。因此，如果出现这种情况，可能是没有问题出现，也可能是出现了重大的问题。
示例 E
在示例E中，也存在一部分的平坦线，特别是当「测试中」和「已完成」完全平坦且重叠时，而「开发中」的任务不断上升。这里存在的问题可能是由于测试环境或开发用 CI / CD 流水线出现故障，导致没有任务能进入到「测试中」。或者是由于另一个更严重更隐蔽的问题导致：在「测试中」的任务数量没有任何增长的情况下，「开发中」的任务数量仍在继续增加。这其实潜在地表明了开发人员可能并不关心测试环境或 CI / CD 流水线的问题，而是继续开始新的任务。这也间接地说明了开发人员没有工作在优先级最高的事情上，以及不太关心团队基础设施。
示例 F
示例 F 中包含典型的棍球棒模式（Hockey Stick）的部分，在时间的后期，「测试中」和「已完成」任务数量的急剧上升。这种现象很可能是由于项目处于强烈的交付压力下，例如接近交付日期或上线日期，但仍有许多任务尚未完成。在这样的压力下，团队成员会有意地妥协测试标准，并将基本能工作的任务到「已完成」，从而导致了这样的急剧上升。这时候团队应警惕起来，因为降低交付质量会增加生产事故的可能性，并降低客户信心。
2.5 近乎完美的累积流图
一个近乎完美的累积流图可能会是什么样子呢？首先，图中没有任何负面的模式，如高原（Plateau）、曲棍球棒（Hockey Stick）或混乱模式（Chaotic）。其次，任务的测试和完成的增长速率可以和开发中的任务进度保持一致，即使计划任务（Scope）不断增加。但是，这样的图只能存在于想象之中，因为在实际项目中，是无法让任务在同一时间内经历工作流程中的所有阶段的。
3. BeeArt V4.0 真实场景
尽管我们认为每个人都已尽其所能地在 BeeArt V4.0 做出了最大的努力，但我们的累积流图仍有很大的改进空间。完美无瑕的累积流图比比皆是，但如果我们分享我们实际遇到的困难，对您来说可能会更有益和可信。很明显的是，BeeArt V4.0 的累积流图是一个能发现很多潜在问题和瓶颈的图。
我们可以根据之前提到的四种常见模式和示例来分析 BeeArt V4.0 的累积流图。例如，A 和 C 在「开发中」堆积了大量的任务，并持续了较长的时间，这在迭代后期必然会增加测试任务的工作量，增加了交付风险。在 B 和 D 中，在很长时间一段时间内，基本上没有任务能进入到下一个工作流阶段，这意味着项目在此期间没有任何进展。这可能是由于一个重大问题，阻止了所有人的工作；或者从好的一面来说，这可能是一个假期，没有人需要去工作。在 E 中，许多任务处于「测试中」且尚未完成，但仍然有更多新的任务进入到「开发中」。这对开发人员来说是个坏消息，因为在「测试中」中的任务还没有被标记为「已完成」时，开发人员仍然在开展新的任务，而不是协助完成测试工作。此外，「开发中」多了更多新的任务意味着一个开发人员必须同时处理多个任务，这对交付来说是不可取的。最后，F 也揭示了多任务处理问题。
4. 总结
总而言之，累积流图是一种很有效的迭代管理工具，可以帮助团队跟踪进度、识别瓶颈，并做出基于数据的决策以改进其流程。通过可视化任务在工作流程中的流转，累积流图提供了一个更为全面的任务进展视图，使团队能够识别潜在问题并进行有针对性的改进，以优化其工作流程。
5. 更多阅读
how-to-read-the-cumulative-flow-diagram-infographic
User Stories Applied - Mike Cohn
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 350394277@qq.com
