敏捷合同入门（下）

本文源自——《精益和敏捷开发大型应用实战：利用大规模Scrum进行大型、跨地区的离岸产品开发》

作者：Tom Arbogast, Craig Larman, Bas Vodde

请将您对未来版本的评论发送给我们

网址为www.agilecontracts.org.

注意：请到网站查看最新版本

分享URL（而不是文件）以保持最新版本

www.agilecontracts.org

Tom Arbogast是一名结合了敏捷原则、系统思维和精益思想知识的并且在IT项目管理和敏捷合同具有多年经验的律师。他主要从事了以下三方面的工作：1）为外包IT服务的客户担任合同律师；（2）作为IT外包商（“供应商”）的专业律师；和（3）为供应商开展业务（利用销售协议来影响合同内容）。Tom领导ClearEdge Partners公司的专业服务和法律业务团队，专门从事IT、并购、谈判、交付管理和运营。他曾担任英国电信的副总裁以及电信和技术领域的执行和法律职位。他曾在私人执业律师事务所工作过，并在加拿大最高法院提起诉讼。他毕业于科罗拉多大学和不列颠哥伦比亚大学法学院。

Craig Larman和Bas Vodde是（1） 《精益和敏捷开发大型应用实战》 （Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development）和（2）《精益和敏捷开发大型应用指南》（Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum）的作者。

他们作为组织设计顾问，以及作为大型系统产品开发，在离岸和多地开发中采用精益思想和敏捷开发的团队中的管理和工程教练。

译者：何强、Charlie Qian;何强（CSP/CLB)，北京三星研究院敏捷教练，近十年外企研发管理经验，敏捷变革的爱好者和践行者。

Charlie Qian(CSM/CLB)，Scrum Master，目前就职于阿迪达斯数字化中心，敏捷实践者。校审：申健Jacky(CST/CTC/CLP)，自2007年开始在诺基亚西门子通信实践敏捷开发，大规模Scrum(LeSS)亲历者，现任优普丰敏捷学院合伙人。

以下为正文

第三部分：合同模型

避免……固定价格、固定范围（FPFS）合同

固定价格、固定范围——甚至更糟糕的，固定周期的合同和项目会让供应商和客户趋向双输的糟糕情况；客户经常不知道他们真正需要什么，供应商也很容易有亏损。

在带着价格和范围约束条件下去交付东西的时候，供应商经常会降低交付物的质量，包括降低代码质量，减少测试等等。

所有这些都导致客户未来成本的增加，他们最终将不得不为过去的错误付出代价，他们需要后续提起变更请求（注释14），以获得他们真正需要的东西，而且低质量的软件和高昂的“技术债务”会增加额外的维护支出。

固定价格出价已经将大的风险意外事件（占预估成本的高达50％）添加到总体价格中——此溢价通常隐藏在工作量估算中（注释15）。

注释13：122.50美元的价格依据：考虑到人天费率为150美元，项目需要35,000人天和100,000故事点，122.50美元就是总价为17,500,000美元的每个故事点的价格。

注释14：印度的传统离岸外包商非常享受这种变更请求模式，因为他们从中获得了很高的利润; 他们非常清楚他们的FPFS合同无法交付客户真正需要的东西，他们期待他们通过开发客户不满意的系统之后，客户付出需求变更费用来满足他们真正的需求。在印度，他们称此为“租金”。

这将导致项目执行期间双方透明度降低并且双方博弈的增多，因为供应商希望将此溢价作为利润而不是正常的预算消耗。此外，由于签署的早期需求规范几乎无法包括真正的需求，（这主要是由于这个固有的复杂领域中的多种混合因素），供应商在印度能够产生进一步的收入，外包商称之为“租金” ，亦即通过一系列后续变更请求，每个变更请求都是在超出原定价格以外的额外成本。

在各种局部优化的伪装之下，固定价格项目得到推崇（而不是以项目成功为目的）; 我们鼓励专业律师注意这些：

• 作为客户，最重要的是了解财务报告或预算的成本（注释16）
• 作为供应商，最重要的是确定总订单价值。
• 作为销售人员，最重要的是确定总订单价值，从而能够获得全额佣金。
• 作为管理者，最重要的是避免在项目上浪费时间。管理者需要的是订购一些东西，在没有“干扰”的情况下转向其他工作，然后在项目最后能够成功得到那些东西。

但有些公司，出于某种原因，仍然在尝试那种方式。在那种情况下，我们得到的最常见的问题是，“你如何使用敏捷方法进行固定价格且固定范围的项目？”首先，它是可能的; Valtech India和其他敏捷外包供应商已经这样做了（因为市场需求） ——尽管这是他们最不喜欢的模式。

FPFS和敏捷方法问题背后经常存在两个误解：

• 第一个误解是，当使用敏捷方法时，在第一个迭代开始前无法知道或者估计整体项目发布需求。这是错误的。其实，在Scrum中，在第一个迭代开始之前，是可能有初步的发布规划（也叫初步创建产品待办清单），在这个时候所有确定的发布需求就已经被澄清和被估计。
• 第二个误解就是用敏捷方法时，需求就必须改变。这也是错误的。其实，所有的敏捷方法都给学习和改变提供了机会和机制，但是并不是必须要求去改变。Scrum也可以被用于一个确定内容的发布规划中，而且仍然可以提供它的优势。这需要感谢工作方式、技术、测试结果以及小规模增量带来的更频繁和更高效的反馈。

使用Scrum或任何其他方法，有一些关键点可以避免在使用FPFS项目时造成破坏：

注释15：由于这个原因和其他原因，FPFS合同也被称为“最晚日期，最高成本”合同。

注释16：参见配套书中“组织”章节的“超越预算”部分，以替代传统的预算程序。

• 针对大型项目进行详细的前期需求分析，定义完备的验收测试集，所有需求的熟练工作量估算方面，尽可能地进行尽职调查，并且所有这些都需要由经验丰富的人员完成。
• 不允许对要求或范围进行任何更改，或仅在同等工作量条件下允许新需求取代现有需求。
• 增加合同价格的余量，以反映FPFS软件开发中固有的重大风险——这个领域充满了发现，可变性和令人讨厌的意外。
• 聘请拥有卓越的技术，经验丰富的领域专家。

注意，长期的、亲力亲为的优秀工程师，以及经理作为工作中的老师去辅导团队，这样的精益文化才能提供给人们经验成长的培养环境，从而减少FPFS项目风险。

付款时机

FPFS的付款时间通常是每次迭代之后，并且在最后一次付清（如果以前没有用完总付款）。每次迭代付款的数量是项目总价的固定百分比，或者是按照预估的总迭代数，或者，如果项目也是固定的那么就按预定义好的迭代数。

使用Scrum实现FPFS项目的灵活性

在使用Scrum执行FPFS项目时，有几个低风险区域提高了灵活性; 有能力做到：

• 使用同等工作量的需求来替代现有需求
• 这个可替换性选项非常重要
• 改变固定需求的实现顺序
• 每次迭代改进“完成的定义”

Schwaber（注释17）还建议了另外两项合同条款：

• 客户可随时要求提供额外的版本发布，并以T＆M定价
• 如果项目提前获得满意，客户可以提前终止合同，并向供应商支付剩余未开票价值的20％。

注释17：Ken Schwaber是Scrum敏捷方法的共同创建者。

专业律师需要意识到这种灵活性的存在而且应该在FPFS合同的条款中表达。

我们应该采用顺序进行的传统方法进行FPFS项目吗？

有一个问题有时候会被问到，“如果我们必须进行FPFS项目，我们应该使用敏捷方法还是顺序生命周期（瀑布……）式的传统方法？”

有证据表明，与迭代、增量或敏捷方法相比，顺序生命周期开发往往与更高的成本、更慢的交付、更低的生产率、更多的缺陷或更高的故障率相关。[MacCormack01，Reifer02，DBT05，MJ05，CSSD05，AV07，PRL07]。

因此，使用传统的顺序开发方法将是你将FPFS项目变得更糟的最后一个事情。

恰恰相反：如果你使用Scrum执行FPFS项目，你将能够减少浪费，减少排队队列，减少在制品数量，并且你将获得有关项目真实性质的早期现实反馈。根据早期反馈，你可以提前调整而不是项目延期。特别是在FPFS项目中，你想要尽可能快地知道坏事; 敏捷方法增强了反馈。

在FPFS项目上使用敏捷方法有一个更微妙的优势：它可能演变为面向协作的灵活项目。许多客户利益相关者都明白FPFS模型可能无法解决他们的问题，但是被强制施加于他们——可能是法律或财务部门。一旦客户开始直接与敏捷软件供应商就着表面上看起来固定的项目进行交互，并且每两周快速交付一个完善的解决方案，而且能够改变迭代顺序——实现其固定需求的顺序（并替换需求） ，这样客户与供应商建立信任和协作，“固定”可以变得“灵活”。客户慢慢就会放松警惕，看到“客户协作优于合同谈判”的优势，并同意不太关注原始定义而更多关注进化发展以满足他们的实际需求。

最后，在使用Scrum完成初始FPFS合同之后，客户可能愿意为后续项目使用其中一种备选敏捷合同模型。一些敏捷外包商已经与客户一起体验了这些积极的模式。

尝试……可变价格变量范围渐进式合约

在最纯粹的形式中（注释18），渐进式合同意味着完全灵活的范围，后续开发范围都会在后续迭代中自适应地定义。他们是敏捷项目的理想候选。

注释18：称为开放式可变范围，开放式增量或不确定交付无限量（IDIQ）的变体。

[Poppendieck05].它们是主服务协议或大框架合同，它们定义了每次迭代的总体关系和定价方案，但没有定义范围。渐进式合同没有定义总固定项目价格——尽管一种变化具有项目上限。

由于每个迭代都会有一个可工作的系统，所以客户风险受到很好的控制，因为客户合同终止可以在任何迭代结束时发生。如果双方都对这种关系感到满意，那么渐进式合同项目可以无限期地继续下去。

通常（但不是必需的）在每次后续迭代之前，客户和供应商定义即将到来的下一个迭代的目标，有时候是通过验收测试的测试用例。有时在Valtech是在第N-2迭代期间澄清第N个迭代的目标。

每次迭代的定价运行各种变化：每次迭代的固定价格，每次迭代的T＆M等等。

变体——在Valtech，限价变动范围累进合同十分常见; 它设定了项目总价上限。每个迭代的定价是任何变化，例如T＆M。同样，频率是一种限价变动范围累进合同，带有无约束的发布待办清单，由各方在合同签署前创建发布目标的待办清单。该待办清单包含在合同的附录中。但是，各方都同意原始待办清单中没有任何内容具有约束力。

（这就是传统Scrum）为什么在合同撰写之前就要创建无约束的发布待办清单？它被用来估计大概的发布上限，同时提供一个开始节点的共同愿景。在先前单独的合同接触阶段，去创建这个无约束发布待办清单也是非常常见的现象。

渐进式合同是敏捷外包商和与之建立信任关系的长期客户的常见合同模式。一种经常发生的模式（不是推荐）是

1.   早期合约是固定价格，固定范围的变体

2.   之后，转向渐进式合约，简单的T＆M或每次迭代设定上限的的T＆M

尝试……增加项目灵活性和合同的变量

范围可变、价格可变、日期可变等纯累进式合约都是灵活的。任何变量（范围，价格，日期）的灵活性都各不相同，具体取决于客户和供应商之间的信任和协作水平，或者受到政府监管等其他限制。敏捷外包商创建的合同变更包括以下内容：

上限价格（注释19）、范围可变——在上一节已经进行过讨论

上限价格、部分范围确定——只有小部分需求是确定，这样可以给学习和调整留一些空间。

固定价格、范围可变——这种范围可选的合同[BC99]是这种模式的一种变种，并且结束日期固定。

灵活合同中的约束风险：多阶段模型

多阶段模型在第39页的“尝试…多阶段变量模型框架”一节中进行了描述。简而言之，它通过一系列较短的合同实现了更长的项目。

如果双方信任度低，客户可以通过使用一系列短期，灵活的合同来约束他们的风险（和恐惧）。例如，长达一年，固定价格、固定日期、可变范围的合同可能会被惶恐地看待。但是，一系列的两个月、固定价格、固定日期、可变范围的并且能够在任何周期结束时终止的合同——看起来更加合胃口。

另外，在几个合同周期之后，双方慢慢建立信任。此时，客户可能会转换为每次迭代的T＆M定价的简单累进合同。

注释19：

在本节中，价格是指整体项目价格。

分享或适应性地改变损失/增益或风险的模型

对于双方来说，项目都有潜在的风险和回报，而且这些可能会随着时间而改变。例如，FPFS项目似乎将大部分风险转移给了供应商，尽管由于之前确定的原因这是一种错觉。

下一步探讨的一些框架已经明确制定出来，用来分担这些风险和回报，并将风险转移到适当方面从而能够采取措施（注释20）。

在最好的情况下，这些框架提高了各方动机的一致性，因为它们都具有“自身的利益在其中”。同时，它们可以改善基本的公平性和关系建设。这种理念是双赢方法核心概念，它将创造信任和关系，促进进一步的合作业务。

但合同本身并不能创造信任和一致性。在最糟糕的情况下，这类合同被滥用，成为了指责游戏的一部分，将损失转移到另一方并且只能一方获益。

这些框架包括

• 目标成本
• 多阶段变量模型
• 利润共享

尝试……目标成本合同

目标成本合同有助于对齐双方的动机。它们被用于丰田的供应商，体现了精益思想中支柱之一——尊重人，丰田试图在信任和相互支持的基础上与供应商建立稳定的长期关系。

该模型假设了一个初始的发布计划步骤，在该步骤中确定了整个项目范围。这是确定目标成本第一阶段的一部分：

1.   在客户和供应商之间的协作中，识别、分析和估计所有可能的项目要求。

2.   在协作下，估算项目期间的变更或范围增加的成本。这很重要;因为目标成本合同必须尽可能实际地考虑总体工作量和成本。

3.   从这两个要素中，确定目标成本。

4.   根据目标成本（例如，目标成本的15％）计算目标利润。

5.   与客户分享所有细节和结果（这很重要）。

注释20：这通常意味着将与需求相关的风险（“做什么”）置于客户手中，并将实施和技术相关的风险（“如何做”）置于供应商手中。

在第一阶段，这个模型成功的关键是(1)通过熟练的尽职调查产生的尽力服务的估算，而不是想当然估算的目标成本，以及(2)(供应商)公开成本核算，以便客户透明地查看导致计算目标成本的所有细节。

目标成本合同中的第二阶段是项目执行——例如，使用Scrum。项目双方很快就会意识到，成功的关键实践是跟踪所有实际成本（例如，开发人员花费的时间，会议时间，硬件成本），并以近乎实时的方式透明地与客户共享所有成本信息。

目标成本合同的关键方面是根据实际成本和目标成本之间的差异而调整的、双方共同承担的损失/收益公式。该公式有几种变体。

一个简单的例子：

调整值=（实际成本-目标成本）*客户分担成本差值的份额

客户支付数目=目标成本+目标利润+调整值

如下所见，调整值有可能为正，也有可能为负。

假设协议是任何成本差异的60％份额是给客户的，40％份额是给供应商的。那么：

如果成本高于估计，供应商和客户都会分担损失：供应商的利润较低，客户承担部分成本负担。如果节省成本，双方共享收益：供应商的利润更高，客户支付的费用低于原始目标付款。

这意味着双方都会尽可能积极推动减少项目期间浪费的方法，尽管这一点无法保证。

付款模式的变化

合同起草人已经引入了很多付款方式的变化，包括：

• 有上限（天花板）的客户付款数目
• 如果超出目标成本，降低供应商的单价

可调整的目标成本和目标利润

支持敏捷和迭代价值的目标成本合同的另一个基本要素是通过各方之间的持续谈判来调整目标成本（和利润）的能力。成功调整目标成本的关键包括

• 供应商的高透明度和近乎实时、公开的项目账目，以便客户了解供应商的真实费用状况
• 客户和供应商共同努力的精神，不断改进
• 这是丰田在[ISV09]上持续不懈努力的部分
• 合同中双方就目标成本调整准则早日达成协议
• 一个适当的调整周期，以避免对调整过度反应，或在调整时使用过多的开销; 例如，每迭代调整一次可能太过频繁
• 利用测试驱动开发来进行验收，减少歧义

这些实践能够减少但不会消除正在进行的重新谈判期间的争论，因为调整的问题通常具有内在的模糊性——类似“这是一个缺陷还是一个需求？”

一个小组报告（注释21）说，以下事先商定的调整方案减少了争论：

注释21：在[EMH05]中描述的是一个关于敏捷项目的目标成本合同的故事。

尝试……多阶段变量模型框架

随着时间的变化，项目的不确定性或风险状况同时也会发生变化，理想情况下合同双方会对此进行改善。多阶段框架合同中可以反映出这些变化。任何一个阶段都可以使用任何合同模型：FPFS，渐进式，目标成本等。

在Valtech的多阶段变量模型示例反映了常见的Scrum模式:(1)创建初始产品待办清单(2)自适应迭代开发。这是一个涉及23个国家的项目干系人的大型B2B解决方案：

• 第1阶段 – 固定价格，固定期限，可变范围。从本质上讲，这是初始创建产品待办清单。此阶段的输出是产品待办清单,或者更确切来说，是一个产品发布待办清单, 以及包括基于研讨会和团队分析的各种业务分析（市场分析，愿景……）文档。虽然合同中确定了要交付的特定文件清单，但分析范围或内容各不相同。
• 通过产品发布待办清单，成本估算变得可实行，因此……
• 第2阶段  – 渐进式合同，包括每次迭代的T＆M，设定发布上限，非约束性产品发布待办清单，固定期限。第2阶段基本上是一个经典的Scrum项目：原始待办清单中的任何内容都没有被限定，但它用于估计和约束发布项目成本，提供初始概览，并定义在第一次迭代中启动该做什么。

为什么要使用这些多阶段模型而不是简单的渐进式合同呢？通常情况下，这么做的激励因素是(1)双方缺乏信任,(2)监管限制,(3)一方相信他们可以节省更多资金或更好地降低风险,(4)定义项目愿景的需求，高层次概览性需求，或后期成本考虑（以及此项工作本身的工作量很大），或(5)“优化”次要目标(在项目成功之外)，例如更好的成本可预测性。

[Larman03]中的另一个例子：

1.   第1阶段 – 固定价格部且分固定范围，用于前三次迭代（固定期限）。“强制”的固定范围较少（例如，占可用工作量的20％），于是在不确定性较高时为可变性和探索留有足够的空间对客户和供应商来说，风险都是有限的，并且双方都对第2阶段持续性项目的性质有了很多了解。

2.   第2阶段-FPFS，期限可变。由于知识的增加以及在第1阶段中某些变化源的减少，供应商在承担FPFS阶段的风险降低了。

结论

 “当涉及双方合作合同时，我们怎么可能做敏捷开发？”这是我们经常被问到的一个问题。但关键问题不在于合同，而在于合同编写者和他们所服务的客户——这反映出大家相信成功是更多地围绕合同谈判而不是围绕客户协作，或项目成功并不是合同事务的目标。这里我们重申一个系统思考的警句，“不指责”，这句话暗示系统中人的行为是由系统塑造——在本例中，由于鼓励部门孤岛、局部目标（和奖励）导致本地优化以及传递出来的微妙信息，“律师不需要了解运营细节或研发的新方法，那是别人的工作。”

此外，当被问到这个问题时，“合同”通常被用作“固定价格固定范围”合同的同义词，但这根本不是必然的——在现实中有各种各样的合同模型，包括可变范围渐进合同等。

在制定合同时，法律专业人员有责任考虑双方的信任和合作崩溃的后果以及其他问题。正如合同律师需要更多地了解精益和敏捷原则一样，其他各方需要更多地了解律师必要且有效的关注点。正如跨职能开发团队可以改善产品工作一样，通过将法律专业人员纳入更广泛的跨职能团队，团队效能可以得到进一步改进。

推荐阅读

第一步是阅读第4页“尝试…律师也去学习敏捷、迭代和系统思考等概念”一节中列出的建议。

网上有大量资源，涉及敏捷开发和合同; 然而，有些是推测性的而不是基于经验的，请在阅读时牢记这一点。一些读物：

• Mary和Tom Poppendieck是精益软件开发的思想领袖，多年来组织了多个合同研讨会，并在他们的网站www.poppendieck.com上收集并分享了“精益和敏捷合同”论文和演示文稿。遵循类似于本章的主题，Poppendieck自己的敏捷合同材料强调了与合同相关的信任，协作和透明度的基本问题。
• Susan Atkinson和Gabrielle Benefield撰写了关于“进化合同模型”称谓下的敏捷合同的文章; 请访问www.infoq.com查看他们的文章。
• 在agilesoftwaredevelopment.com上，Peter Stevens撰写了一篇文章，总结了“下一个敏捷软件项目的10种合同”(10 Contracts for your next Agile Software Project)。
• Barry Boehm及其同事在“增量承诺模型”（incremental commitment model)主题上撰写了几篇文章（可在网上获得）。
• 一些刚接触该主题的人认为鼓励灵活性\协作和利益一致性的合同（“敏捷”合同）是一个新颖的概念，但实际上多年来在这个领域已经有很多写作和推广，包括在美国政府（例如，参见Administration of Government Contracts）。有数十种（如果不是数百种）书籍和网站讨论各种合同模型。
• 我们已经审阅了几种明确支持迭代、进化或敏捷开发的“公开”合同模型。但是，Valtech和ThoughtWorks以及我们所知道的其他敏捷外包商 ，选择编写自己的合同而不是使用这些模型。我们不鼓励“复制粘贴”合同写作，但这些都值得深入思考：

• DSDM联盟（DSDM是一种敏捷方法论）提供了样本合同，在www.dsdm.org上提供给成员。请注意，合同不时会被修改。
• 挪威PS 2000合同是由行业和政府之间的联盟为迭代和演化发展而创建的，可从www.dataforenin-gen.no获得。我们从合同中引用一段，“当在招标前难以甚至无法制定详细规范时，[合同]将发挥用处，我们的想法是让开发人员找到实现目标和满足客户需求的最佳方式。

参考文献

[Austin96] Austin, R., 1996. Measuring and Managing Performance in Organizations, Dorset House

[AV07] APLN, Version One, 2007. “2nd Annual Survey. The State of Agile,” VersionOne website at http:// www.versionone.com/pdf/stateofagiledevelopment2_fulldatareport.pdf

[BC99] Beck, K., Cleal, D., 1999. “Optional Scope Contracts,” at www.jarn.com/about/OptionalScopeCon-tracts.pdf

[CSSD05] Ceschi, M., Sillitti, A., Succi, G., De Panfilis, S., 2005. “Project Management in Plan-Based and Agile Companies,” IEEE Software, May/June 2005

[DBT05] Dalcher, D., Benediktsson, O., Thorbergsson, H., 2005. “Development Life Cycle Management: A Multiproject Experiment.” Proceedings of the 12th International Conference on Engineering of Computer-Based Systems, IEEE Computer Society

[EMH05] Eckfeldt, B., Madden, R., Horowitz, J., 2005. “Selling Agile: Target-Cost Contracts.” Proceedings of Agile 2005 Conference

[Gilb05] Gilb, T., 2005. Competitive Engineering, Butterworth-Heinemann

[Herzberg87] Herzberg, F., 1987. “One More Time: How Do You Motivate Employees?” Harvard Business Review, Sept/Oct 1987

[ISV09] Iyer, A., Seshadri, S., Vasher, R., 2009. Toyota’s Supply Chain Management: A Strategic Approach to Toyota’s Renowned System, McGraw-Hill

[Kohn93] Kohn, A., 1993. Punished by Rewards, Houghton Mifflin

[Larman03] Larman, C., 2003. Agile and Iterative Development: A Manager’s Guide, Addison-Wesley

[LV08] Larman, C., Vodde, B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley

[MacCormack01] MacCormack, A., 2001. “Product-Development Practices That Work,” MIT Sloan Manage-ment Review. Vol. 42, No. 2.

[Martin04] Martin, R., 2004. “Estimating Costs Up Front,” Extreme Programming mailing list, at http:// groups.google.com/group/comp.software.extreme-programming/msg/9a203fad85f3d363?hl=en

[MJ05] Moløkken-Østvold, K., Jørgensen, M., 2005. “A Comparison of Software Project Overruns—Flexible versus Sequential Development Models,” IEEE Transactions on Software Engineering, Vol. 31, No. 9, Sept 2005

[Moore91] Moore, G., 1991. Crossing the Chasm, HarperCollins Publishers

[Parkinson57] Parkinson, C., 1957. Parkinson’s Law, Buccaneer Books

[Poppendieck05] Poppendieck, M., 2005. “Agile Contracts” Agile 2005 Conference Workshop, at www.pop-pendieck.com/pdfs/AgileContracts.pdf

[PRL07] Parsons, D., Ryu, H., Lal, R., 2007. “The Impact of Methods and Techniques on Outcomes from Agile Software Development Projects,” IFIP—Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda. Springer (draft)

[PS06] Pfeffer, J., Sutton, R., 2006. Hard Facts, Dangerous Half-Truths And Total Nonsense, Harvard Business School Press

[Reifer02] Reifer, D., 2002. “How Good are Agile Methods?” IEEE Software, July/Aug 2002.

[Smith07] Smith, P., 2007. Flexible Product Development: Building Agility for Changing Markets, Jossey-Bass

全文完

继续阅读：

敏捷合同入门（上）

敏捷合同入门（中）

敏捷合同入门（下）

敏捷风水——外包合同暴露了甲乙方八字不合–签署敏捷合同