摘要：软件开发是一项复杂的工作，而软件项目管理则是一门艺术。通过简单有效的管理手段使项目顺利完成是所有项目管理者追求的目标。累积流图是一种简单实用的量化分析方法，可以帮助项目组有效的识别问题。笔者曾经在一些项目中使用过该方法，取得了良好的效果。望本文对于累积流图的介绍能够对读者有一定的帮助。
1:什么是累积流图？
累积流图是一种识别项目“瓶颈”的度量分析方法。“瓶颈”是指项目工作流中存在阻碍的位置，它将导致项目工作流变慢。在项目的“瓶颈”附近会出现工作任务积压的现象。这就好比公路上某个路段由于道路变窄导致车辆通过性下降，出现堵车。
图1：累积流图及关键指标
累积流图横轴为时间轴，纵轴为任务数量。通常，累积流图的数据由多条线组成，每条线代表不同阶段累积已完成的任务数。图1是一个比较简单的累积流图，由三条线组成最上方的线代表累计收到任务数量，中间的线代表累计已完成开发的任务数量，最下方的线代表累计已交付的任务数量。只要项目正在使用进度表，就可以很容易得到累积流图所需要的数据，画出累积流图。
在上图中可以看到两个关键指标：
（1）在制品数量（Work In Progress, WIP），即图中最上方线和最下方线之间的纵向垂直距离，它显示的是某个时间点已经开始但还交付的任务数量。当WIP增加时，意味着项目中未交付的任务数量正在增加，也就意味着工作流出现拥堵。在图中，WIP最长所对应的时间点就是工作流中拥堵最严重的点，即为“瓶颈”。图1的三条线将WIP切分成两段，上半段（绿色）代表已接受但还未完成开发的任务数量，下半段代表已完成开发但还未完成交付的任务数量。上半段比下半段长，说明瓶颈主要出现在上半段，也就是说要解决当前“瓶颈”主要是要减少已接受但还未完成开发的任务数量。
（2）前置时间（Lead Time），即图1最上方线和最下方线之间的横向水平距离，它显示的是任务从接受到交付的平均时长。前置时间变长意味着“生产线”流速变慢。需要注意的是，累积流图并不跟踪具体的某个任务，前置时间也不指向某个具体任务的交付，只反映平均交付时间。
根据在制造业总结出来的利特尔定理（Little’s Law），在制品数量与前置时间呈线性相关。也就是说通过减少WIP可以缩短Lead Time，加快工作流。其实这很好理解：当公路上车辆减少时，车速自然就会提高。如果公路上同时出现过多车辆，所有车辆的速度都会变慢。在软件项目中，很多项目经理为了赶进度而在计划中加入过多任务，其实这种做法不但无法起到加快效率的作用，反而会使项目工作流出现瓶颈，从而降低交付效率影响客户满意度。
综上所述，累积流图能直观的显示出项目的“瓶颈”，并可以通过减少WIP提升整个工作流效率。
2:累积流图应用
当项目是按照一个特定流程进行工作，并且持续向客户进行交付时，就可以使用累积流图。笔者首次应用累积流图是在一个系统维护项目。客户不定期给项目组提出原有系统的修改任务。每个任务都要经过分析、设计、编码、测试这几个标准流程。每个任务只要完成后就可以交付给客户。
该项目从开始就陷入了热火朝天的加班状态。老员工们一边忙于指导项目中的新人，一边完成自己手头的工作。一些业务疑问客户也没有时间及时答复。客户和项目组之间互相的不满情绪开始蔓延，客户开始质疑项目组能力，项目组也对客户的配合度表示不满。
没过多久，项目进度表似乎已经不起作用了，频繁出现的延期导致进度表经常要被调整。
最新版的进度表看起来是没有多少延迟的，但过不了多久延迟又出现了。笔者作为QA和项目组对当时的项目状态进行了讨论，大家普遍认为，现在项目问题很多，究竟哪些是关键问题，哪些是优先级最高要解决的问题并不清晰。显然，项目组当时缺乏有效的数据来帮助项目经理进行管理和决策。在QA的建议下，项目经理开始尝试使用累积流图每周对项目整体状态分析。
图2：某项目累积流图实例
图2是笔者曾经所在项目的累积流图实例。横轴代表项目开始的周数，如W3代表项目开始后的第三周。从图中可以看到项目过程中产生了几个比较明显的瓶颈：
（1）需求阶段在W6-W7是工作流的瓶颈（项目已接受但还未完成需求的任务数量明显增多）。项目经理组织项目组进行原因分析：客户回复Q&A的速度突然下降，其原因是负责回答Q&A的客户被他的领导临时要求，将主要工作精力放在业务需求整理上，因为客户担心需求的提供速度可能会影响我们的开发。可是从累积流图中可以看出，项目组已经积压了很多的需求都还没有进入到分析环节，也就是说，项目组根本就不缺需求。之前虽然通过周会向客户提出了Q&A延迟对我们产生的不利影响，但客户直到看到了累积流图才知道这个影响有多大。在将这一问题的分析过程展示给客户之后，客户立刻解决了Q&A回复的问题。
（2）设计阶段在W10-W12周成为比较明显的瓶颈。经过原因分析得知，项目一名设计人员离职，因为考虑到近期工作较多只是一种临时现象，项目经理本想在组内将这个工作量消化了，但无奈已经越来越影响项目进展。而且领导并不同意继续为这一项目投入人力。因为项目已经处于超编运行，其他项目还处于缺人状态。但我们从图2可以看到，分析环节已经变的非常顺畅，而且考虑到后续需求难度不大，项目决定和领导做一个交换，使用组内一名分析人员来置换一名设计人员，领导最终同意了这个方案。
（3）在W15-W16开始，测试阶段成为明显的瓶颈。经过原因分析得知，开发组近期增加了一些新员工，本来期望提高产能，结果他们对代码质量的控制做的不好，很多代码在进入测试环节之前的冒烟测试没有通过，从而出现了返工，导致WIP上升。经过评估，项目经理决定通过代码检查工具、调整任务分配、加强对新员工辅导等多个角度提升开发质量，从而逐渐解决了这个瓶颈。
项目组通过定期使用累积流图对项目状态进行分析，不断识别和解决项目“瓶颈”，有效降低了出现积压的工作任务，提交了交付速度瓶颈，提升了客户满意度。在使用累积流图的过程中，笔者总结了几点心得：
●第一，
累积流图帮助我们系统性的考虑项目全局。当我们身处项目之中，往往会将精力聚焦解决细节问题。
如果一个工具能帮助你很简单的看清全局，将会起到事半功倍的效果。
●第二，
累积流图促进了跨团队的合作。软件开发过程中，不同的工程阶段是由不同的团队或角色完成的。
跨团队合作的前提是一个团队能否深刻理解另一个团队的需求。在笔者的实例中，客户通过累积流图深刻理解了项目组最优先要解决的问题并非是自己想象中的需求，而是Q&A回复速度。
●第三，
累积流图推进了持续改善。根据约束理论（Theory of Constraints）,一个流动型的生产系统中总是有一个瓶颈。当我们使用累积流图集中精力消灭了一个瓶颈后，图形中还会有下一个瓶颈出现，不断的识别并消除瓶颈的过程，正是我们实践“改善无止境”这一质量管理名言的过程。
●第四，
通过累积流图可帮助项目组识别资源使用状态，当出现瓶颈时，可考虑进行资源调整。
事实上，累积流图不仅可以分析项目任务，还可以用来分析项目Q&A状况，缺陷修改状况、需求变更状况。只要是流程化的工作，都可以使用累积流图来观测“瓶颈”。
3：总结
总之，累积流图非常简单实用，更重要的是不会增加管理成本。如果你在组织内推行一项改进，最好选择一些不会对其他人造成太多负担的切入点，累积流图正好符合这个特点。希望通过本文的介绍让更多人认识和掌握累积流图，如果你的项目遇到了很多问题却不知该从何下手，那就快快使用累积流图去帮助你吧。
附录名词解释：
利特尔定理：由麻省理工大学斯隆商学院（MIT Sloan School ofManagement）的教授John Little﹐于1961年所提出与证明。它是一个有关前置时间与在制品关系的简单数学公式，这一法则为精益生产的改善方向指明了道路。
约束理论：是以色列物理学家、企业管理顾问戈德拉特博士(Dr．EliyahuM．Goldratt)在他开创的优化生产技术基础上发展起来的管理哲理，该理论提出了在制造业经营生产活动中定义和消除制约因素的一些规范化方法，以支持连续改进。可用一句话来表达约束理论，即找出妨碍实现系统目标的约束条件，并对它进行消除的系统改善方法。
