撰写适配敏捷的合同：一份本周即可使用的现场清单
如果你的团队采用 Scrum，但合同却要求范围冻结、价格固定、交付日期在写下第一行代码之前就已敲定，那么二者其实在悄然对抗。合同假设你能预先预测整个产品；而 Sprint 假设你在推进中不断学习。经历了供应周期、人员编制乃至办公地点都按月变动的两年之后，假装一切都能事先锁定的代价，从未像今天这样清晰。
让合同更适配敏捷并不需要法律学位，只需改变协议所保护的对象：不再保证一份冻结的功能清单，而是保证一种工作方式、一种决策节奏和一个清晰的退出机制。下面这份清单，你本周就可以带到下一次采购或供应商洽谈中。
协议中应写入的内容
固定节奏，而非范围。 约定 Sprint 时长、买方参加的 Sprint 评审，以及由买方产品负责人排序的产品待办列表。待办列表可以变，但检视与重新决策的节奏不能变。
按带上限的工时计费，或按 Sprint 计费。 购买一段固定时间的产能，而非一份冻结的功能集合。上限让财务安心；任意 Sprint 后可停止的权利让各方都安心。
将产品负责人角色写入合同。 明确由谁排序待办列表、由谁在评审中验收工作。拖垮远程与混合项目的，往往是决策延迟，而非开发速度。
对“完成”只定义一次，适用于一切。 在合同中引用书面的完成定义，使“做完”不必在开票时逐项功能地争辩。
内置无过错退出机制。 允许买方在 Sprint 边界经预先通知后终止合作，并保留此前产出的全部可用软件。正是这一条款，让增量交付变得诚实。
应当略去的内容
附件中详尽的功能时间表——一旦你学到新东西，它就成了变更单的制造机。
与固定上线日期挂钩的罚则，而该日期是在调研之前猜出来的。
要求在最后进行一次性大验收的审批关卡，这违背了逐个 Sprint 评审的初衷。
缺乏节奏支撑的含糊“行业尽力而为”措辞——它谁也保护不了。
一个有用的检验：通读草稿，自问如果到了第 3 个 Sprint，团队发现最有价值的功能在签约时根本没列出，会发生什么。好的敏捷合同会把它变成对待办列表的一次普通重排；糟糕的合同则把它变成一场纠纷。合同应当让学习去改变产品，而不必改变合作关系。
这一切并不意味着合同变得松散。它们在对的地方——节奏、角色、验收和退出——变得具体，而对那些第一天谁都无法诚实锁定的事情，则有意保持沉默。
重写合同，使其为价值买单而非与你的交付模式对抗，越早做对越好——XNM 的项目群与项目交付咨询帮助公共部门与重大项目团队构建经得起考验的协议。