敏捷前沿: 传统采购必将迎来敏捷时代 (思考篇)

在这个乌卡时代，很多甲方仍然执行fix-fix-fix招标政策，即固定价格(fixed cost)，固定时间(fixed time)，“固定需求”(fixed scope)。而供应商们也不得不在很大程度上不确定的条件下投标并"许下承诺”。业务需求不清晰，技术方案不确定，团队成员不确定… 在诸多的不确定条件下签订fix-fix-fix合同，甲方和乙方的信心指数都不可能太高，甚至没有太大信心！

有的组织正在亲历难言之隐。。。

有的组织正在寻求突破之道。。。

有的顾问正在研究落地方案。。。

(还有与我同行的伙伴吗？)

从2017年起我开始思考“敏捷合同”这条未来之路，当时写下了实施“敏捷合同”的几个ideas，并随着更多的实践而不断演进：

• 运行Program Increment，即3～5个迭代，以PI为周期签合同

• AC就是合同的一部分，一开始AC先给出MUST支持的业务场景，业务KPI，以及非功能需求，比如性能指标，如果有对标系统更好

• 每一个业务需求尽量定义为一个PI内可以完成的颗粒度，按故事点或者T-shirt相对估算，即只有复杂度和工作量相对大小的估计，不做精确的人天估算 (实际上也根本估不出来！) ⚠️注意，乙方需要拿出过去曾经完成的类似系统的工作量和复杂度估计作为参考 (yesterday's weather)

• 选择demo周期 (比如每2～3周)，作为合同里的规定动作

• 组建joint team负责交付，比如甲方出业务专家，乙方出技术专家，项目层级联合治理

敏捷宣言提倡“客户合作 高于 合同谈判”，那么甲乙双方先按照PI时间箱和固定人头数签一个开发服务合同，不是fix-fix-fix软件交付合同。甲乙方共同探索不确定的需求并定义价值，共同制定可执行的PI计划和迭代计划，共同负责交付并收集反馈，进而快速调整和改进。⚠️注意，完成不了计划是双方共同的责任，此处风险共担！可以随时止损，迭代周期足够短。

敏捷宣言提倡 “响应变化 高于 遵循计划”，那么乙方敢于签订需求范围可变的敏捷合同吗？如果甲方预算是固定的，那么双方应定义以MVP为单位的推进方案，在迭代中不断清晰化需求范围，尽早砍掉不合理需求、次要需求。

敏捷宣言提倡“工作的软件 高于 详尽的文档”，那么乙方敢于按合同规定的固定周期 (比如每2～3周) 在客户的测试环境中demo working software吗？这时，持续集成、持续部署、自动化测试这些工作量应作为工程需求进入项目范围。

敏捷宣言提倡“个体和互动 高于 流程和工具”，那么甲乙双方能否在合同期内密切协作，每天都有面对面的机会，为了达成PI目标而透明高效地一起面对问题、一起解决问题。

我认为，以上思路可以解决fix-fix-fix合同的主要矛盾。同时，我开始寻找现有的成功案例。。。且听下回分解吧～～