小议敏捷和小瀑布的异同
前言
现如今应该无人不晓【敏捷】为何物吧？但据我所知，能够掌握敏捷精髓，熟练应用于项目管理，一针见血的指出敏捷执行过程中的错误，并可以"和谐地"推广和培养团队接受的专家级人才，我了解和认识的应该是个位数，而Steve就是其中之一。可惜合作时间太短，还没偷师到一些好东西就分道扬镳了。
Fortunately，本人明智的提前跟Steve约了稿，而且他也信守了承诺，这是第一篇，后面陆续会有干货出来滴，是吧？Steve!
- 曲健Nicholas
正文开始...
小议敏捷和小瀑布的异同
- 沈灏Steve
都在实践 PDCA 和迭代/增量开发，两者差别大到非要搞清楚吗?
在帮客户实施敏捷项目的现场，以及一些和同行的交流活动中，敏捷和小瀑布的异同时常被直接或间接地提起。讨论中涉及到两者在项目交付上的效果，各自本质上的相似和差异之处。比如:在早期敏捷的实践过程中，有些项目做着做着就成了小瀑布。某些同事还会问非要搞清楚吗?
首先
这两者的确有相似之处，但在本质和实施结果上有所不同。小瀑布从本质上来说还是瀑布式的。从项目约束(项目铁三角)来看，两者对最终交付的需求价值、进度、成本和质量的管理方式不同。相应的项目成功率也有所不同。关于铁三角管理的大致不同，会在文章的最后部分小议。而成功率的不同，有份统计结果可以参考。据 StandishGroup 跟踪 2002-2010 年间的项目结果所得报告，敏捷项目的成功率和失败率分别为瀑布式的 3 倍和 1/3。
其次
在项目交付效果不同的背后，是它们在 PDCA 实施时精益程度上的不同，以及组织架构和决策的不同。我的个人体会是:如果能对这些方面加以深入理解，再到实际应用掌握，那会受益匪浅。对进一步的收获敏捷实效有益。
以下
内容假设读者对敏捷和瀑布有一定的实践和认知。因此，不会对敏捷和瀑布的基础知识作展开。我将着眼于梳理敏捷和小瀑布两者表象和内在的异同。囿于个人的实践和认知，梳理的方式和结果难免管窥，希望大家指正。
从 4 个维度 - 流程、交付物、客户诉求和人员来浅析两者差异
软件开发项目的 4 维特征
不论是 PMP 还是 CMMi， 对软件开发项目的描述相当完整，同时也很“沉重”。如 CMMi-3 就有 18 个过程域。受精益/敏捷轻流程实践的启发，我发现软件开发项目管理可以相对轻量地从 4 个主要维度来梳理，即:流程、交付物、客户诉求和人员。尽管采用了 4 个看似独立的维度来梳理，实际上它们是互为关联和影响的。工作中，改进了其中的一个便会导致和需要另外 3 个或多或少的协同改进。
为什么落在这 4 个维度呢?从项目整体的功用来看，项目是一个响应外部或内部客户诉求的系统，客户诉求是一切项目努力的源头。作为源头的客户诉求，经系统处理后转换为需求和附着其上的价值。需求和价值经过一系列的后续流程，经加工和创造成为交付物。当然，工作在流程之上的人员也少不了。
用敏捷的语言来描述这 4 个维度 ，它们各自的对应关系为:流程=>迭代;交付物=>可交付增量;客户诉求=>需求和价值;人员=>跨职能自组织团队;参见图-2。到这里，熟悉敏捷的读者会想到经典的 Scrum 流程框架了。敏捷团队先梳理产品 Backlog，形成迭代 Backlog，然后经过迭代的 PDCA(5 种会议)产生可交付产品增量。客户对产品增量的反馈进入下一次的迭代中，以期交付更能符合客户诉求。敏捷的项目周期就是由多个这样的迭代组成。相较瀑布开发，在同样的项目时间跨度内，只有一次迭代，只能得到一次可交付增量。需求的表现形式是传统的诸多 XXX 说明书。其价值一般很难传递到一线的项目交付团队。而项目团队是从以专精为主的职能部门里调配得到，很难看到自组织团队的踪影。
如果说从这 4 个维度，我们能比较容易得出敏捷和瀑布的区别，那么小瀑布又是怎么一回事呢?它和敏捷的区别又是怎样的呢?还是让我们从这 4 个维度，详细地梳理一下吧。
小瀑布具备一定迭代和增量式开发的特征(IID:Iterative & Incremental Development)因为在小瀑布项目中，PDCA℗已经能做到相对的小批量和短周期的迭代来进行。整个项目周期内有不止一次的交付增量。所以，它具有增量式开发的属性。比瀑布中大爆炸式(Big Bang)的 PDCA 更能相应外部世界的多变需求的挑战。但在单个迭代的时间箱来看，各个工序之间还是在各做各的 PDCA，工序间需要进行“硬”交接。要有 2-3 个迭代的周期(或更多)才能算是完成了一个全流程的迭代。比起敏捷，在一个短周期里需要完成全流程的 PDCA，以及在短周期内的“软”交接的灵活性还有差距。
小贴士℗ 在这里，PDCA 指计划、需求、设计、开发、测试、校验、项目监控等实现交付的工作过程，以及调整、改进等过程治理。虽然，在 PDCA 的初始含义里，Check 和 Act 是分别指
1】识别经过全流程生命周期后的流程改进有效之处
2】再将其在组织中推广，这样来使得 Check 步骤中识别的有效之处能落到实处，即英语的 enAct。
在后世的实践中，Check 和 Act 已经有了更多的衍生。包括:项目监控、识别过程改进措施和付诸实施等运用过程和改善过程。
另外，Scrum 对 PDCA 在短周期内的执行尤其强调，使用了 Sprint 一词(为了达到预期小目标的短周期 PDCA)。虽然 Kanban 在这方面，相对弱些。但也通过不同种类的 SLA 来达到类似目的。就如图-3 所示，迭代周期的大小直接影响到了项目周期内的迭代次数，也就是项目响应和反馈客户诉求的次数。
交付物
在这个维度上，我们继续参见图-3。
前一节中，我们谈到小瀑布方式下的项目交付有多次增量。但是，它的次数收到全流程迭代时长的影响。而且，由于工序间需要进行“硬”交接，文档式驱动，集中校验在长迭代的最后阶段，精益程度有限。虽然比大瀑布有进步，但是和敏捷相比(特别是 Scrum)还有差距。另外，因为是瀑布文档式驱动，小瀑布的交付物中一般没有关于客户诉求的描述。大家只是对功能进行校验，而是否真正满足客户诉求，这个一线团队基本没有概念。也没有对一线团队有这样的要求。下面一节将对交付物的源头 – 项目需求做一下梳理。
项目需求
小瀑布方式下的需求，除了批量变得小些了，其余还是瀑布式的。在项目的 4 维特征中，我们谈到大瀑布里的需求对客户诉求的跟踪不够精益。而小瀑布有所进步，做到了更小的批量。但是，它们都还是用传统类型的 XXX 说明书来描述和传递客户诉求。除了在《市场需求说明书》和《产品需求说明书》有需求价值的描述和优先级排序，在其余的文档里几乎找不到价值和优先级的踪影。
作为项目源头的需求和其传递方式的不同，直接导致敏捷和小瀑布项目的计划方式也大不相同。小瀑布的项目估算和计划也基于诸如《系统架构功能说明书》类文档来做任务级别的 WBS，进行详细估算和排期。在这种做法下，价值和优先级很难传递到一线的项目交付团队。而敏捷的 Scrum 和 XP 里，我们知道计划的最小单位是用户故事，其包含价值描述和相应的优先级。
经典的故事描述 3 段式，包括 Why, Who,What。每次迭代的产出会由 PO 和团队一起对用户故事的 What 和 Why 进行校验。以此来快速反馈到下一次或再下一次的迭代中。
人员
小瀑布下的人员组织还是由职能部门主导，一线经理分派为主。在这样的组织架构下，跨职能和自组织很难体现出来。而我们知道在敏捷下，跨职能和自组织是基本特征。一线团队成员对项目进展进行监视和控制、对任务开展进行自主判断、对迭代中的管理和工程实践进行回顾和改进、和业务代表(PO)一起评审交付增量等。
简单地说，就是迭代 PDCA 基本由团队自主决定了。当然，按照组织的现状，自组织的程度有所不同。原先一线经理的角色和职责，乃至整体组织架构也会因 PDCA 的轻量化，团队自组织化而改变。总体来说，组织架构更趋向扁平，管理的风格也由命令控制式，向服务和指导培养转变，将一线的管理工作下放至团队自管理。
具体的内容很多，因为不再是“小议小瀑布和敏捷的异同”了，所以我就不展开了。感兴趣的话，大家可以翻阅 Scrum，LeSS，SAFe，Coaching 等的相关资料。
项目约束管理的铁三角
到这里，我们从 4 维特征的角度，对小瀑布和敏捷的不同进行了由内至外的大致梳理。接着，让我们来看看二者对项目约束(铁三角)的管理的不同。参见图-4。
在敏捷式项目的实践中，铁三角里的时间由是迭代周期的次数决定，其相对固定。预算，主要指敏捷团队也相对固定。而范围相对可变。这样做的根本原因在于，敏捷假设外部世界越来越 VUCA (Volatile / Uncertain / Complex/ Ambiguous)，项目范围的变化无法避免的。这样的框架设计先天就是拥抱变化的，能满足瀑布式开发中范围变更的需要。另外，敏捷的质量是内建的。它由流程方面的 PDCA 和持续改善，以及 PO 验收交付增量来保证。实践中，因为敏捷中每次迭代较短，紧急范围的变化就算赶不上本次迭代，赶下一次迭代也行。可以说，敏捷将时间和预算相对固定，留出可变的范围是相应了外部变化，改善和简化了项目约束管理。
在分析小瀑布模式下的铁三角之前，我们先来重温一下瀑布式项目中的铁三角情况。项目的范围一般先由业务部门来确定，再“硬”交接给研发部门开展具体计划。因为这样的交接有内部合同谈判的意味，成功交接也意味着研发部门的“承诺”(Commit)和签字背书。业务部门希望研发部门恪守其承诺。而研发部门也不是轻易承诺的。部门经过对可行性和人力资源最佳配比的再三研究后再会做出对一定范围的承诺。对于承诺范围的大小，业务部门和研发部门会来回拉锯多次。最终，双方得出一个互相妥协的结果。因此，在项目执行和实现的过程中，研发部门不希望业务改变范围从而影响项目的具体计划和执行。如果非要改变的话，将会影响已承诺范围的继续执行的可行性，所以要对范围变化进行评估，需要走“变更”流程。变更流程的产生的根本原因就在于批量太大，项目的可交付增量只有一个的局限造成的。由此，我们能得出瀑布下的范围是固定的。而且，这种固定还有另外一个对需求的假设，就是项目范围所要求的可交付增量一定是客户所需要的。也就是说，项目范围的价值在客户没有具体尝试之前已经被确认了。这和敏捷对需求价值的探索式假设很不一样。
其次，瀑布式项目中的时间和预算经常是超出计划的，可变的。主要原因有:
1)项目交付物要到最后环节才集中校验，质量问题最后的总爆发容易导致项目延期，超预算。
2)项目范围的变更。
3)项目时间和人力分配的不均匀。我们往往看到项目的早期和中期，团队成员们的工作较不饱满。而后期，往往是轮番加班，甚至熬夜。
4)需求的传递在职能部门间“硬”交接，导致交接不畅而产生的浪费和重复劳动。
5)重流程所带先天的决策缓慢，和一线等待的浪费等。
在实际情况下，这些因素也会导致交付质量被某种程度的牺牲。
瀑布式下的情况大致分析完毕后，我们再一起来聊一聊小瀑布的铁三角情况。在项目需求一节里，我们已经谈到小瀑布的项目范围相对瀑布要小。小批量意味着更高的灵活性。但因为小瀑布的迭代相对敏捷还是较长，很难响应在较长的一次全流程迭代内发生的范围改变。但是在实际工作中，小瀑布式项目中的“变更”还是较有可能发生的。而且一旦“变更”是必须的话，那些没有来得及校验和确认的在制品，便会成为相当棘手的问题。一般情况下，业务部门和研发都会希望把在制品做完，也就是完成一次全流程迭代后，在下一次的全流程迭代中再考虑新的范围。因为小瀑布项目周期里有多次长迭代，小瀑布的范围便具有一定的可变性了。但是灵活度还是不及短迭代的敏捷。接着就是小瀑布中铁三角的另外两个角 -- 时间和预算。因为小瀑布有了多次的长迭代，它的排期和响应的预算也能因长迭代而固定。但实际工作中，因为和瀑布中一样的原因，尤其是 1)、3)、4)、5)，长迭代的运行相对短迭代较容易发生偏差，导致长迭代延期，超预算。
小结
综上说述，小瀑布比起瀑布有所改进，特别是在 4 维特征里的迭代和增量方面。但是和敏捷相比较，这两个方面还有差距。在需求的传递和人员自组织方面，则差距更大。对于项目约束的管理方面，小瀑布较瀑布有所改进，但敏捷的做法更为简练和响应变化。
END
?