【IT168 分析评论】

    合同是不同机构间的粘合剂，但传统的合同是基于“不信任”和“自保”哲学，而且定额合同（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）。固定范围合同的最大问题在于，它将甲方和乙方置于对立面，双方互相争论需求是否变了，谁该为这些变化买单。敏捷方法将试图将对峙关系转化为协作关系（客户合作重于合同谈判）。

    为什么敏捷合同如此重要，以至于各位专家都对此进行了探讨呢？又为什么没有达成共识呢？没有哪个传统合同能真正适应敏捷开发团队的工作方式——除了在过程上不匹配之外，更重要的是，价值观念上也不符。

    在工作中，你是用敏捷合同还是传统合同？那又该如何运用它？是感觉还行呢，还是感觉哪里有点不对味？