怎样编写精益和敏捷项目的合同

Alan Shalloway 在精益 - 敏捷邮件组中写道：

你有什么比较不错的，可以写进合同（或者工作计划）里，用来跟踪一个软件承包方的进度 / 效能的度量方法推荐吗？【…】然而【问题在于】，这一困惑在敏捷 / 精益 / 看板领域尤为突出。

Jeff Anderson 给出了几条具体条款以作参考：

这些是我刚完成的合同中所包括的条款。我们有幸曾经真正地与客户一起完成过用户故事，因而对其复杂度有所了解。具体数据并不重要，主要给你个概念。 - 周期，我们承诺故事的一个 SLA 汇报周期为 20 天，准确度为 80%

• 产量，我们承诺每月完成 7 个用户故事

为了实现这一点，我们假设待办事项列表中的故事的平均复杂度与已经完成的故事相同。我们每周持续汇报进度，异常值将按照变更请求来处理。有些类型的问题，我们让客户来负责，那些被总共阻碍超过 2 天的故事也会当做变更请求来处理。

Hillel Glazer 已经开始从一个不寻常的角度制定他的合同条款了：

总体来说，我所采取的重构合同的方法，是以我想要如何发挥客户关系的心理图作为起点的。接下来，我想到了客户在付钱给我的时候的感觉。他们付我钱买了什么？更重要的是，为什么？还有，我值得吗？我不希望觉得，他们付我钱是因为我的合同 / 协议规定如此。这使得我更关注价值。不仅仅局限于合同，而是我与他们的相互交流。 再来看看合同里的语言，我发现自己与律师们所用的委托书竟然惊人地（近乎不可思议地）一致。于是，我找了一份入手，搞出了一份“合同”书，约定了提供服务的报酬，“从何时到何时”，“基于客户的需求”以及“对特定的任务和工作量附带相应的期望产出”。（等等）

每一个特定的最终交付物都是独立任务，而不只是简单的文字定义。事实上，我所提供的服务就在协议当中，而任务和最终交付物都是提供那些服务的特有实例。

另一方面， Peter Stevens 认为，一份合同应该包括：

1. 项目以及公司间合作的目标
2. 项目组织架构概述
3. 主要人员
4. 付款和结算
5. 提前以及正常终止条款
6. 任何根据当地法律或者法定惯例所需的法律细节问题