转载

为确保敏捷行为的实施而制定合约

Martin Kearns在澳大利亚墨尔本的第一会议上发表了一场关于敏捷合约的演讲。InfoQ对他进行了采访，内容如下：敏捷合约与瀑布项目的合约有何不同之处，合约该如何应对范围内的变化，在开发过程中的主要干扰或延误，可以做些什么来确保合约能提供敏捷行为的权利和帮助所有那些相关的人在基于敏捷思维的基础上一起工作，当机构想要在敏捷软件开发中使用合约时律师所起的作用，以及为了能够使用敏捷合约，机构必须做什么。

InfoQ：为什么您认为合约对敏捷开发来说很重要？

Kearns：一所机构，无论何时需要第三方的参与来传送结果、提供支持，增强所作用和增加金融业务都是交易的一部分，而合约是成功的基础。最重要的是合约代表着该途径的意旨、预期行为和责任制。

InfoQ：敏捷开发的合约以何种方式不同于瀑布项目的合约？

Kearns：最重要的不同是在支持文件中，总是试图删除瀑布项目的变动，许多费用和重点都在于后续变化（即范围蔓延），这是不可避免的，无论计划多么提前完成。这就自然而言地创造了一种不利关系，即双方都努力专注于他们自己的最大利益。

敏捷合同开始于允许项目失败的构想，因为合约体系必须允许双方基于一个可怜的商业理念构建一个合同。太多的项目因为某一方的自身利益而持续。还需要有一个延伸的退出条款，因为一旦传输的价值比迭代的成本还要少，那就没有理由继续了。在栅栏的另一边（供应商），如果客户行为和思维不支持敏捷方法，那么在不产生损失的情况下，退出的能力就是必不可少的。对敏捷合约来说，共同的责任是必要的，不能降低到一种单方的交易。

InfoQ：在大多数“传统合同”中，必须交付的范围是一致的。在这段时间里你想用敏捷来接受变化，适应范围。敏捷合同怎么支持呢？

Kearns：在第二到第四次的任务迭代中，我努力确定的一件事是对积压任务以及用户故事的周期时间的自信度，为了敏捷合同的成功，我们需要对计算交付混合项目的成本有一个很好的处理。为了做到这点，我通常喜欢参与Time 和Materials建设中最初的冲刺。

一旦我们有可以接受的自信水平，我喜欢用工作来确定以固定成本可以实现的很多功能和/或故事点。一旦认为这是“可行的”，我就可以像进入我的夜间俱乐部，“1进1出”。我改变的方法就是一直说“是”，客户可以提高项目的最高限度或者删除大小相等的故事/功能。很明显当项目的最高限度得以提高，成本和更多可能的时间也会提高。

InfoQ：您能就敏捷合同是怎么处理开发过程中的主要干扰或者延迟，举个例子吗？

Kearns：我最喜欢的方式之一是创造一个障碍的气泡图，这样我可以追查一下随着时间延迟的轨迹。一旦图上出现气泡，它就会随着障碍存在的时间变长，开始向右移动。随着因为无所作为而引发的相关交付影响变得越来越显著，我们就会“冒泡”。一旦气泡离开容忍边界，相关成本（气泡大小）就转变成一个变化请求。

当项目延迟的影响不再被目前的合同所忍受，那么它就必须通过合同修正处理。这可以通过减少故事点的限度，或者增加项目支出而产生。正如我们所看到的气泡每天超出项目容忍度，而我们在它们成为财务问题之前就提供最大的领先时间来解决问题。

InfoQ：在您的演讲里提到敏捷合约应该确保敏捷行为帮助所有那些相关的人在基于敏捷思维的基础上一起工作。您能就此详细说明一下吗？

Kearns：我喜欢在我的合约里看到的一件事是，早期失败是安全的。如果我作为一个供应商，已经证明了你的项目假设是错误的，期望值不可能达到，因为我得到报酬以及我的客户在能够重新分配项目资金到其他地方上看到价值，是很重要的。仅此一项在最初的讨论中就产生了一个不同的重点，早期的迭代作为结果，也更加重视起来。

另一件关于敏捷合约的事是，因为范围不能高度提前定义。传统的供应商交付也设计为逐渐形成以及独立于项目其他元素，以保护供应商的利益。不幸的是，项目成果是相互依存相关的，需要重新设计敏捷合同条款。一种可以解决的方式，一种可以设计正确行为的方式，是各方“以原则工作”的必要手段。这一责任必须在两个机构中共享。这对我而言已经是我在对这种合同安排负责的律师间的合作中，学会欣赏的东西。因为原则共享，它提供了一个公平的与他人交战的游戏领域。这样原则的一个例子是将明确地显示由供应商团队在商业决策上要求的响应率，以实现目标的发布日期或者连续的对市场的交付速度。

在合同计里嵌入敏捷思维有很多好处。我想提及的最后一件事是供应商管理在这种情况下的作用。随着我们在合同评审（2-4周）上有更快的节奏，会持续关注于结果以及迭代的交付产品如何增加价值和/或认知。通过正式的循环反馈，定期重新调整关系，透明度也以此鼓励各方关注结果，互惠繁荣，因为成功是共享的。