project-management - 您是如何与敏捷项目签订契约(Contract)的？ (不是你想的那样，你是怎么做的)

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




要执行敏捷项目，您首先需要一份契约(Contract)。没有契约(Contract)——没有项目!没有项目——没有敏捷、SCRUM 或任何东西!

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

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

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

请不要“它可能会这样工作......” – 我读过很多。 只对“对我们来说它是这样工作的”感兴趣 .毫无疑问，跳过其中的所有自信信息。

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

Answer 1

我在政府工作。

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

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

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

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

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

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

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

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

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

从那以后，我们已经为第二年的开发延期了所有三份契约(Contract)，尽管我想说这次进展并不顺利(新的 SCRUM 大师，不同的团队组成)它仍然是一个很棒的项目。

您可能还会觉得这很有趣:Outsourcing Agile .