你是如何与敏捷项目签约的？ （不是你怎么想的，你是怎么做的）
要执行一个敏捷项目，您首先需要一个合同。 没有合同 – 没有项目！ 没有项目 – 没有敏捷，SCRUM或任何！
如果我们谈论的是中大项目，合同必须有明确的安全触发条件。 即客户希望非常确定，如果我们同意在时间= T，预算= B和范围= S的情况下结束项目，我们不会以时间= T×2，预算= B×3或范围= S / 2。
另一方面，作为交付产品的公司，我们不希望项目意外结束。 也就是说，如果经过一些迭代，客户说：“现在我看到，这实际上是我们所需要的，我们现在就停下来。” 这个项目又计划了两个月，比我们有没有计划工作的人要多。 如果3-6人不是一个大问题，15-25可能是一个真正的问题！
然而，我没有find任何具有安全function的合同的真实例子，使得项目能够以完全敏捷的方式执行（声明或不向客户陈述）。 标准的说法我在很多论坛上find了 – 跟客户交谈，向他解释这是更高效的工作方式等等，既不说服我也不说服我的pipe理层。 不是说我们不相信敏捷实际上是一个更好的方法。 这只是安全触发器的差距非常明显，我们的客户没有一个购买它，我们不喜欢它们（差距，而不是客户））。
请不要“这可能会这样工作……” – 我读过这么多。 只对“为我们这样工作”感兴趣 。 毫无疑问，跳过所有的信心。
PS据我所知，标准迭代，特征驱动的方法build议客户在每次迭代（迭代次数）之后付款，并且能够在客户和项目执行者经过任何迭代后停止项目，而不用多说任何后果，而不是说“反正会失败的，所以越早越好”（这是正确的，但在签订合同时不是很有帮助）。
我在政府工作。
我们最近运行了一个软件开发采购stream程，并select了三个供应商来开展一个敏捷项目。 一些说明：
-
我们已经确定要运行一个敏捷项目了，因为我们知道我们的需求是模棱两可的，因为它是一个面向公众的Web项目，具有重要的devise元素。 所以我想说，如果你的客户知道敏捷，并从一开始就买，即使他们实际上没有在内部实践，它也会有很大的帮助。 请注意，在（某些）政府圈子中接受敏捷正在增长，所以这可能会变得更容易。
-
我们采用的一个安全措施是聘请一位经验丰富（独立）的SCRUM主pipe为我们工作，并代表我们的团队主pipe/架构师/可用性人员来处理软件项目pipe理职责。 我们花了很多时间find这个人，并从三位优秀的申请者中挑选出来。 这是昂贵的，但值得。
-
一旦我们select了我们的供应商，并且广泛地同意他们的angular色（devise，前端，后端），我们就制定了一份快速的谅解备忘录，概述我们的意图，项目的可能预算，团队的可能规模卖方，承诺在本月底签订全面合同，并在此期间签署一份时间和材料协议。
-
然后，我们跳上了技术计划/大小调整会议的事情。 这个时候没有开发工作或devise，但是我们做了很多大小和高级估计。
-
到本月底，我们为每个供应商签订了合同（一个迟了，但没关系）。 一个供应商提出了我们可能使用的样本合同，一个基于项目三分之一的付款; 另一个完成冲刺。 我认为最后我们完成了sprint（每月结算），在我们的标准合同模板的付款部分使用了一些供应商build议的语言。
总的来说，我们采用这种方法是可以的（尽pipe承认有一些风险），因为我们并不认为整个项目中存在大量的实际技术风险，而且我们对采购stream程和供应商有很大的信心，已经select。
最后，这是一个非常成功的项目，我们自此开始在其他项目中使用SCRUM。 我认为有一个伟大的团队是关键。 我们对供应商有信心 – 不仅他们能够做这项工作，而且他们对于作为一个团队工作的态度很合适，而且对于每个人都有明确的angular色（即他们会不要争夺同样的钱）。
如果我们的供应商不是那么好，那么我们对这样的合同会有一些保留，但是运行采购几乎和科学一样是一门艺术，而且我们知道我们select了最适合的团队来自其他高素质受访者的态度。
我们已经把第三年的所有三份合同都交给了第二年的发展，虽然我认为这次不是很顺利（新的SCRUM大师，不同的团队组合），但它仍然是一个很好的项目。
你也可能会发现这个有趣的事情： 外包敏捷 。
由于我主要在Intranet应用程序上工作，所以这对我来说不是一个太大的问题。 然而，我经常为其他部门做应用程序，有时候，特别是在项目规模很大的时候，我们就项目范围，（预期）持续时间和成本签署谅解备忘录（MOU）。 由于我以敏捷的方式工作，这些东西都不是固定的，往往很难向其他部门解释，而这些部门以前没有这样做过。 通常情况下，我将包括对过程本身的描述 – 几段 – 解释项目是他们之间的合作事业，我们一起决定何时完成。
在实际编写谅解备忘录时，我已经在项目中投入了大量的时间来发现需求是什么（这些都是以标准的小时率处理的）。 在此基础上，结合我对速度的估计以及与之前项目的相似性，我对所需特征的时间和成本进行了广泛的估计 – 再次解释，实际成本取决于我们实际实现哪些特征，需要多长时间？ 这需要相当的信任，但是由于我们一直在共同努力来制定要求，所以我通常和我正在直接处理的个人有这样的要求。 我经常试着将实际的估计从谅解备忘录中提取出来，但是如果他们的经理坚持的话，将包括在内。 我试图给他们一个预算编号。
我的经验是，一旦项目开始，你开始为客户提供价值，他们很less不高兴。 通常情况下，他们要求（并支付）超过原来的项目范围。 通常情况下，我们都同意一些原始function是不需要的，但我总是期待这一点。 毕竟，他们真的无法确切地知道，直到他们真正看到了他们真正需要的东西。 更多的时候，我们根据实际的发展情况，放弃一些function并添加其他function。 我想如果我们没有在那里使用敏捷方法没有任何意义。
我认为关键问题是信任。 我build议与一个新的客户在小型项目上合作，或者把一个大型项目明确地分成更小的项目来发展信任。 一旦他们和你知道你可以相互信任，build立正确的产品并拥有正确的function，那么我认为把客户突然撤出的风险 – 总是有一个最小化。
我曾经从事的唯一一个敏捷项目是In House，Time and Materials（T＆M）或者Per Per Cycle项目。
正如你所指出的那样，麻烦是有一个项目早期失败/结束的风险。 但是，是不是像任何项目一样？ 如果你去T＆M你承担所有的风险，如果你去固定价格客户承担所有的风险。 通过每次循环进行付费，您将承担大部分风险，但一次只能将一小部分风险传递给客户。 在这种情况下，您或客户都不想冒任何风险，这就是为什么您发布了这个问题。
风险在于生意是什么，风险越大，利润越大，如果没有，损失就越大。 如果处理风险太大，唯一的解决办法就是找别人把风险从你手中拿走，但你必须付钱。 如果你和客户都没有准备好，那么可能只有两个答案：
- 得到一些富有的傻瓜来承担风险（即得到保险）。
- 将风险分散到众多人群中，直到每个人的风险如此之小以至于可以接受。
我认为第二个选项是使接触器如此受欢迎。 因为他们很容易摆脱，他们最终冒着项目终止的风险。 由于这些风险会在其中一些风险之间传播，所以风险分散到可接受的水平。 由于额外的风险，他们会比员工更多地收取费用，但这是您为了避免风险而得到的。
你在敏捷项目上最后要做的事情是固定的范围（通常是传统瀑布项目的合同中包含的内容）。 你需要的是一个固定的时间表和一个固定规模的团队协同工作来处理优先级产品积压。
如果你强迫你的商业伙伴在启动时定义一个固定的范围，他们将把所有他们能想到的东西放在合同中。 不是因为它有价值，而是因为以后很难做出改变，他们可能需要它。
可以为业务伙伴请求的一组function提供高级估计。 但是，由IT和产品所有者组成的团队接受该范围和优先级，并且可以在实现这些function的过程中轻松地进行更改。 通过始终专注于最重要的function，团队成为价值驱动而非计划驱动。 如果有什么东西从名单上掉下来，它的价值就会小一些，而且被团队学到的更重要的东西所取代。
固定范围的合同在最不了解特征的情况下locking团队作出范围决定。 关注优先级并允许优先级和范围在迭代之间进行折叠，以确保交付的内容具有价值。
与业务合作伙伴签订固定范围的合同，与您的业务合作伙伴一起参加敏捷的新手训练营。 class级应该概述敏捷过程和产品所有者的angular色。 如果业务接受敏捷方法，则准备开始开发。 build立产品积压，确定优先级，提供高级估计，制定发布和迭代计划，开始交付价值。
我们执行关系的方式是首先将业务伙伴发送到敏捷新手训练营。 然后，我们培训了业务伙伴成为产品所有者。 然后，我们build立了积压，提供了一个高层次的估计和固定团队的规模和时间盒装的发展。 第一个工作软件在两周内被演示。 从那时起，商业伙伴就开始了解更多的变化的价值。 任何关于固定范围合同的讨论很快就被遗忘了。
我们处理这个问题的方式非常有效率。
我们的客户基本上购买迭代。 客户签订合同说“X 2周迭代”。 有一个客户端教育的过程（与我所从事的所有敏捷项目一样），以帮助客户加速规划过程，以及在开发过程结束时实际获得的信息并不具体项目的开始，但他们控制什么最终的结果将是。
我们的团队已经合作了近六个月，我们已经有了稳固的技术基础，可以将风险降到最低。 我们对速度方面的持续能力有非常牢固的把握 – 这有助于我们预测满足客户期望结果所需的迭代次数。
我们的PM实践仍然赶上了交付软件的敏捷方法。 大多数情况下，小心谨慎的是，最初的合同定义了高层次的目标，但是对可预见的技术挑战的function限制。 定义和定价某些主要交付里程碑，即alpha，beta，final。附加范围被定义为补充原始合同的变更请求。 这是一个学习的经验，因为我们摆脱了传统的瀑布方式; 我所看到的最大的问题是，像定期部署这样的东西很难定价，因为你永远不知道从迭代中处理“反馈”需要多less时间。 我们已经“这很棒，我们正在顺利进行！” 我们已经有了“这里有200个缺陷的列表”。 对客户之间频繁发布的目的有不同程度的了解。
自从我们转向敏捷以来，我们的合同并没有改变，客户仍然希望在重要的里程碑上获得构build，而且在冲刺的每一端都不能直接参与。 产品所有者不一定是合同另一端的人，可以是执行经理。 产品所有者始终与实际客户的需求保持沟通，他将评估需求展示给客户。 如果他有频繁的发布，那么这个人与客户交stream也会容易得多。
