Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
累积流图（CFD）通过可视化系统中的工作流来帮助监视工作流程。 本文介绍如何使用累积流动图 (CFD)、周期时间和提前期来识别问题并提高工作流效率。
- 若要设置或查看一个CFD，请参阅 “查看并配置累积流图”。
- 若要向仪表板添加前置时间或周期时间控制图，请参阅 “前置时间和周期时间”小组件。
- 若要设置或查看一个CFD，请参阅 “查看并配置累积流图”。
- 若要向仪表板添加前置时间或周期时间控制图，请参阅 “前置时间和周期时间”小组件。
连续流CFD是遵循精简流程的大多数团队首选的图表。
但许多团队将精简做法与 Scrum 或其他方法相结合。 他们在迭代或冲刺期间使用精简做法。 在这种情况下，关系图看起来有点不同。 它展示了两个额外的内容，其中连续流动图（CFD）是大多数团队在遵循精益流程时的首选图表。
但许多团队将精简做法与 Scrum 或其他方法相结合。 他们在迭代或冲刺期间使用精简做法。 在这种情况下，关系图看起来有点不同。 它显示出两个额外且有价值的信息点，如下一个图表所示：固定期限差价合约（CFD）。
连续流CFD
展示抽象连续流CFD的图表。标签指出前置时间、循环时间、正在进行中的工作以及处于各种状态的项目。
此固定周期的CFD显示冲刺已完成。
顶部行显示冲刺的设定范围。 由于工作需要在最后一天之前完成，关闭状态的斜率可以显示团队是否按计划进行。将此视图视为燃尽图。
在图表中，该过程的第一步位于左上角区域。 最后一步位于右下角区域。
已完成冲刺的固定期差价合约
图表指标
CFD 显示一段时间内按状态或列分组的工作项计数。 跟踪的两个主要指标是周期时间和交付周期。 从图表中提取这些指标。
指标
定义
周期时间1
通过单个进程或工作流状态移动工作所需的时间。 测量从一个进程的开始到下一个进程的开始的长度。
交货周期1
对于连续流过程：从发出请求（例如添加一个提议的用户故事）的时间到该请求完成（已关闭）的时间。
*对于冲刺或 fi 对于连续流过程：从发出请求的时间（例如添加建议的用户情景）到该请求完成（已关闭）。
对于冲刺或固定时间段的过程：从任务开始到完成的时间（例如，从活动状态到已关闭状态的时间）。
正在进行的工作（WIP）
正在进行中的工作量或工作项的数量。
范围
给定时间段内投入的工作量。 此指标仅适用于固定周期进程。
1 使用分析数据的CFD小组件和可以从团队积压或看板中查看的内置CFD，都不提供离散的提前期和周期时间值。 但是，前置时间和周期时间小组件 确实提供这些值。
潜在顾客时间或周期时间与 WIP 之间存在明显的关联。 更多的 WIP 会导致更长的周期时间和更长的交货时间。 相反，同样正确——更少的WIP可缩短周期和交货时间。 当开发团队专注于更少的项目时，他们能够缩短项目周期和交付周期。 此关联是您在用于跟踪和管理工作的看板上设置WIP 限制的关键原因。
工作项计数显示给定一天的总工时量。 在固定周期的CFD中，此计数的更改意味着该时间段的范围更改。 在连续流CFD中，它显示给定一天内在队列中和已完成的总工作量。
将工作划分到特定的看板列中，可以显示流程每个区域的工作量。 此视图可深入了解工作进展顺利、存在阻塞的位置，以及未完成任何工作的位置。 很难理解数据的表格视图，但视觉对象CFD可帮助你查看工作过程中发生的情况以及原因。
确定问题并采取适当措施
该CFD提供下列问题的答案。 根据答案，可以调整流程以推进工作流通过系统。
团队是否会按时完成工作？
此问题仅适用于固定周期的 CFD。 可以通过查看看板最后一列中的工作趋势（或进度）来获得了解。
在此方案中，可以考虑在迭代中减少工作范围。 如果显然工作进展不够快，那么采取这样的行动是适当的，假设它仍然以稳定的速度进行。 此方案可以指示工作被低估，并应纳入下一个冲刺计划。
但是，工作没有快速完成可能还有其他原因。 可以通过查看图表上的其他数据来确定这些原因。
工作进度如何？
团队是否以稳定的速度完成工作？ 一种方法是查看图表上各列之间的间距。 它们与彼此的相似或统一距离是否从头到尾？ 有哪些列在多个连续天数内显示数据趋于平稳？ 是否有任何东西看起来凸起？
Mura，或不均匀，是指平坦线条和凸起的精益术语。 Mura 意味着系统中的一种浪费（Muda）。 系统中的任何不均匀性都会导致计算流体动力学中出现突起。
监视平面线和凸起的CFD支持约束项目管理过程理论的关键部分。 保护系统中最慢部分的做法称为鼓-缓冲-绳过程，并且是工作计划方式的一部分。
两个问题在视觉上显示为平线和凸起。
当团队没有定期更新其工作项的状态时，会出现平线。
用于跟踪和管理工作的开发板提供了将工作从一列转换到另一列的最快方法。
当一个或多个流程的工作花费的时间比计划长时，也可以显示平面线。 平面线显示在系统的许多部分，因为如果只有一个或两个部分有问题，你会看到一个凸起。
平线
当工作在系统的一部分积压而未能在流程中顺利通过时，就会出现积压现象。
例如，当测试需要很长时间，但开发需要更少的时间时，可能会发生膨胀。 结果是工作在开发阶段累积。 Bulges 表示后续步骤存在问题，不一定是发生膨胀的步骤。
凸起
如何解决流问题？
可以通过执行以下作来解决缺少及时更新的问题：
- 举行每日例会
- 举行其他定期会议
- 计划每日团队提醒电子邮件
系统性平线问题表明一个更具挑战性的问题，尽管这些问题很少见。 平面线表示整个系统的工作已停止。 根本原因可能包括以下问题：
- 进程范围的阻塞
- 进程花费很长时间
- 工作转移到未在工作板上记录的其他机会
系统平面衬线的一个示例可能发生在特征CFD中。 功能工作可能需要比用户情景工作更长的时间，因为功能由多个故事组成。 在这些情况下，要么预期到斜率（如前面的示例），或者问题早已众所周知，团队已经提出了这个问题。 如果这是一个已知问题，则问题解决超出了本文的范围。
Teams 可以主动修复显示为CFD浮出水面的问题。 适当的修补程序可能取决于发生膨胀的位置。 例如，假设在开发过程中出现膨胀。 可能会发生膨胀，因为测试花费的时间比编写代码要长。 测试人员可能还会发现大量 bug。 当开发人员不断将工作转换回开发人员时，开发人员会继承越来越多的活动工作列表。
有两种可能简单的方法来解决此问题：
- 将开发人员从开发过程转移到测试过程，直到消除膨胀。
- 更改工作顺序。 具体而言，将可以快速完成的工作与需要更长时间才能完成的工作交织在一起。
查找消除凸起的基本解决方案。
注意
由于各种方案可能会导致工作不均衡地进行，因此必须对问题进行实际分析。 CFD可以告诉你存在问题。 它还可以大致告知问题所在位置，但必须进行调查才能解决根本原因。 本指南提供了解决特定问题的建议作，但解决方案可能不适用于你的情况。
范围是否发生了变化？
范围更改仅适用于固定周期 CFD。 图表的顶线指示工作范围。 冲刺预加载了第一天要完成的工作。 对顶层线路的更改表示工作量的增加或减少。
在某种特定情况下，无法使用CFD跟踪范围更改。 当在同一天添加和删除相同数量的工作项时，会出现这种情况。 在这种情况下，该行保持水平。
若要在此情况下跟踪范围更改，请执行以下操作：
- 将多个图表与另一个图表进行比较。
- 监视特定问题。
- 使用 冲刺进度 监视范围更改。
是否有太多的 WIP？
可以轻松 监视开发板，以确定是否超出 WIP 限制。 还可以使用CFD监视WIP级别。
大量的 WIP 通常显示为垂直膨胀。 随着 WIP 量的增多持续时间越长，凸出部分就越会扩展为椭圆形。 此行为表明 WIP 正在对周期时间和交付时间产生负面影响。
下面是 WIP 的一个很好的经验法则：在任何给定时间，每个团队成员最多应该有两个项目正在进行。 使用两项限制（而不是更严格的限制）的主要原因是，现实经常侵入软件开发过程。
有时需要时间从利益干系人那里获取信息或获取必要的软件。 有多种原因会导致工作停止。 维护第二个工作项在意外延迟期间提供操作灵活性。 如果这两个项都被阻止，是时候引发一个红色标志来取消阻止某些内容，而不仅仅是切换到另一个项目。 一旦正在进行大量项目，处理这些项目的人员就很难切换上下文。 他们很可能忘记了他们在做什么，这可能导致错误。
潜在顾客时间与周期时间
下图显示了前置时间和周期时间的差异。 在创建工作项时开始，当工作项进入“已完成”状态类别时结束。 当工作项进入“正在进行”或“已解决”状态类别时，周期时间开始，并在进入“已完成”状态类别时结束。
如果您的团队使用看板来跟踪和管理工作，了解各列如何映射到工作流程状态，将有助于您更有效地管理工作。 若要了解如何设置开发板，请参阅 开发板上的“管理”列。
若要了解系统如何使用状态类别（拟议、进行中、已解决和已完成），请参考 积压和看板中的工作流状态。
周期时间如何处理重新激活的工作项
对于重新激活的工作项（从 已完成 状态移回 “正在进行 ”状态），周期时间从第一次工作项进入 “正在进行 ”或 “已解决 ”状态类别开始，结束进入 “已完成 ”状态类别的最后时间。 周期时间包括整个活动工作周期，包括重新激活后的任何时间。
示例方案：
- 新→激活→已解决→已关闭→新→激活→已关闭
- 周期时间计算： 从第一个转换到“活动”到最终转换到“已关闭”
- 总周期时间： 在重新激活之前，包括活动工期和处于“已关闭”状态的时间
此计算方法全面了解完成工作项所需的总时间，包括重新激活后的任何返工或额外工作。 前置时间的计算遵循相同的原则——它涵盖从工作项创建到最终完成的整个时期，而不考虑任何中间完成状态。
根据前置时间和周期时间进行估算交付时间
使用平均交货周期和循环时间以及标准偏差来估算交付时间。
创建工作项时，请使用团队的平均提前期来估算完成日期。 团队的标准偏差显示估计的可变性。 同样，使用周期时间及其标准偏差来估算工作项在工作开始后完成的时间。
周期时间小组件示例
在下图中，平均周期时间为 8 天，标准偏差为 6 天。 通过此数据，估计团队在工作开始后大约 2 到 14 天完成未来的用户情景。 较窄的标准偏差使估算值更具可预测性。
确定进程问题
离群值通常意味着存在基础流程问题。 例如，等待太久，无法快速查看拉取请求或无法修复外部依赖项。 检查团队的控制图表中是否有离群值。
显示多个离群值的示例周期时间小组件
如图所示，一些异常值存在，因为某些错误花费的时间比平均值长。 检查那些 bug 为何耗时更长可以帮助你找到流程问题。 修复流程问题有助于减少团队的标准偏差，并提高团队的可预测性。
你还将了解流程更改如何影响潜在顾客和周期时间。 例如，在 5 月 15 日，团队努力限制 WIP 并修复过时的 bug。 标准偏差在该日期后变窄，显示改进的可预测性。