要不是亲身体验，还真无法相信一个软件项目可以提前结项，而且是作为甲方的客户主动提出的。原因是：目前为止他们已经看到并做过UAT的产品，已经足够他们的业务需要。之前合同中的其他需求暂时没有考虑清楚，可以在以后再重新启动。你没有听错，似曾相识是不？Scrum创始人之一Jeff老爷子，在2008年的一篇敏捷合同的老文章Agile Contracts: Money for Nothing and Your Change for Free中就提到过类似的场景。当时我还半信半疑，真的会有这样的客户吗？现在看来还真有。
去年写了一篇文章《从一个乙方视角聊聊敏捷项目》，其实就是这个项目，当时项目差不多刚刚运行半年多。它是我第一次和懂敏捷思想的客户一起工作，并且客户特别要求严格按照scrum的方式运行项目。一年多的时间我们团队始终按照4周一次迭代的节奏和客户一起协商用户故事的优先级、demo、安排用户UAT，搜集反馈并将他们和其他用户故事重新排列优先级。项目一开始用户计划的是3个Release。到目前为止我们马上要完成第一个Release。和最开始赢得项目的标书内容来看，距离原始功能要求还有一定差距，甚至Release 1的内容也已经有不少变化了。但是客户认为已经够用了，他们原本计划的后两次Release的需求暂时没有想清楚，所以他们不想继续开发了。项目可以结项了。
总结一下这个项目中最有感触的几点：
- 最重要的一点：构建甲乙双方的互信。这是所有的前提。
- 客户参与度要高，多从客户的角度提供解决方案，让客户了解项目进展并愿意共担风险。
- 功能/用户故事一定要随时排列优先级，尤其是抓住一切机会让客户参与。例如梳理会上，项目同步会等一切有客户参与的会议都可以考虑。
- 团队永远只做客户认为最重要的功能，而不是我们自己认为重要的或者容易的。避免造成浪费。例如这次如果按照传统的项目方式，根据合同的功能列表基于项目时间来安排开发计划，那可能无法提前结束项目，因为客户的功能可能还没有全部开发完，甚至客户还没有进行全面的验收测试。
- 产品质量一定要过硬，迭代的完成标准要严格执行。能够做到随着每次迭代之后都可以UAT甚至上线。
- 敏捷项目一定要有过硬的工程实践来加持。仅仅follow Scrum的工作方式是不行的。例如：自动化测试，CICD流水线，代码静态扫描，动态扫描以及安全扫描等都要包含进完成标准，并内化到团队每天的工作中，避免积累技术债。例如：这个项目的测试覆盖率达到了80%以上。对于Sonar等扫描工具发现的问题，几乎是随提随改。结果就是第三方安全扫描一次性通过。从侧面客户能真实地感受到的高质量的信心来源。
总结一下Jeff老爷子上面那篇敏捷合同文章中的一些主要的观点。发现2008年他老人家在里面提到的一些关键点我这次真切的体会到了他们的精妙。（感兴趣的小伙伴可以看看原文）
甲方
如果客户在整个项目期间保持参与Scrum团队，如果合同工作的总范围没有更改，客户将能够更改范围，而不会产生任何额外费用。如果从合同中删除同等范围的项目，可以在Sprint边界免费添加新功能。
客户在敏捷项目中角色
- 基于业务价值最大化来排列优先级。
- 双方要互信彼此的评估，并对每次变更都增加合同注释。
- 参与每一次Sprint 计划会，和团队一起选定功能，并回答问题澄清需求。
- 在功能开发前和团队一起制定功能的完成标准。
- 参与Sprint评审会，对完成的和工作中工作项给予反馈。
乙方
对于乙方来说合同中能够明确的内容：
- 合同总价
- 项目时间和物料成本单
- 合同范围
合同条款的解释
提前结束(Money for Nothing)
客户可以在任何Sprint结束时终止合同。终止的标准是当客户认为，继续项目的成本高于收到的额外价值时。客户将向乙方支付剩余合同价值的20%，以行使提前终止。 (Note：这里20%在现实中很可能拿不到，不过项目如果能提前结束，对甲乙双方来说都是有利的。甲方提前结束项目成本，乙方可以将团队投入其他项目中)
乙方承诺在商定的交货日期前交付高质量的80%的项目范围内容。高质量是由双方一起商定的。 只有当客户在项目期间保持对Team Scrum的参与时，才能颁布此条款。
如果双方无法就工作项目估算达成一致，或者客户没有继续参与Scrum团队，合同应恢复时间和材料计费。
变更免费(Change for Free)
如果客户在整个项目期间保持参与度，如果工作的总范围没有更改，客户将可以更改范围，而不会产生任何额外费用。也就是说，如果从合同中删除同等范围的项目，那么可以在Sprint边界免费添加新功能。
