10 KiB
第56讲 | 有了敏捷开发，那交付期限去哪儿了？
你好，我是明道创始人任向晖，今天想跟大家分享的主题是敏捷开发中交付期限控制的问题，以及其他行业带来的启发。
今天，软件行业已经无人不知敏捷开发，实践者也不局限于互联网产品公司，即使是传统软件开发团队，也十分愿意采纳敏捷开发。温和的看板之于严苛的期限，当然前者要友善得多。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.遇到问题后的快速会商
软件行业中的从业者，经常被一件事情困扰，那就是需求的不明确和经常的变更，尤其是自有软件产品开发项目。很多软件开发的延期会将责任归咎在需求的含糊和变更上。
我以前总以为像建筑工程这样的项目不太会有经常的变更。设计图纸和施工工艺一般不存在含糊的情况。事实看起来的确是这样，一座机场可容不得在开工了一半的情况下突然决定增加一个候机楼。但是，这并不意味着其他行业不存在变更和其他意外的问题。
实际上，局部的施工修改和变更随时都可能发生，施工中遇到的实际环境和设计条件存在差异，因为环境、设备、材料、人员能力和工艺有效性带来的突发问题层出不穷。制造业甚至总结出了“人、机、料、法、环”（分别指人员、机器、材料、方法和环境）这几个生产影响要素。
那么遇到问题该怎么办呢？从这两个行业观察到的方法和我的本能直觉一致——集体会商！
制造业的现场管理和站会不是没有道理的。在生产过程中发现和产生的问题，最好的解决办法就是在制造现场，站在车间里解决。建筑业也是一样，除了工程师可能要带上安全帽进入施工现场以外，工程项目部也永远都设在施工现场一两百米的距离之内。
我在采访一些工程项目部的时候，发现所有的项目部经理办公室都有一个大大的沙发区，项目经理很难离开这个现场，因为他们随时要召集不同职能的人会商问题。
总结一下，专业的WBS分解、持续的进度跟踪和关键里程碑，以及遇到问题后的快速会商，从建筑工程业和按单制造业这两个行业总结出的这三个要点看起来非常简单，也不难理解。但反观我们的软件业，在全行业拥抱SCRUM的同时，似乎丢失和忽略了一些原则。这也许就是我们管理交付期限更为困难的原因。
受限于篇幅，本期主要跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带给我们的启发，下期，我将跟大家分享软件业具体该采取的做法。感谢您的收听，我们下期再见。