合同是不同机构间的粘合剂,但传统的合同是基于“不信任”和“自保”哲学,而且定额合同(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
评论