敏捷签约–您可以尝试

一个在敏捷开发的重要原则是“在合同谈判的客户合作”不幸的是，这意味着，如果你想跟着敏捷方法，你没有留下有用的准则，当涉及到合同和未来与遵循合同适合敏捷团队工作的方式 。

当然，无论团队如何工作，时间和材料都不费吹灰之力–完成工作，跟踪时间和其他成本，并在执行过程中向客户收费。 但是对于必须在固定价格/固定范围等合同结构中工作的人们而言，这尤其具有挑战性，这是许多政府合同的授予方式以及许多大型企业仍在从事开发工作的方式。

敏捷团队的建议通常是这样的：由您说服购买者更改规则，并接受更加模糊，更平衡的合同方式和更多的让步。 符合敏捷开发的基本假设的东西：成本（主要是团队中的人员）和进度可以固定，但是范围需要灵活并随着项目的进行确定。

但是在许多商业环境中，为工作付费的人对改变他们的想法和计划不感兴趣-这是他们的钱，他们想要时想要他们想要的东西。 他们在做主。 如果您不遵守投标过程中的条款，则根本没有机会与客户合作。 付钱给您的人（您的管理人员）还需要知道它要花多少钱，什么时候要完成以及有什么风险，以便他们知道自己是否有能力承担该项目。 这使开发人员处于困难的（也许是不可能的）情况。

无钱赚钱，免费找零

Scrum的创建者之一杰夫·萨瑟兰 （ Jeff Sutherland）提出了一种合同结构，即“ 一无所有的钱和免费的零钱 ”。 开发团队逐步交付软件–如果他们正确地遵循了Scrum，则应首先从对客户最重要的工作开始，并尽早交付客户最需要的东西。 客户可以在任何时候终止合同（因为他们已经有了他们真正需要的东西），并支付合同剩余部分的一定比例，以补偿开发人员因失去计划完成整个项目而获得的收入。 因此，很显然，合同的付款时间表不能在项目结束时进行加权（“最终验收”中不需要大笔付款，因为它可能永远不会发生）。 那就是“一分钱不花钱”的部分。

“免费更改”意味着客户不能在项目中添加范围，但可以进行更改，只要他们用相同大小或更小的工作代替待办事项中仍需完成的工作即可。 因此，可以提出新的工作，客户可以改变主意，但是项目的总体规模保持不变，这意味着团队仍应能够在计划的结束日期之前交付项目。

为此，您必须定义，理解并确定需要提前完成的所有工作的规模，这与敏捷团队的迭代，增量方式不太匹配。 它忽略了变更仍然需要付出代价的事实：开发人员必须浪费时间，因为他们花了很多时间来预先了解需要做些什么来估计它以及他们在计划它时所做的工作，而他们必须做需要更多工作来审查和了解更改，估计更改并重新计划。 变更在敏捷开发中很便宜，但并非免费。 如果客户需要进行少量更改，则成本并不高。 但是，如果客户在一个项目中进行数十或数百次此操作，则可能成为交付的真正障碍，并增加了可观的成本。

固定价格和固定所有合同

固定价格合同，尤其是Alistair Cockburn所谓的固定所有合同 （固定价格，固定范围和固定时间）都是令人讨厌的事实。 Cockburn说，这些合同通常是出于缺乏信任而创建的-为要开发的系统付费的人不信任开发软件的人来做他们需要的事情，并试图将风险推给开发团队。 即使人们开始互相信任，这些合同也经常会造成信任破裂的环境-客户不信任开发人员，开发人员向客户隐藏东西，付钱给开发人员的人也不信任任何人。

但这仍然是签约工作的一种常见方式，因为对于许多客户而言，他们更容易计划工作，并且对于将软件开发项目视为工程项目并且希望以与他们相同的方式对待软件工程项目的组织来说，这是有意义的。修建道路或桥梁。 这就是我们告诉您的需求，这是在我们需要时，即您说要付出的成本（包括您的风险和利润率），我们同意这是我们愿意支付的，现在就开始建造它完成后我们会付钱给您。

Cockburn确实谈到了一个案例，即团队与客户紧密合作并证明他们可以为客户提供他们所需的东西，从而成功地将固定的所有合同随时间变化为时间和物料合同。 每次交付后，团队将与客户会面，讨论是继续执行书面合同还是处理客户真正需要的事情，而不是继续进行合同重新谈判。 我已经看到了这种情况的发生，但是这种情况很少见，除非两家公司共同努力，并且项目失败的风险很小。

肯·施瓦伯（Ken Schwaber）承认， Scrum项目无法完成固定价格合同 （请阅读本书 ）。 同样，解决方案是说服客户以渐进的迭代方式接受工作并为之付款。

马丁·福勒（Martin Fowler）表示 ，没有详细，稳定和准确的要求，您无法交付固定价格，固定时间和固定范围的合同，他认为这是无法做到的。 他的解决方案是确定价格和时间，然后与客户合作，在约定的结束日期之前交付您所能提供的一切，并希望这足够了。

我在敏捷项目合同中找到的最有用的参考资料是Arbogast，Larman和Vodde的可免费获得的《 敏捷合同》，该书来自《规模化精益和敏捷开发实践》 。

他们的建议：避免使用固定价格，固定范围（FPFS）的合同，因为它们对客户和供应商都是双输。 客户不太可能获得所需的东西，因为供应商有时会因交付而感到恐慌，并被迫降低质量。 如果供应商能够交货，则由于供应商必须增加风险溢价，客户必须支付比他们应支付的更多的钱。 以这种方式工作会导致缺乏透明度，并导致双方都在玩游戏。

但是，如果必须这样做：

• 显然，这需要进行前期的规划和设计工作才能理解和估算必须完成的所有工作，这意味着您必须大幅度改变敏捷方法。
• 您不必允许更改–您可以从预先定义的待办事项中逐步进行工作。 或者，您可以限制客户只改变要完成的工作的优先顺序（这使他们具有透明度和某些控制权），或者允许他们用新需求替换相同规模的现有需求（Sutherland的“免费更改” ”）。

要成功签订此类合同，您必须：

• 由有经验的人投入大量资金来进行详细的前期需求分析，一些设计工作，彻底的验收测试定义和估算
• 不允许更改要求或范围–只能替换/替换
• 增加合约价格保证金
• 确保您了解正在处理的问题–领域和技术
• 尽早交付重要的东西，并希望如果您仍然无法交付所有东西，那么客户将在最后阶段灵活应对。

PMI-ACP关于敏捷承包？

对于所有使用敏捷方法交付的项目，签约似乎仍在进行中。 有很多好的想法和建议，但没有可靠的答案。

我已经阅读了PMI-ACP认证的学习指南材料，以了解PMI对敏捷项目合同的看法。 Sutherland的“无钱赚钱，免费找零钱”和其他一些选择是一样的。 显然，PMI没有将敏捷项目中的合同作为一个严重的问题。 这意味着他们错过了另一个机会来帮助大型组织和与大型组织一起工作的人员（将要关心PMI-ACP认证的人员）了解如何在实际情况下使用敏捷方法。

参考： 敏捷中的合同–您可以在Building Real Software博客上从我们的JCG合作伙伴 Jim Bird 尝试使用 。

翻译自: https://www.javacodegeeks.com/2012/08/contracting-in-agile-you-try-it.html