你是如何签署敏捷项目的合同的？（不是你认为你会怎么做，而是你实际上是如何做的）

Question

你是如何签署敏捷项目的合同的？（不是你认为你会怎么做，而是你实际上是如何做的）

37

要执行敏捷项目，首先需要签订合同。没有合同就没有项目！没有项目，就没有敏捷、SCRUM或其他任何东西！

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

另一方面，作为交付产品的公司，我们不希望项目意外结束。也就是说，如果在某些迭代之后客户说：“现在我看到这实际上是我们所需要的全部。我们现在停止。”而项目计划了另外两个月，那么我们就会有没有计划工作的人员。如果三到六个人不是很大的问题，那么15到25个人可能是一个真正的问题！

然而，我没有找到任何具有安全功能的合同的真实示例，可以允许项目在完全敏捷的方式下执行（无论是否向客户声明）。我在许多论坛上发现的标准说法是，与客户交谈，向他解释这是更有效率的工作方式等，但这既不能说服我，也不能说服我的管理层。并不是我们不相信敏捷实际上是更好的做事方式。只是安全触发器中存在的漏洞是如此明显，以至于我们的任何客户都不会接受它，并且我们也不喜欢它们（漏洞，而不是客户；）。

请不要提出“它可能会这样工作……”——我已经读了大量相关信息。我只对“对我们而言，它是这样工作的”感兴趣。没有疑问，请跳过其中所有自信的信息。

另外，据我所知，标准的迭代、特征驱动方法建议客户在每个迭代之后付款（迭代次数），并且在任何迭代之后，客户和项目执行者都可以停止项目，而不必过多地谈论后果，而是说“它无论如何都会失败，所以越早越好”（这是正确的，但在签订合同时并不是非常有帮助）。

- Dandikas

我投票关闭此问题，因为它涉及项目管理而非编程。 - EJoshuaS - Stand with Ukraine

1

我投票关闭此问题，因为它与编程无关。 - Vadim Kotov

7个回答

10

由于我主要从事企业内部应用程序的开发，这对我来说并不是太大的问题。然而，我经常为其他部门开发应用程序，有时，特别是在项目很大的情况下，我们会就项目范围、预计完成时间和成本签署谅解备忘录(MOU)。由于我以一种敏捷的方式工作，这些都不是固定的，这通常很难向以前没有这种工作经验的其他部门解释清楚。通常，我会包括一个关于过程本身的描述——几段话——解释该项目是他们和我之间的合作，我们共同确定何时结束。

实际编写MOU时，我已经投入了许多时间去了解需求(按标准小时费率处理)，基于这些信息以及对我的速度和以前项目的相似性的估计，我会给出所需功能的大致时间和成本估计——再次说明，真正的成本取决于我们实际实现哪些功能以及实际需要多长时间。这需要相当高的信任度，但由于我们一起制定需求，我通常与直接打交道的个人建立了这种信任。我经常尝试将实际估算留在MOU之外，但如果他们的经理坚持，我会包括在内。我会尽量给他们一个预算数字。

我的经验是，一旦项目开始并且你开始为客户提供价值，他们很少不满意。通常情况下，他们要求(并支付)比原来的项目范围更多的功能。我们通常都同意一些最初的功能不是必需的，但我总是期望这样。毕竟，在实际运行之前，他们真的没有办法确定他们真正需要什么。更常见的情况是，在实际开发过程中，我们放弃了一些功能，并添加了其他功能。我想，如果我们不这样做，使用敏捷方法就没有任何意义。

我认为关键问题在于信任。我建议与新客户一起合作小型项目，或者明确将大型项目分解成小型项目以建立信任。一旦他们和你知道彼此可以相互信任来构建正确的产品和正确的功能，那么我认为客户突然退出的风险——虽然总是存在的——会被最小化。

- tvanfosson

你必须承认，与另一个部门合作并不像与完全新的客户（从客户的角度来看，供应商也是全新的）合作那样神经质。但我明白你的意思，谢谢。 - Dandikas

实际上，部门内部的关系非常疏离 - 通常有完全不同的报告结构。如果说有什么不同的话，可能会更糟，因为从实质上讲，你们在争夺同样的资金，但他们常常无法将业务带到别处。 - tvanfosson

7

我曾参与的敏捷项目只有内部、计时计料或按周期支付的项目。

问题是，正如你所指出的那样，项目失败/提前结束的风险存在。然而，这与任何项目都一样吗？如果选择计时计料，您承担所有风险，如果选择固定价格，则客户承担所有风险。通过选择按周期付费，您承担了大部分风险，但是每个周期将小块的风险转移给了客户。恰好你和客户都不想承担任何风险，这就是为什么你发表了这个问题。

问题在于，承担风险是商业活动的本质，承担的风险越大，成功时的利润就越大，但如果失败，损失也会越大。如果风险太大，无法承受，唯一的解决方案就是找到可以承担风险的人，但您必须付钱。如果您和客户都不准备承担风险，那么可能只有两个答案：

1. 找到某个富翁来承担风险（即购买保险）。 2. 将风险分散到多个人身上，直到每个人承担的风险达到可接受的水平。

我认为第二个选项是承包商如此受欢迎的原因。因为他们容易被解雇，最终承担了项目提前终止的风险。由于风险将分散到多个人身上，因此风险会达到可接受的水平。他们将比一名员工收取更高的费用，因为他们必须承担额外的风险，但这就是您试图避免自己承担风险所得到的东西。

- Martin Brown

非常敏锐的评论。这意味着如果您按周期获得报酬，那么您承担的风险就会更少，因此您的利润可能比在基于合同的项目中承担所有风险（基于您能力的信任）时要少。 - Diomidis Spinellis

3

在敏捷项目中，你最不想要的是固定范围（通常在传统瀑布流项目合同中包含的东西）。你需要的是达成一致，确定一个固定规模的团队按照优先级排序的产品待办清单来完成固定的进度安排。

如果你在启动期间强制商业伙伴定义一个固定的范围，他们会把他们能想到的所有内容都填写到合同中。这不是因为它有价值，而是因为难以后期更改，而且他们可能需要它。

可以针对商业伙伴请求的一组功能提供高层次的估计。然而，由IT和产品负责人组成的团队接受范围和优先级会经常发生变化，并且可以很容易地在实现功能的过程中进行调整。通过专注于首先处理最重要的功能，团队变得以价值驱动而不是计划驱动。如果任何功能落后于计划，那么它的价值相对较低，并已被更加重要的事情所替代。

固定范围的合同会让团队在了解功能最少的时候做出范围决策。专注于优先级并允许优先级和范围在迭代之间灵活变化，确保所交付的内容具有价值。

与其与商业伙伴签署一个固定范围的合同，不如与你的商业伙伴一起参加敏捷训练营。该课程应概述敏捷过程和产品负责人的角色。如果商业伙伴接受敏捷方法，你就可以开始开发。构建产品待办清单，确定优先级，提供高层次的估算，制定发布和迭代计划，并开始提供价值。

我们执行关系的方式是首先送商业伙伴参加敏捷训练营。然后，我们培训商业伙伴成为产品负责人。然后，我们建立待办清单，提供高层次的估算，确定团队规模和限制开发时间。在两周内，第一个可工作的软件就展示了出来。从那时起，商业伙伴参与其中并理解了根据学习经验进行更改的价值。任何有关固定范围合同的讨论很快就被遗忘了。

- Cam Wolff

2

我们的做法非常有效。我们的客户基本上购买迭代。客户签署合同，表示“X2周迭代”。有一个客户教育的过程（和我参与的所有敏捷项目一样）来帮助客户适应计划过程和理念，即开发过程在项目开始时实际上不是具体的，但最终结果由他们控制。

我们的团队已经共同工作了近六个月，我们拥有自己开发的坚实技术基础来最大限度地减少风险。我们对速度方面的持续能力有相当牢固的把握，这有助于我们预测需要多少次迭代才能达到所需的客户目标。

- Toby Hede

1

我们的项目管理实践仍在追赶敏捷软件交付的步伐。大多数情况下，出于谨慎考虑，初始合同定义了高层次目标，但附加了对功能的限制，以应对可预见的技术挑战。某些重要的交付里程碑，如alpha、beta、final，已经被定义并定价。额外的范围被定义为变更请求，补充原始合同。随着我们从传统的瀑布方法中远离，这是一个学习的过程；我看到的最大问题是有些事情，比如常规部署，很难定价，因为你永远不知道解决迭代中的“反馈”需要多少时间。我们曾经有过“这太棒了，我们进展顺利！”和“这里有200个缺陷清单”的情况；客户对频繁发布的目的有不同程度的理解。

- slau

0

我们自从转向敏捷开发以来，合同并没有改变，客户仍然希望在重大里程碑时接收构建版本，并且距离每个sprint的结束太远，无法直接参与。产品负责人不一定是合同另一端的人，可以是高管经理。产品负责人与真实客户的需求保持不断的沟通，他评估这些需求并向客户展示。但如果该人员经常发布新版本，则与客户交流将更容易。

- MissT

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Anon Gordon · Accepted Answer

我在政府工作。

我们最近进行了一项软件开发采购过程，并选择了三家供应商来参与敏捷项目。以下是一些注意事项：

我们已经75％确定要运行一个敏捷项目，因为我们知道我们的需求含糊不清，并且因为这是一个面向公众的网站项目，具有重要的设计元素。所以我会说，即使客户没有实际在公司内部实践敏捷，如果他们从一开始就知道敏捷并买入它，这会非常有帮助。请注意，（某些）政府圈子中对敏捷的接受度正在增加，因此这可能会更容易。
我们使用了一种保障措施，即与我们合作，代表我们的团队领导/架构师/可用性专家处理软件项目管理职责的非常有经验的（独立）SCRUM主管签订合同。我们花费了很多时间找到这个人，并从三个优秀的申请者中选择了他们。虽然这很昂贵，但也是值得的。
一旦我们选择了供应商并广泛同意了他们的角色（设计、前端、后端），我们就制定了一个快速的谅解备忘录，概述了我们的意图，项目的可能预算，每个供应商团队的规模，承诺在月底签署完整合同，并在此期间签订一份时间和材料协议。
然后我们开始进行技术规划/大小估计会议并开展事项。在这段时间内没有进行任何开发工作或设计工作，但是我们进行了很多大小估计和高级别估算。
到月底时，我们为每个供应商准备了合同（其中一个迟到了，但没关系）。一家供应商提出了我们可能使用的样本合同，其中一个基于按项目的三分之一付款; 另一个基于冲刺完成。我认为最终我们采用了冲刺完成（按月计费），并在我们的标准合同模板的付款部分使用了一些供应商建议的语言。

总的来说，尽管承认存在一些风险，但我们对这种方法感到满意，因为我们认为整个项目中实际的技术风险并不是非常大，并且我们对采购过程和我们选择的供应商非常有信心。

最终，这是一个非常成功的项目，我们后来在其他项目中开始使用SCRUM。我认为拥有一个优秀的团队是关键。我们对供应商充满信心——不仅他们能够完成工作，而且在工作态度方面能够像一个团队合作，并且每个人都有明确定义的角色（即他们不会为同样的报酬而竞争）。

如果我们的供应商没有那么好，我们可能会对签订这样的合同产生更多的顾虑，但采购运营几乎是一门艺术而不仅仅是科学，我们知道我们已经从其他高质量的响应者中选择了最适合我们的工作团队。

我们后来将所有三份合同滚动到第二年的开发，虽然我要说这次并不像上次那么顺利（新的SCRUM大师，不同的团队构成），但这仍然是一个很棒的项目。

您可能也会觉得这很有趣：外包敏捷开发。