37

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

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

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

然而，我没有找到任何具有安全功能的合同的真实示例，该合同允许项目以完全敏捷的方式执行（向客户说明或未说明）。我在许多论坛上发现的标准说法——与客户交谈，向他解释这是更有成效的工作方式等，这并不能说服我和我的管理层。并不是说我们不相信敏捷实际上是一种更好的方法。只是安全触发器的差距是如此明显，以至于我们的客户都没有购买它，我们也不喜欢它们（差距，而不是客户；））。

请不要“它可能会以这种方式工作......” - 我已经阅读了大量的内容。只对“对我们来说它是这样工作的”感兴趣。毫无疑问，跳过其中的所有自信信息。

PS 据我所知，标准的迭代、功能驱动的方法建议客户在每次迭代（迭代次数）后付费，并且能够在任何迭代后由客户和项目执行者停止项目，而无需多说后果，而不是说“无论如何它都会失败，所以越早越好”（这是正确的，但在签署合同时不是很有帮助）。

4

7 回答 7

11

我在政府工作。

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

  1. 我们已经 75% 确定我们想要运行一个敏捷项目，因为我们知道我们的要求是模棱两可的，而且因为它是一个面向公众的 Web 项目，具有重要的设计元素。所以我想说，如果你的客户了解敏捷并从一开始就接受它，这会很有帮助，即使他们实际上并没有在内部实践它。请注意，（某些）政府圈子越来越接受敏捷，所以这可能会变得更容易。

  2. 我们使用的一项保障措施是聘请一位非常有经验（独立）的 SCRUM 主管为我们工作并代表我们的团队负责人/架构师/可用性人员处理软件项目管理职责。我们花了很多时间找到这个人，并从三位优秀的申请人中选出了他们。这是昂贵的，但值得。

  3. 一旦我们选择了我们的供应商并广泛同意他们的角色（设计、前端、后端），我们就制定了一份快速的谅解备忘录，概述了我们继续进行的意图、项目的可能预算、每个团队的可能规模供应商，承诺在月底前签署一份完整的合同，并在此期间签订时间和材料协议。

  4. 然后我们参加了一个技术规划/规模调整会议，让事情顺利进行。这段时间没有进行任何开发工作或设计，但我们做了很多大小调整和高级估计。

  5. 到月底，我们为每个供应商制定了合同（一份迟到了，但没关系）。一位供应商提出了我们可能会使用的样本合同，一份基于项目三分之二的付款；另一个在冲刺完成时。我认为最终我们完成了冲刺（按月计费），在我们的标准合同模板的付款部分使用了一些供应商建议的语言。

总的来说，我们对这种方法没问题（尽管承认存在一些风险），因为我们认为整个项目中没有大量的实际技术风险，并且因为我们对采购过程和供应商充满信心，我们已选择。

最后，这是一个非常成功的项目，我们已经开始在内部将 SCRUM 用于其他项目。我认为拥有一支优秀的团队是关键。我们对供应商充满信心——不仅他们能够胜任这项工作，而且他们非常适合作为一个团队工作的态度，并且每个人都有明确的角色（即他们会不是为了同样的钱而竞争）。

如果我们的供应商不是那么好，我们对签订这样的合同会有更多的保留意见，但是进行采购几乎是一门艺术和一门科学，我们知道我们选择了最合适的团队来自其他高质量受访者的态度。

从那以后，我们已经为第二年的开发延期了所有三份合同，尽管我想说这次进展并不顺利（新的 SCRUM 大师，不同的团队组成）它仍然是一个值得参与的伟大项目。

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

于 2009-04-21T21:09:17.427 回答
10

因为我主要在 Intranet 应用程序上工作，所以这对我来说并不是太大的问题。但是，我经常为其他部门做应用程序，有时，特别是当项目很大时，我们会就项目范围、（预期）持续时间和成本签署谅解备忘录（MOU）。由于我以敏捷的方式工作，这些事情都不是固定的，这通常很难向以前没有以这种方式工作的其他部门解释。通常，我将包括对过程本身的描述——几段——解释项目如何成为他们和我之间的合作项目，我们共同决定何时完成。

到实际编写 MOU 时，我已经在项目中投入了大量时间来发现需求是什么（这些是按标准小时费率处理的）。基于这一点，再加上对我的速度和与以前项目的相似性的估计，我对所需功能的时间和成本进行了广泛的估计——再次解释说，实际成本取决于我们实际实现的功能和真正需要多长时间。这需要相当多的信任，但由于我们一直在合作开发需求，所以我通常会与我直接打交道的个人一起制定需求。我经常试图在谅解备忘录中留下实际估计，但如果他们的经理坚持，我会将其包括在内。我确实试着给他们一个预算数字。

我的经验是，一旦项目开始并且您开始为客户提供价值，他们很少会不高兴。通常，他们要求（并支付）比原始项目范围更多的东西。通常，我们都同意不需要某些原始功能，但我总是希望如此。毕竟，在他们真正看到运行中的事物之前，他们真的无法确定他们真正需要的是什么。通常情况下，我们会根据实际开发删除一些功能并添加其他功能。我想如果我们不这样做，那么使用敏捷方法就没有任何意义了。

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

于 2009-04-09T11:53:10.857 回答
7

我参与过的唯一敏捷项目是内部、时间和材料 (T&M) 或按周期付费项目。

正如您所指出的，问题在于，项目存在提前失败/结束的风险。但是，这和任何项目都不一样吗？如果您选择 T&M，您将承担所有风险，如果您选择固定价格，则客户将承担所有风险。通过按周期付费，您承担了大部分风险，但每次一个周期将一小部分风险传递给客户。碰巧的是，您或客户都不想承担任何风险，这就是您发布此问题的原因。

问题是冒险是商业的全部，你承担的风险越大，当它出现时利润就越大，但如果不这样做，损失也越大。如果风险太大而您无法处理，唯一的解决方案是找到其他可以承担风险的人，但您将不得不付钱给他们。如果您和客户都没有准备好接受它，那么可能只有两个答案：

  1. 找一些有钱的傻瓜来承担风险（即买保险）。
  2. 将风险分散到许多人中，直到每个人承担的风险小到可以接受为止。

我认为第二个选项是使接触器如此受欢迎的原因。因为他们很容易摆脱，他们最终冒着提前终止项目的风险。由于风险将在其中一些之间分散，因此风险分散到可接受的水平。由于额外的风险，他们会向您收取比员工更高的费用，但这就是您试图自己避免风险的结果。

于 2009-04-09T13:28:07.587 回答
3

在敏捷项目中，您最不想要的是固定范围（通常包含在传统瀑布项目的合同中）。您需要的是与固定规模的团队针对优先产品积压工作达成固定时间表的协议。

如果你强迫你的商业伙伴在启动时定义一个固定的范围，他们会在合同中塞满他们能想到的所有东西。不是因为它有价值，而是因为以后很难做出改变，他们可能需要它。

可以为业务合作伙伴要求的一组功能提供高级估计。但是，由 IT 和产品负责人组成的团队接受范围和优先级将在功能实施过程中轻松更改。通过首先专注于最重要的功能，团队成为价值驱动而不是计划驱动。如果有任何东西确实不在列表中，那么它的价值就会降低，并且已经被团队学到的更重要的东西所取代。

固定范围的合同锁定了团队在他们对功能了解最少的情况下做出范围决策。关注优先级并允许优先级和范围在迭代之间灵活调整，确保交付的内容具有价值。

与其与企业签订固定范围的合同，不如与您的业务合作伙伴一起参加敏捷训练营。该课程应概述敏捷过程和产品所有者的角色。如果企业接受敏捷方法，您就可以开始开发了。构建您的产品待办事项，对其进行优先级排序，提供高级评估，构建发布和迭代计划并开始交付价值。

我们执行这种关系的方式是首先将业务合作伙伴送到敏捷训练营。然后我们将业务伙伴培训为产品负责人。然后我们建立了积压工作，提供了一个高水平的估计，并确定了团队的规模，并对开发进行了时间限制。在两周内，第一个工作软件被演示了。从那时起，业务合作伙伴就开始了解并了解做出改变的价值，因为他们学到了更多。任何关于固定范围合同的讨论很快就被遗忘了。

于 2009-05-02T00:16:43.137 回答
2

我们处理这个问题的方式非常有成效。

我们的客户基本上是购买迭代。客户签署了一份合同，上面写着“X 2 周迭代”。有一个客户教育过程（与我从事的所有敏捷项目一样）来帮助客户加快规划过程，并且他们在开发过程结束时实际得到的东西并不具体项目的开始，但他们控制最终结果。

我们的团队已经一起工作了近六个月，我们拥有自己开发的坚实技术基础，可以最大限度地降低风险。我们对我们在速度方面的持续能力有一个非常扎实的把握——这有助于我们预测满足期望的客户结果所需的迭代次数。

于 2009-05-19T00:57:51.690 回答
1

我们的 PM 实践仍在追赶交付软件的敏捷方法。大多数时候，出于谨慎考虑，最初的合同定义了高层次的目标，但对功能有可预见的技术挑战的限制。某些主要的交付里程碑，即 alpha、beta、final，被定义和定价。附加范围被定义为补充原始合同的变更请求。当我们远离传统的瀑布方法时，这是一种学习体验；我见过的最大问题是，像常规部署这样的事情很难定价，因为你永远不知道解决迭代中的“反馈”需要多少时间。我们有“这太棒了，我们进展顺利！” 我们有“这里”

于 2009-04-09T12:07:43.817 回答
0

自从我们切换到敏捷后，我们的合同没有改变，客户仍然希望在重大里程碑时接收构建，并且距离在 sprint 的每一端都直接参与太远了。产品负责人不必是合同另一端的人，它可以是执行经理。产品负责人不断与真实客户的需求沟通，他评估需求并将其展示给客户。如果他经常发布，那么这个人与客户沟通会容易得多。

于 2009-04-09T16:12:09.320 回答