累积流图示例的价值在于把“瓶颈在哪”从感觉变成可读的图形。本文用一份演示情景的两周数据，完整展示待办、开发中、待评审、测试中、已完成五个状态的在制品数量如何逐日叠加成色带，并逐项解释色带变宽、整体斜率、平坦段分别说明什么。读者可以照着这份表格替换成自己团队的每日快照，做出能定位积压状态与积压起点的累积流图。
要点总览（TL;DR）
- 累积流图示例的核心是每天记录各状态的在制品数量并叠加成带，相邻色带的垂直距离就是该状态当天的在制品数。
- 示例中待评审色带从1增厚到10，是变宽最快的状态，说明积压主要发生在评审交接环节。
- 对比已完成色带斜率与中间色带增厚速度，可以区分瓶颈偏上游投放还是偏下游消化；示例属于后者。
- 测试中长期平坦而上游待评审持续增厚，说明平坦来自交接受阻，而非该环节本身空闲。
- 换成自己团队数据时，先统一状态定义与每日快照时点，再按总在制品、单条色带、斜率的顺序读图。
示例要回答什么：从一张累积流图看出瓶颈
这份示例设定一个常见的研发情景：一个约八人的功能团队，两周共十个工作日，工作项以需求卡和缺陷卡为主，统一按“张”计数。所有数据均为演示情景，用于说明读图方法，不代表任何真实团队的表现，也不能据此推算效率收益。
示例要回答三个问题。第一，哪个状态在积压——是待评审排队，还是测试环节堆积。第二，积压从哪天开始——是某次批量投放之后，还是持续缓慢累积。第三，瓶颈偏上游还是偏下游——是需求投放速度超过开发消化能力，还是开发产出快于测试验收能力。这三个问题对应累积流图的三条读图线索：单条色带宽度、色带整体斜率、某状态与下游状态的对比形态。
统计口径需要先约定清楚，否则图形会失真。本示例采用按天快照、按工作项计数：每天固定时点记录当时停留在各状态的工作项数量，同一工作项在一天内只计入其当前所处的一个状态，跨状态流转在次日快照中体现。状态划分与团队实际流程一致，不额外拆分子状态，也不把“阻塞”单列为状态，而是通过色带形态和备注识别。已完成状态只累计不减少，因此最上方色带单调上升，这是累积流图的基本性质。
完整示例：一份两周的累积流图数据与读法
下表是演示情景的每日快照数据。每一行是一天的记录，每一列是该状态当天的在制品数量，最后一列是累计完成数。把五列数值自下而上叠加，就得到累积流图的五条色带；相邻两条色带之间的垂直距离，就是该状态当天的在制品数量。
| 天数 | 待办 | 开发中 | 待评审 | 测试中 | 已完成（累计） |
|---|---|---|---|---|---|
| 第1天 | 18 | 4 | 1 | 1 | 0 |
| 第2天 | 17 | 5 | 1 | 1 | 1 |
| 第3天 | 16 | 6 | 2 | 1 | 2 |
| 第4天 | 15 | 7 | 3 | 1 | 3 |
| 第5天 | 14 | 8 | 4 | 2 | 4 |
| 第6天 | 13 | 9 | 5 | 2 | 5 |
| 第7天 | 12 | 10 | 6 | 3 | 6 |
| 第8天 | 11 | 10 | 8 | 3 | 7 |
| 第9天 | 10 | 10 | 9 | 4 | 8 |
| 第10天 | 9 | 10 | 10 | 4 | 9 |
把这张表画成累积流图，形态可以这样描述。最下方的“待办”色带从18缓慢降到9，说明需求投放节奏平稳，没有出现批量涌入。中间的“开发中”色带从4稳步增厚到10，前七天持续变宽，后三天保持平稳，说明开发环节的在制品在持续累积。“待评审”色带从1增厚到10，是五条色带中变宽最明显的一条，尤其第7天到第10天从6涨到10，积压加速。“测试中”色带长期停留在1到4之间，几乎平坦。“已完成”色带以每天约1张的速度缓慢上升，斜率明显低于开发中的增厚速度。
由这些形态可以得出示例的读图结论。第一，主要积压在“待评审”状态，它是最宽且增厚最快的色带。第二，积压起点在第5天前后，此前待评审维持在1到2张，此后每天净增约1张，说明从第5天起评审消化能力开始跟不上开发产出。第三，瓶颈偏下游交接环节：开发中持续增厚而测试中几乎不动，说明工作项卡在评审这道交接关口，尚未进入测试；已完成色带斜率偏低，进一步印证下游消化能力不足。这个结论指向的动作方向是增加评审投入或缩短评审等待，而不是继续加快开发投放。
逐项解释：每个判断是怎么从数据里读出来的
色带变宽与变窄对应在制品的增减。相邻两条色带的垂直距离就是该状态当天的在制品数量，距离逐日拉大即色带变宽，表示进入该状态的工作项多于离开的，形成积压；距离逐日收窄即色带变窄，表示该状态在消化存量。示例中待评审色带从1增厚到10，是典型的持续变宽；待办色带从18降到9，是缓慢变窄，属于正常的需求被逐步领取。
斜率对比用来区分上游投放问题与下游消化问题。看最上方已完成色带的斜率，它代表团队的整体交付速度；再看各中间色带的增厚速度。如果待办色带快速变薄、开发中色带同步快速增厚，说明投放快于开发消化，瓶颈偏上游；如果开发中色带持续增厚、而紧邻的下游状态几乎不动，说明产出快于下游接收，瓶颈偏下游交接。示例属于后者：开发中增厚的同时测试中平坦，问题出在评审这道关口，而不是需求投放过猛。
平坦色带有两种常见成因，需要区分。一种是该状态本身工作量小、流转快，平坦是健康表现；另一种是上游供给不足或准入受阻，导致该状态长期空转。区分方法是看它的上游色带：如果上游色带也在变窄或平稳，平坦更可能是供给不足；如果上游色带持续增厚而该状态平坦，则更可能是交接或准入规则卡住了。示例中测试中长期平坦，而它的上游待评审持续增厚，因此判断为评审交接受阻，而非测试环节本身空闲。
示例中有几处容易误读。其一，把待办色带变窄当成好消息——待办减少本身中性，要结合开发中是否同步增厚来判断是正常领取还是投放不足。其二，只看某一天的单点数值，忽略连续趋势；单日波动可能来自批量导入或集中关闭，至少要看一周以上的形态。其三，把已完成色带的绝对高度当成产能，它只反映累计完成量，斜率才反映速度。其四，忽略统计口径变化，如果中途调整了状态定义或快照时点，色带的突变可能来自口径而非真实流动。
可迁移规律：把示例换成自己团队的数据
把这份示例换成自己团队的数据，可以按以下步骤操作，每一步都有明确的产物和完成标志。
- 裁剪状态列。按团队实际流程确定三到六个状态，例如待办、开发中、待评审、测试中、已完成；状态太少看不出卡点，太多则色带难以辨认。产物是一份状态定义清单，完成标志是团队对每个状态的含义和进入、离开条件达成一致。
- 确定快照时点与责任人。每天固定同一时点（如每日站会后）由固定角色导出或记录各状态的工作项数量，避免不同人不同时点造成口径漂移。产物是每日快照记录表，完成标志是连续记录不少于两周且无缺日。
- 按固定顺序读图。先看总在制品，即最上方已完成色带与最下方待办色带之间的总厚度，判断整体是否在膨胀；再看单条色带，找出最宽和增厚最快的状态；最后看斜率，对比已完成色带斜率与各中间色带增厚速度，定位瓶颈偏上游还是偏下游。产物是一页读图结论，完成标志是能指出具体状态和大致起始日期。
- 把结论转成下一步动作。若瓶颈在评审交接，动作方向是明确评审准入标准、限定待评审上限或增加评审人手；若瓶颈在测试，动作方向是补充测试资源或拆分测试批次；若整体在制品持续膨胀，动作方向是先限制投放、消化存量。产物是一到两项可执行的动作，完成标志是动作有明确负责人和观察周期，下一轮快照能验证色带是否收窄。
在采集环节，工作项状态与流转记录需要有稳定的承载方式。ONES 的工作项管理支持为不同类型工作项配置状态与流转规则，状态变更会留下记录，便于按天回溯各状态的工作项数量，减少手工统计的口径偏差。团队可以把每日快照的口径与工作项状态定义对齐，让累积流图的数据来源和流程规则保持一致。
适用边界：累积流图能说明什么、不能说明什么
累积流图适合判断流动与积压：它能显示哪个状态在堆积、积压从何时开始、瓶颈偏向上游投放还是下游消化，适合团队在回顾或流程改进时作为讨论依据。它描述的是工作项在流程中的分布和变化，回答的是“卡在哪”和“什么时候开始卡”。
它不适合用来评价个人绩效。累积流图统计的是状态层面的工作项数量，无法区分个人贡献，也不应据此对个人做考核或排名。人员的主观体验、协作感受和疲劳程度属于开发者体验与协作效能的议题，需要访谈、问卷等另外的方法。单个项目的进度纠偏和排期调整属于项目进度管理，累积流图可以提供线索，但排期决策还要结合范围、依赖和资源情况。
使用中最大的失真风险来自数据口径不一致。状态定义中途变更、快照时点不固定、同一工作项被重复计数、跨状态流转未及时记录，都会让色带形态偏离真实流动，进而得出错误的瓶颈判断。因此在读图之前，先确认统计口径在整个观察期内保持一致；一旦口径调整，应在图上标注断点，分段解读，避免把口径变化误读成流程变化。
常见问题
示例里的数据可以直接当作团队基线吗？
不能。示例数据是演示情景，用于说明读图方法，不代表任何真实团队的表现。团队基线需要用自己连续两周以上的每日快照重新采集，并且保持状态定义和快照时点一致，才能作为比较依据。
团队状态比示例多，比如还有“阻塞”和“联调”，色带怎么处理？
状态列按团队实际流程裁剪，一般控制在三到六个状态。如果“阻塞”是频繁出现的停留点，可以单列为一个状态，让积压直接显形；如果只是偶发，用备注标记并在读图时结合色带突变判断即可。状态越多，色带越窄越难辨认，建议先合并相近环节，再逐步细化。
每天记录一次快照，遇到周末或节假日怎么办？
关键是整个观察期内口径一致。可以只在工作日记录，并在图上标注间隔；也可以按自然日记录，让周末的停滞如实呈现。两种方式都能读图，但不能中途切换，否则色带的突变可能来自记录方式而非真实流动。
发现瓶颈在评审之后，下一步应该先做什么？
先确认瓶颈是产能不足还是准入规则不清。如果待评审持续增厚而评审人力有限，可以限定待评审上限、明确评审准入标准，或增加评审投入；如果大量工作项在评审前反复返工，则要先查开发交付质量。动作落地后，用下一轮快照观察对应色带是否收窄，作为验证。
累积流图能用来评估某个人的产出吗？
不适合。累积流图统计的是状态层面的工作项数量，无法区分个人贡献，据此做考核或排名会误导判断。它回答的是工作卡在流程的哪个环节，个人绩效评价需要另外的方法和数据。
