讲清楚混合交付：何时把瀑布与敏捷结合起来
如果你曾经做过这样的项目：楼宇必须按固定时间表完成报建和浇筑，而楼里的软件却随着用户反馈不断变化，那么你已经遇到过混合交付的典型情形。到2021年初，团队突然分散在各自的厨房和客房里，如何规划一项既部分可预测、又部分未知的工作，便不再是纸上谈兵。混合交付正是务实的答案，而且它比那些行话所暗示的要简单。
两种方法各自的真正前提
瀑布与敏捷与其说是对手，不如说是对“你能提前知道多少”所下的不同赌注。理解各自下的是什么赌注，正是作出正确选择的全部关键。
瀑布假定需求稳定且可知：你界定全部范围、规划次序、分阶段交付。它奖励可预测性和清晰的依赖关系——想想报建、地基、结构。
敏捷假定需求要在使用中才会被发现：你以短周期工作，拿出真实可见的东西，再做调整。它奖励学习和低成本地改主意——想想一款功能不断演进的面向用户的应用。
错误在于把它当成针对整个项目的性格测试。真实的项目几乎总是同时包含这两类工作。
混合交付究竟如何运作
混合交付意味着按工作的性质、而非按立场来拆分项目。把可预测的部分分阶段规划，把不确定的部分按迭代推进，再通过共同的里程碑和一份统一的整合进度表把两者连接起来。要点是让每种方法都用在其前提成立之处。
按确定性梳理工作。 列出各大工作流，并对每一条发问：我们现在就知道“完成”是什么样，还是要边做边摸清？决定方法的是这个答案，而非偏好。
把固定部分作为阶段来规划。 凡是范围、法规或依赖关系确定之处——采购、基础设施、合规——设定有先后次序的里程碑，并按经典方式管理。
把演进部分按迭代推进。 凡是价值要靠反馈发现之处——界面、服务、内容——以短周期工作，每次都产出可用、可检视的成果。
在接缝处把两者连接。 界定迭代工作必须对接固定期限的衔接点，并以一份总进度表中清晰的整合里程碑来守护这些接缝。
选定单一的汇报节奏。 把两条工作流汇总为一个状态视图，让管理层看到的是一个项目，而不是两套方法在会上争吵。
混合交付的难点不在方法本身，而在接缝。一个可预测的硬件里程碑依赖于迭代中的软件，或者一笔固定的资金期限依赖于仍在演进的范围，正是这些地方让混合项目吃紧。尽早把这些依赖关系点明，其余便水到渠成。
2021年的远程条件让混合交付更为普遍，而非更少，因为分散的团队需要明确的交接，而这在共用办公室时代往往靠走廊里的一句话就解决了。混合不是回避抉择的办法，而是一种纪律：为每一块选对方法，并诚实面对它们的交汇之处。
如果您正在权衡如何为一个兼具固定与演进部分的项目搭建结构，XNM的项目群与项目交付咨询可以帮助您把接缝画在正确的位置。