文/明道创始人任向晖
今天软件行业的人已经无人不知敏捷开发。实践者也不局限于互联网产品公司，即使是传统软件开发团队，也十分愿意采纳。温和的看板之于严苛的期限，当然前者要友善得多。SCRUM能够得到普及，和它宽慰人心的作用是分不开的。
敏捷开发宣言
捷开发思想的确在改变软件行业面貌。它让小型团队可以摆脱过于笨重的项目计划，让产品设计和开发避免闭门造车，不至于让程序员的青春年华浪费在那些因为失败而没有投入使用的软件项目上。它同时也推动了需求方和开发者之间的持续透明沟通，让团队开始意识到，高频度的沟通是提高软件交付质量的原动力。敏捷开发还将工作的起点转换到客户的具体问题解决（User Story），而不是从一个看似完善的产品需求文档出发。
2001年，17名软件工程师发表了著名的敏捷宣言，全文只有聊聊数十个字：
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值。
在应用敏捷开发的数年中，我们自己从中得到了很多的收益。作为SaaS软件产品，采纳敏捷开发模式几乎是从本能出发的。至少，我们没有和客户的合同谈判，并非为特定客户交付一个软件项目，而是自始至终地改良属于自己的产品。在相对稳定的冲刺周期内（2-4周），交付短期可估量的特性通常不是很大的挑战，即便有1-2天的延期和缺陷修复，看起来也没有严重的商业后果。
期限之殇
但软件开发行业的大部分从业者其实并不是产品开发者，而是服务于提供IT服务的外包开发商。他们按照合约的要求，在固定的期限之内需要给客户交付可用的软件。敏捷开发宣言似乎并不能完全打动他们的客户，因为期限不仅是开发合同的要件，还直接影响客户的业务运营。在一桩典型的外包开发项目上，的确很难应用敏捷开发模式。
即使是像明道这样的产品型公司，也不能完全通过敏捷开发模式来覆盖所有的开发活动。对于全新的重构、大型版本、偿还技术债、复杂的特性交付等情况，就几乎不可能在2-4周的时间范围内达成。我们经历过的最漫长迭代周期超过四个月。虽然这当中肯定有决策失误的原因，但没有产品能够完全幸免这样的遭遇。即使像Salesforce, Asana, Atlassian这样的高水平SaaS产品企业，都有过那些结果糟糕，而又不得已为之的长跑型迭代。
这张图是敏捷开发模式下典型的任务板模型。乍一看是非常直观且有效的开发管理模式。但它只能支持日常特性迭代，在固定周期完成合适数量的User Story。而且，在In Process这个狭窄的看板中，其实掩盖了过程控制问题。如果这个In Process不能在1-2周内完成编码和单元测试，整个冲刺就高概率地会失败。SCRUM方法要求在这种情况下进行复盘，找出项目延期的原因，在下一次迭代中针对性改善。但从很多产品团队的反馈来看，这个原因通常总是归结在User Story放得太多了，或者定义得太模糊了，而鲜见去复盘设计开发过程中的进度控制问题。
所以，SCRUM在带来价值的同时，并不能天然地保证团队准时的交付。而如果要做到准时交付，团队自然也不能通过牺牲特性交付量来实现，因为企业永远受团队协作、销售业务需要、竞争等要素的压迫。
无论是传统的开发项目，还是敏捷开发项目，我们到底应该怎样来实现高成功率的进度控制呢？
其他行业的启示
要为软件行业找到按期交付的办法，我们可以从其他对工作交付期限有更高要求的行业寻找灵感。在众多行业中，建筑工程管理和按单制造业是符合要求的两个行业。
建筑工程受制于客户合约、租赁器材的高成本、人员计划的约束，对于项目执行的节点要求非常高，项目或者项目内的大节点延期会带来大额的损失和违约风险。完整的建筑工程项目计划大多用甘特图绘制完整，其中包含任务的前置关系、资源的约束，并且项目计划被允许保存为基线，用来和实际进度定期比较。同时，通过专业的项目管理软件（例如Project），项目经理还要识别出众多任务中的关键路径（Critical Path），在关键路径上的任何任务延期，都会导致整个项目的延期。相反，如果一个任务不在关键路径上，它可能有一定的缓冲空间。
按单制造业根据客户性质的不同，按时交付的刚性有所区别。但整体上都面临客户合同的约束，即使延期也必须在合理范围内。如果是在工业上游的制造业，他们面临的交付压力就会非常大，因为一旦延期交付，影响的是后续供应链的生产计划。想象一下苹果公司对富士康等装配企业的要求，再想象富士康因此给上游材料、工具、模具等制造企业的交付要求。
因为这两个行业的现实挑战，他们自然会因为内在的压力形成一些有效的做法，来实现更可靠的按期交付率，这些方法和原则可能对软件业有所启发。
1）专业的WBS分解
如果打开一个建筑工程项目管理文件或者一家模具制造的工单分解和排程表，外行肯定像看天书一样，因为你没有受过工程专业训练，不了解各门类产品具体的生产工艺和制造程序。反过来说，如果这两个行业的任务和里程碑分解结果你都看得懂，说明它无法起到真正的过程管理作用。对于外行来说，也许最多能够猜测出来的建筑工程里程碑就是打地基，结构封顶，内装修，外装修了。但这些所谓的里程碑每一个都可能需要数月的周期才能达成。而且，实际上，一个普通民用建筑的里程碑需要数十个分部分项专业才能列举完整。
分解的WBS任务有大有小，建筑业的最小工作包从一两天到一两个月不等。无论长短，它都有一个专业衡量，即便它来自的是经验判断。一座小型建筑的施工准备是2天，土方开挖和基底清理要20天，楼层主体每层要20天，这些预计工期在行业内已经成为显性的知识。
有专业的任务分解、工期预估、流程次序和里程碑定义是进度管理的基础，有了这个信息，我们才能够实现第二步—持续跟踪。
2）持续的进度跟踪和关键里程碑
这两个行业都有高密度跟踪进度的实践，而且大多有专人。建筑业一般在项目部有施工日志要求，并依据日志通过专人负责更新进度表，制造业则有每日站会（一般就在车间里）和生产经理来管理排程。
进度跟踪的基本逻辑在两个行业有所不同。建筑业通过原有的基线对比，来准确协调各分部施工方、分包商、材料供应商和施工人力资源的准备、入场和验收。准备完成、入场和验收完成是建筑业各个分部分项工作的核心里程碑。制造业则紧紧围绕工件，依据工件在制造程序上的流转来确定进度，如果进度滞后，则要及时修改剩余的制造程序排期，所以大体可以认为工件在单个制造工序上的完成是制造业的关键里程碑。
3）遇到问题后的快速会商
在软件行业中的人，经常被一件事情困扰，那就是需求的不明确和经常的变更，尤其是自有软件产品开发项目。很多软件开发的延期会将责任归咎在需求的含糊和变更上。我以前总以为像建筑工程这样的项目不太会有经常的变更。设计图纸和施工工艺一般不存在含糊的情况。事实看起来的确是这样，一座机场可容不得业主在开工了一半的情况下突然决定增加一个候机楼。但是，这并不意味着其他行业不存在变更和其他意外的问题。实际上，局部的施工修改和变更随时都可能发生，施工中遇到的实际环境和设计条件存在差异，因为环境、设备、材料、人员能力和工艺有效性带来的突发问题层出不穷。制造业甚至总结出了“人、机、料、法、环”（分别指人员、机器、材料、方法和环境）的生产影响要素。
那么遇到问题该怎么办呢？从这两个行业观察到的方法和我的本能直觉一致——集体会商！
制造业的现场管理和站会不是没有道理。在生产过程中发现和产生的问题，最好的解决办法是在制造现场，站在车间里解决。建筑业也是一样，除了工程师可能要带上安全帽进入施工现场以外，工程项目部也永远都设在施工现场一两百米的距离之内。我在采访一些工程项目部的时候，发现所有的项目部经理办公室都有一个大大的沙发区，项目经理很难离开这个现场，因为随时要召集不同职能的人会商问题。
从两个行业总结出的这三点看起来非常简单，也不难理解。但反观我们的软件业，在全行业拥抱SCRUM的同时，似乎丢失和忽略了一些原则。这也许是我们管理交付期限更为困难的原因。
软件业应该怎么做？
1）将进度要素纳入敏捷开发
其实敏捷开发宣言中也并没有完全抛弃进度，它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定（2-4周），所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性，作为一个不算成功的迭代来复盘。
预测在2-4周内能够完成的特性开发量相对容易，稍有经验的ScrumMaster都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业SaaS特性开发中，一个迭代经常需要超过一个月，再加上必要的测试和灰度发布，可能轻易超过两个月。我统计了一些常用APP的版本更新历史，发现80%以上的App更新频度在两个月以上。
所以，我们必须要把进度要素重新纳入敏捷开发的管理范畴内。
这意味着，看似简洁的SCRUM开发看板，在In Process（开发中）这一栏的任务内容需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。
而在敏捷开发之外，传统的软件开发计划和建筑工程项目管理相比，大多也欠缺详尽的进度计划，而只是笼统定义几个粗放节点。如果是业务部门人员和外包客户达成协议，软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候，别说客户了，就连自己人也很容易拿交付的时点来倒逼开发团队。
是不是应该倒算排期是一个很难回答的问题，企业总是面临客户的需求压力和竞争压力。问题的关键不在于交付期限的来源，而是有了交付期限以后，我们应该怎样细分软件研发工作的关键里程碑。
2）软件研发的关键里程碑
软件研发的里程碑到底应该怎样定义？我相信这个问题很多研发团队都做过探索。按照设计交付、编码完成、测试发布和验证发布这样的粗线条节点划分虽然容易，但对进度管理并没有实质性的帮助。而且，对于敏捷开发项目来说，设计交付甚至都不是一个一刀切的工作，有一部分细化设计工作完全可能在编码工作开始以后再进行。
当我们从建筑工程行业寻找灵感的时候，发现他们的关键里程碑是各个分部分项工程的准备、入场和验收。而且每个分支工程所需要的工时在计划时的确能够比较准确地衡量。虽然软件开发远远没有建筑工程的分工项目那么多，但是要做到可靠进度管理的基本前提是一样的。
制造业的规律也同样提供了线索。工件在工序上的转移是一个明确的物理过程，进入B工序的前提是完成A工序，每个工序所需要的工件加工时间只要能够被精确衡量，整个制造过程所需要的时间和资源就能够被事先计划清楚。而这个计划过程是在工件进入加工之前用专门的排程工作事先完成的。
软件业如何采用类似的思想来提高自己的进度管理水平呢？
首先，软件开发要根据前端开发、后端开发和测试的主要专业分部建立细化的专业里程碑。一般前端开发工作依据设计阶段产生的页面来清点前端组件开发工作量。在模块化开发的过程中，还要注意对通用组件的合并归纳。一般而言，页面数量越多的应用，前端开发的工作量越大，模块化程度越低的项目，工作量越大。后端开发则根据数据对象和功能特性的设计来细化出接口列表和数量。如果不涉及特殊计算，大部分企业应用的开发工作量和接口数量成正比。而黑盒测试所需要的时间则和以上的前后端开发量总计成正比。
理解了这个规律，再复杂的软件开发项目也同样可以像建筑工程那样列出整个开发测试工作的关键里程碑。
在分割这些里程碑的时候，达成里程碑所需要的工作时间一般要细化到一周工作量以内的颗粒度，否则开发过程中的按周检查就失去了意义。
谁能够有这个专业能力来定义这些关键里程碑呢？其实和建筑工程一样，团队并不需要一个全能的高手，而是应该由负责前后端和测试工作的专业工程师一起评估给出。制定计划和执行计划的人如果是一致的，计划达成的概率会更高。当然，因为前后端开发工作不可避免地需要相互协调，以确定科学的次序，所以这个制定过程总是依赖产品和研发人员的集体会议。但这样的会议因为目标清晰，就是为了产出里程碑列表，所以效率可以得到保证。
下图就是一个根据以上原则和方法创建的复杂开发项目关键里程碑列表。为了便于每周的检查和跟踪，特意没有做成甘特图模式，而是将里程碑项目根据期限进行分组，每组就是一周内应该达成的里程碑。开发小组在周末进行的检查完全基于这个开发进度计划。
按照这个方法，能不能根据迭代的总期限（比如四周）进行倒推呢？当然可以！而且，这样的倒推，才让敏捷开发中重要的响应变化原则得到体现。在没有可靠进度计划之前，产品研发团队对于一个迭代所需要装进去的开发内容总是容易产生争议，大部分争议集中在用户价值上。但是，用户价值是需要使用数据加以佐证的，在新产品，新特性的开发过程中，往往还没有足够的用户数据来帮助决策，这时候，特性功能对交付时间的影响就成了另外一个关键决策要素。
当我们不得不尊重一个大版本的交付总期限时，团队就能在细分到每周的开发里程碑表中找到均衡，更容易达成一致。有时候，团队会毫不犹豫地在开发计划中将某个特性划去，因为它极可能带来整个项目的延期风险。
以上介绍的是在敏捷开发模式下的进度计划要素。这个基本方法当然也应该用于一个全新产品和项目的研发过程。只不过，除了具体的模块定义，接口定义和页面组件定义带来的开发工作时间计划外，还需要留下足够的项目整体架构时间。这些初始化的架构工作包括项目成员参与技术方案调研和论证，数据结构的初始化设计，通用类库的定义，以及在这个过程中和产品需求方的沟通工作。根据需求来源的性质和清晰度差异，它们通常要占据团队2-4周的时间。
3）跟踪、响应和及时沟通
制定和落实了进度计划，是不是就不会有意外呢？当然不一定。无论是自己的产品，还是客户的委托开发项目，变更有的时候是难以杜绝的。为了保证最终交付的质量，有些变更我们宁可去冒险，也不会对已知的失误无动于衷。
但接纳变更，响应变化的前提是持续对里程碑计划进行维护。让最新版本的里程碑计划能够体现出变更后的情况。和其他行业不同，软件行业一般不需要做完整的基线对比，所有的变化都应该反映在从今天往后的新计划中。从这一点看，对进度的控制并不破坏敏捷项目管理的基本原则。
当周不能完成里程碑的原因不仅仅是需求的变更，还可能是开发过程中的遇到的技术实现问题。我们永远无法保证研发人员事先已经掌握了所有的技能和知识，开发过程中随时可能会遇到成员的能力瓶颈和信息断层。解决这个问题的办法和建筑业，制造业一样——及时的会商。
开发人员有时候怯于提出问题，担心自己遇到的阻力会影响团队的进度，所以一个人闷头花了过长的时间，而事实上可能有更好的解决方案或者完全可以接受的变更。为了保证做到这样的及时会商，团队可以约定在周中（比如周三下午）安排一次期中检查，由产品、研发和必要的管理层一起参加，主动去发现这样的执行瓶颈，以避免到周末的时候不得不被动接受延期的现实。当然，为了做到更高密度的跟踪，研发团队内部也应该坚持SCRUM开发要求中的每日站会。
所以，在研发过程中，跟踪进度，响应问题和及时主动沟通是保证进度的基本手段。
4) 按期交付的激励
最后，我们要谈一谈按期交付的激励问题。很多开发团队为了解决按期交付的问题，都设计过各种各样的激励计划，其中最常见的就是项目按期交付的额外物质激励或者假期奖励，名曰项目冲刺奖。甚至还把提前交付的时间长度作为奖励的一个变量。
从我们长期的研发管理实践看，这样的做法有百害无一利。因为，它会让管理的重心盯向结果，而不是必要的过程，从而忽略投入在那些让项目如期完成的原因上。
过度强调如期交付的奖励，会让团队成员忽略质量，不愿意花费时间在计划和沟通上，而且一定会制造研发人员和产品设计人员之间的矛盾。如果前者对交付时间负责，后者对用户满意度负责，这之间的冲突和撕裂是可以想象得到的。
最好的按期交付激励应该落到平时。如果能够细化到按周评估的里程碑，就给了我们庆祝small win的机会，按周的如期交付也是如期交付，同样值得奖励，甚至如果周四就完成了当周的开发里程碑，周五就可以是一个自由工作时间。
对于软件研发人才，更宝贵的激励是能力的迅速提升。如果研发成员都参与过进度计划工作，尝试过科学拆解研发里程碑，他们将来的能力将不仅仅是更出色的程序员，而是能够管理更复杂项目的主管人才。这种体验，只要是做过相关工作，尝到过胜利果实的研发人员都能够迅速体会到的。这就像在足球赛场上，赢得最终比赛是激励，如果球员能够组织一次有效的进攻，赢得一个进球，或者成功化解和阻挡一次险恶的进攻也都是非常有效的激励。
即刻获取更多敏捷资料
[jinshuju form=VKzSr5 banner=show background=white height=1511]
