Scrum与固定价格合同：真实场景

固定价格合同和Scrum通常被描述为根本不兼容。固定价格合同提前定义范围、进度和成本，并要求承包商遵守这些承诺。Scrum拥抱变化，将产品待办列表视为活文件。将两者结合在一起，就产生了一种需要刻意管理的结构性张力——否则它会管理你。

情况

某省级政府部委向一家软件开发公司授予了一份240万美元的固定价格合同，用于为社会服务工作人员交付案例管理系统。交付时间线为18个月。软件公司提议使用Scrum。部委的采购和法律团队有顾虑：如果范围和价格是固定的，我们如何管理变更？如果团队在进行两周Sprint，谁来决定每个Sprint的内容？

他们的做法

• 有时限范围与变更配额：工作说明书以功能性成果定义范围，而非详细规定实现方式。合同中内置了10%的变更配额：无需正式合同修订，即可通过轻量级Sprint级变更流程替换多达10%的合同范围。

• Sprint级变更控制流程：在每个Sprint结束时，部委的产品负责人可以接受、推迟或标记需求进行范围替换。如果产品负责人想要添加新需求，他们必须确定一个同等规模的低优先级项目进行推迟。

• 季度范围审查：每三个月，指导委员会审查产品待办列表的当前状态，确认与部委不断变化的需求保持一致，并进行超出Sprint级变更配额的范围调整。

• 与合同验收对齐的完成定义：合同为每个主要功能领域定义了验收标准。功能在通过针对这些标准的用户验收测试之前，不被视为已交付。

什么有效，什么困难

有效的方面：第九个月高价值功能的提前交付是真正的成功。因为Scrum团队首先优先处理最关键的工作流程，MVP在完整系统交付前六个月为社会服务工作人员提供了可用工具。困难的方面：合同修订很慢——超出变更配额的范围变更需要四到六周处理正式合同修订。发起人期望需要持续管理——部委的执行发起人难以接受产品待办列表会演变的想法。

对他人的教训

• 在合同允许的情况下，将范围定义为成果而非实现方式。基于成果的范围固定价格合同与Scrum的兼容性远高于详细规定实现方式的合同。

• 在授标前将变更配额谈判纳入合同。签订合同后再尝试增加灵活性要困难得多。

• 投资于客户方的产品负责人角色。部委的产品负责人是使安排奏效的最重要因素。

• 将修订滞后时间纳入进度计划。如果季度审查可能导致需要正式修订的范围变更，请在进度计划中留出滞后时间。

在政府固定价格合同环境中驾驭Scrum需要采购和交付两方面的经验。XNM项目群与项目交付团队支持公共部门客户完成复杂的敏捷交付安排，包括合同结构设计、Scrum辅导和整个交付过程中的合同管理。