合同是不同机构间的粘合剂，但传统的合同是基于“不信任”和“自保”哲学，而且定额合同（fixed price contract）也未考虑软件开发的不确定因素。按时计价的项目则是不基于已交付的价值收费，这就导致某些团队耗时多，产出少，没多少成果可以展示，但同样可以得到经济收益。敏捷社区一直在寻求更好的解决方案。
Mishkin Berteig 为敏捷合同感兴趣的人士收集了一些关于敏捷合同话题的阅读材料。而且在 Chris Sterling 发表的一篇帖子基础上，他还增加了一些由其本人写的文章的链接。
通读 Mary Poppendieck 、 Alistair Cockburn 和 Martin Fowler 的几篇文章，将会得到一些建议和战争故事（war story），各式各样但众说纷纭。
Mary Poppendieck 在其演讲中，以丰田（Toyota）和通用（GM）如何处理与供应商的关系以及丰田如何得到更多的信任为例，表述了建立信任以及信任带来的货币价值的重要性：
- 丰田占到了四分之三的美国供应商份额而通用（GM）只有不到二分之一的份额
- 与通用（GM）相比，丰田（Toyota）只花费了一半的财力和时间
Alistair Cockburn 总结了 10 个各不相同策略可用于签订合同。其中一个引自于 Bob 大叔的观点很有意思：
（我）赞同为每个完成的故事点付费的同时，还以小时计算工作费用。例如，假设你接手的项目有 1000 个故事点，一个四人团队的速率大约是每周完成 50 个故事点，这就相当于 80 人周的工作量。以每小时 100 美元计算，就需要支付 320,000 美元。那么，我们可以每个小时的费用降到 30 美元，然后再向客户提出“每完成一个故事点，支付 224 美元”的要求。
Martin Fowler 也介绍了一个 ThoughtWorks 公司做过的一个定额合同。当双方签定了一份固定投标合同（fixed bid contract）后，并逐步建立了信任，继而达成了一个更加灵活的收费方案。
在我看来，这个故事（我们大约有半打这样的例子）的关键在于，从一开始我们就寻求公司之间的合作基调（collaborative note），而不是对峙基调（confrontational note）。固定范围合同的最大问题在于，它将甲方和乙方置于对立面，双方互相争论需求是否变了，谁该为这些变化买单。敏捷方法将试图将对峙关系转化为协作关系（客户合作重于合同谈判）。
为什么敏捷合同如此重要，以至于各位专家都对此进行了探讨呢？又为什么没有达成共识呢？没有哪个传统合同能真正适应敏捷开发团队的工作方式——除了在过程上不匹配之外，更重要的是，价值观念上也不符。
在工作中，你是用敏捷合同还是传统合同？那又该如何运用它？是感觉还行呢，还是感觉哪里有点不对味？
查看英文原文： Agile Contracts Require Trust
译者简介： 包亮，一名普通的程序员，喜欢敏捷实践，喜欢"懒惰"，减少重复，尽可能让工作变得简单。几年来，一直通过网络汲取知识，也希望通过网络将知识与人分享 。志愿参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论