合同是不同机构间的粘合剂，但传统的合同是基于“不信任”和“自保”哲学，而且定额合同（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
注册/登录 InfoQ 发表评论