您是如何与敏捷项目签订合同的？(不是你认为你会怎么做，你是怎么做的)

Question

要执行敏捷项目，首先需要一个合同。没有合同-没有项目！没有项目-没有敏捷，SCRUM或任何东西！

如果我们说的是中、大型项目，合同必须有明确的安全触发因素。也就是说，客户希望非常肯定，如果我们同意以时间= T，预算=B和范围=S结束一个项目，我们不会以时间= T×2，预算= B×3或范围= S/2结束。

另一方面，作为一家交付产品的公司，我们不希望项目出乎意料地结束。也就是说，如果经过一些迭代，客户说：“现在，我看到，这实际上是我们所需要的。我们现在停止。”这个项目计划了2个月，比我们没有计划工作的人还要多。如果3-6人不是一个大问题，15-25可能是一个真正的问题！

然而，我没有找到任何合同的实际例子，其中包含安全特性，可以让项目以完全敏捷的方式执行(说明或不向客户说明)。我在许多论坛上发现的标准说法--与客户交谈，向他解释这是一种更有成效的工作方式等等--既不能说服我，也不能说服我的管理层。并不是说我们不相信敏捷实际上是一种更好的方法。只是安全触发的漏洞是如此明显，以至于我们的客户中没有人购买它，我们也不喜欢它们(差距，而不是客户;)。

请不要“它可能是这样工作的，…” -我读过很多这样的书。只对“它是这样工作的”感兴趣。毫无疑问，跳过所有自信的信息。

据我所知，标准的迭代、特性驱动方法建议客户在每次迭代后付费(迭代次数)，并且能够在任何迭代之后都由客户和项目执行者停止项目，而不必过多地谈论结果，而不是说“无论如何都会失败，所以越早越好”(这是正确的，但在签订合同时没有多大帮助)。

Answer 1

我在政府工作。

我们最近运行了一个软件开发采购流程，并选择了三个供应商从事敏捷项目。一些注意事项：

1. 我们已经有75%确信我们想要运行一个敏捷项目，因为我们知道我们的需求是模棱两可的，因为它是一个具有重要设计元素的面向公众的web项目。所以我想说，如果你的客户从一开始就了解敏捷并购买，即使他们实际上没有在内部实践敏捷，也会有很大的帮助。请注意，在(一些)政府圈子中，对敏捷的接受正在增加，因此这可能会变得更容易。
2. 我们使用的一个保障措施是聘请一位经验丰富(独立的) SCRUM大师为我们工作，并代表我们的团队领导/架构师/可用性人员处理软件项目管理职责。我们花了很多时间找到这个人，并从三位优秀的应聘者中挑选了他们。虽然代价很高，但还是值得的。
3. 一旦我们选择了我们的供应商并广泛地同意了他们的角色(设计，前端，后端)，我们建立了一个快速的MoU，概述了我们的目标，项目的可能预算，每个供应商可能的团队规模，承诺在月底之前签署一份完整的合同，以及时间和材料协议。
4. 然后我们进行了一次技术规划/规模调整会议，并开始了这方面的工作。没有开发工作或设计在这段时间，但我们做了大量的规模和高水平的估计。
5. 到了月底，我们为每个供应商准备了合同(其中一个迟到了，但没关系)。一个供应商提出了我们可能使用的示例合同，一个基于项目的三分之一付款，另一个基于sprint的完成。我认为最终我们完成了sprint(每月计费)，在标准合同模板的支付部分使用了一些供应商建议的语言。

总的来说，我们同意这种方法(尽管承认了一些风险)，因为我们不认为整个项目中存在大量的实际技术风险，也因为我们对采购过程和我们选择的供应商有很大的信心。

最后，这是一个非常成功的项目，我们已经开始使用SCRUM内部的其他项目。我认为拥有一支伟大的球队是关键。我们对供应商很有信心--不仅是他们能够完成这项工作，而且他们在作为一个团队工作的态度上也是一个很好的人选，而且每个供应商都有明确的角色(也就是说，他们不会为了同样的钱而竞争)。

如果我们的供应商不是那么好的话，我们会对签订这样一份合同有更多的保留，但是管理采购几乎是一门艺术，也是一门科学，我们知道我们选择了最适合的团队--从一群其他高质量的受访者中挑选出一种态度。

从那以后，我们已经将这三份合同都转到了第二年，尽管我想说这次进展并不顺利(新的SCRUM大师，不同的团队组成)--这仍然是一个值得参与的伟大项目。

您可能还会发现这一点很有趣：外包敏捷。

Answer 2

由于我主要从事内部网应用程序的工作，这对我来说并不是什么大问题。然而，我经常为其他部门做应用程序，有时，特别是当项目规模很大时，我们就项目范围、(预期)期限和成本签署了谅解备忘录(MOU)。因为我是以敏捷的方式工作的，所以没有一件事情是固定的，这通常很难向以前没有这样工作过的其他部门解释。通常，我会包括对过程本身的描述--几段--解释这个项目是如何在他们和我之间进行合作的，我们一起决定我们什么时候完成。

在实际编写谅解备忘录时，我已经在项目中投入了大量时间，以了解需求是什么(这些需求是以标准的小时费率处理的)。基于此，再加上我对以前项目的速度和相似性的估计，我给出了所需功能的时间和成本的大致估计--再一次解释，真正的成本取决于我们实际实施的功能以及实际花费的时间。这需要相当多的信任，但由于我们一直在一起开发需求，所以我通常需要与我直接打交道的个人一起工作。我经常试图把实际的估计放在谅解备忘录之外，但是如果他们的经理坚持的话，我会把它包括进去。我确实试着给他们一个预算号码。

我的经验是，一旦项目开始，你开始为客户提供价值，他们很少不高兴。通常，他们要求(并支付)比原来的项目范围更多。通常，我们都同意一些最初的特性是不需要的，但我总是这样认为。毕竟，在他们真正看到他们真正需要的东西之前，他们是无法确定的。通常情况下，我们删除一些特性，并根据实际开发添加其他特性。我想如果我们不这么做的话，就没有必要使用敏捷方法了。

我认为关键问题是信任。我建议与新客户合作进行小型项目，或者明确地将大型项目分解为较小的项目，以建立信任。一旦他们和你知道，你可以互相信任，建立正确的产品，有正确的功能，我认为风险--而且总是有--客户突然退出的风险被最小化了。

Answer 3

我曾经做过的唯一的敏捷项目要么是在房子，时间和材料(T&M)，要么是支付每个周期的项目。

问题是，正如你已经指出的，一个项目有提前失败/结束的风险。但是，这不和任何项目都一样吗？如果你去T&M，你承担所有的风险，如果你采取固定的价格，客户承担所有的风险。通过每个周期付费，你承担了大部分的风险，但它的小块，它是由客户一个周期在一次。碰巧的是，你和客户根本不想冒任何风险，这就是为什么你发布了这个问题。

问题在于，承担风险的关键在于，你承担的风险越大，你的利润就越大，如果不这样做，损失也就越大。如果风险太大，你无法应对，唯一的解决办法就是找一个能从你手中拿掉风险的人，但你必须付出代价。如果你和客户都不准备接受，那么大概只有两个答案：

1. 找个有钱的傻瓜来承保风险(也就是买保险)。
2. 将风险分散到多个人之间，直到每个人承担的风险如此之小，以至于它是可以接受的。

我认为第二个选择使接触器如此受欢迎。因为他们很容易摆脱，他们最终冒着项目提前终止的风险。由于风险将在多个风险之间传播，风险被传播到一个可接受的水平。由于额外的风险，他们会向你收取比雇员更多的费用，但这就是你为了避免这种风险而得到的回报。