技术领导力实战笔记_70_第56讲_|_有了敏捷开发，那交付期限去哪儿了？
你好，我是明道创始人任向辉。
今天想跟大家分享的主题是敏捷开发中交付期限控制的问题，以及其他行业带来的启发。
今天软件行业已经无人不知，敏捷开发实践者也不局限于互联网产品公司。
即使是传统软件开发团队，也十分愿意采纳敏捷开发温和的看板，至于苛刻的期限。
当然，前者要友善的多，scrum能够得到普及，和他宽慰人心的作用是分不开的。
敏捷开发思想的确在改变软件行业面貌。
它让小新团队可以摆脱过于笨重的项目计划，让产品设计和开发避免闭门造车，不至于让程序员的青春年华浪费在那些因为失败而没有投入使用的软件项目上。
它同时也推动了需求方和开发者之间的持续透明沟通，让团队开始意识到高频度的沟通是提高软件交付质量的原动力。
敏捷开发还将工作的起点转换到客户的具体问题解决，也就是user story上，而不是从一个看似完善的产品需求文档出发。
二零零一年，十七名软件工程师发表了著名的敏捷宣言，全文只有寥寥数十个字，内容如下，我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观，个体和互动高于流程和工具工作的软件高于详尽的文档，客户合作高于合同谈判响应变化高于遵循计划。
也就是说，尽管右向有其价值，我们更重视左向的价值。
在应用敏捷开发的数年中，我们自己从中得到了很多的收益。
作为sars软件产品采纳敏捷开发模式几乎是从本能出发的。
至少我们没有和客户的合同谈判，也并非为特定客户交付一个软件项目，而是自始至终的改良属于自己的产品。
在相对稳定的冲刺周期内，一般是两到四周交付，短期可估量的特性通常不是很大的挑战，即便有一到两天的延期和缺陷修复，看起来也没有严重的商业后果。
但软件开发行业的大部分从业者，其实并不是产品开发者，而是服务于提供IT服务的外包开发商。
他们按照合约的要求，需要在固定的期限之内给客户交付可用的软件敏捷开发宣言似乎并不能完全打动他们的客户。
因为期限不仅是开发合同的要件，还会直接影响客户的业务运营。
在一桩典型的外包开发项目上，的确很难应用敏捷开发模式。
即使是像明道这样的产品性公司，也不能完全通过民间开发模式来覆盖所有的开发活动。
对于全新的重构、大型版本的迭代、技术债的偿还、复杂的特性，交付等情况，就几乎不可能在两到四周的时间范围内达成。
我们经过的最漫长迭代周期超过四个月。
虽然这当中肯定有决策失误的原因，但没有产品能够完全幸免。
这样的遭遇，即使像salesforce、 assna atolation这样的高水平saas产品，企业，都有过那些结果糟糕却又不得以为之的长跑性迭代。
我在门中放了一张图图中，展示了敏捷开放模式下典型的任务版模型。
大家可以点击文章查看图中的模型，乍一看是非常直观且有效的开发管理模式，但它只能支持日常特性迭代，在固定周期内完成合适数量的user story.而且在impprocess这个狭狭窄的看中，其实掩盖了过程控制问题。
如果这个impprocess不能在一到两周内完成编码和单元测试，整个冲刺就高概率的会失败。
Screm方法要求在这种情况下进行复盘，找出项目延期的原因，在下一次迭代中针对性改善。
但从很多产品团队的反馈来看，这个原因通常总是被归结为user story放的太多了，或者定义的太模糊了，而很少有去复盘设计开发过程中的进度控制问题。
所以，scrum在带来价值的同时，并不能天然的保证团队准时的交付。
而如果要做到准时交付团队，也不能通过牺牲特性交付量来实现，因为企业永远受团队协作、销售业务需要竞争等要素的压迫。
无论是传统的开发项目还是敏捷开发项目，我们到底应该怎样来实现高成功率的进度控制呢？要为软件行业找到按期交付的办法。
我们可以从其他对工作交付期限有更高要求的行业中寻找灵感。
在众多行业中，建筑工程管理和按单制造业是符合要求的两个行业。
建筑工程受制于客户合约、租赁器材的高成本、人员计划的约束等因素，对于项目执行的节点要求非常高。
项目或者项目内的大节点延期，会带来大额的损失和违约风险。
完整的建筑工程项目计划大多用甘特图绘制完成，其中包含任务的前置关系资源的约束，并且项目计划被允许保存为基线，用来和实际进度定期比较。
同时，通过专业的项目管务软件，例如project项目经理，还要识别出众多任务中的关键路径，在关键路径上的任何任务延期，都会导致整个项目的延期。
相反，如果一个任务不在关键路径上，那么它可能有一定的缓冲空间。
按单制造业根据客户性质的不同，按时交付的刚性有所区别，但整体上都面临客户合同的约束。
即使延期，也必须在合理范围内。
如果是在工业上游的制造业，他们面临的交付压力就会非常大。
因为一旦延期交付，影响的是后续供应链的生产计划。
想象一下，苹果公司对富士康等装配企业的要求。
再想象一下，富士康因此给上游材料、工具、模具等制造企业的交付要求。
因为这两个行业面对的现实挑战，他们自然会因为内在的压力形成一些有效的做法，来实现更可靠的按期交付率。
这些方法和原则呢可能对软件业有所启发。
一、专业的WBS分解，如果打开一个建筑工程项目管理文件，或者一家模具制造厂的工单分解和排程表，外行肯定像看天书一样，因为你没有说过工程专业训练，不了解各门类产品具体的生产工艺和制造程序。
反过来说，如果这两个行业的任务和里程碑分解结果你都看得懂，那就说明他无法起到真正的过程管理作用。
对于外行来说，也许最多能够猜测出来的。
建筑工程里程碑就是打地基结构、封顶、内装修和外装修了。
但这些所谓的里程碑，每一个都可能需要数个月的周期才能达成。
而实际上，一个普通民用建筑的里程碑，就需要数十个分布分项专业才能列举完整分解的WBS任务有大有小。
建筑业的最小工作包从一两天到一两个月不等，无论长短，它都有一个专业衡量，即便它来自的是经验。
判断一座小型建筑的施工准备是两天土方开挖和基底清理要二十天，楼层主体每层要二十天。
这些预计工期在行业内已经成为显性的知识，专业的任务分解工期预估、流程次序和里程碑定义是进度管理的基础。
有了这些信息，我们才能够实现。
第二步，持续跟踪。
二持续的进度跟踪和关键里程碑。
这两个行业都有高密度跟踪进度的时间，而且大多有专人负责。
建筑业一般在项目部有施工日志要求，并根据日志通过专人来负责更新。
进度表制造业则有每日战会一般就在车间里，并有生产经理来管理排程、进度跟踪的基本逻辑。
在两个行业有所不同。
建筑业通过原有的基建对比，来准确协调各分部、施工方、分包商、材料供应商和施工人力资源的准备、入场和验收准备完成。
入场和验收完成，是建筑业各个分部分项工作的核心里程碑。
制造业则紧紧围绕工建依据工建在制造程序上的流转来确定进度，如果进度之后，则要及时修改剩余的制造程序排期。
所以大体可以认为，工建在单个制造工序上的完成是制造业的关键里程碑。
三、遇到问题后的快速会商，软件行业中的从业者经常被一件事情困扰，那就是需求的不明确和经常的变更。
尤其是自由软件产品开发项目，很多软件开发的延期会将责任归咎在需求的含糊和变更上。
我以前总以为像建筑工程这样的项目，不太会有经常变更设计图纸和施工工艺，一般不存在含糊的情况。
事实看起来的确是这样，一座机场可容不得再开工的一半的情况下，突然决定增加一个候机楼。
但是，这并不意味着其他行业不存在变更和其他意外的问题。
实际中局部的施工修改和变更，随时都可能发生施工中，遇到的实际环境和设计条件存在差异，因为环境设备材料、人员能力和工艺有效性带来的突发问题层出不穷。
制造业甚至总结出了人机料法环这几个生产影响要素，分别指人员、机器、材料、方法和环境。
那么遇到问题该怎么办呢？从这两个行业观察到的方法和我的本能直觉一致，集体会商制造业的现场管理和站会不是没有道理的。
在生产过程中发现和产生的问题，最好的解决办法就是在制造现场站在车间里解决。
建筑业也是一样，除了工程师可能要戴上安全帽。
进入施工现场以外，工程项目部也永远都设在施工现场一两百米的距离之内。
我在采访一些工程项目部的时候，发现所有的项目经理办公室都有一个大大的沙发区，项目经理很难离开这个现场，因为他们随时要召集不同职能的人会商问题。
总结一下专业的WBS分解、持续的进度跟踪和关键里程碑，以及遇到问题后的快速会商。
从建筑工程业和按单制造业这两个行业总结出的，这三个要点看起来非常简单，也不难理解。
但反观我们的软件业，在全行业拥抱scrum的同时，似乎丢失和忽略了一些原则。
这也许就是我们管理交付期限更为困难的原因。
受限于篇幅。
本期主要跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带给我们的启发。
下期呢我将跟大家分享软件业具体该采取的做法，感谢您的收听，我们下期再见。