固定范围+固定期限+固定价格合同是否可以与“敏捷”一起使用？

我们内部使用的某些项目是Scrum，但仍“固定一切”给客户。我们正在经历混合的成功（客户喜欢燃尽图的可见性）。可以使用敏捷方法成功执行我们工作的项目类型吗？

好吧，我主要在“敏捷”环境中工作（尽管我们不使用术语），并且我已经完成了固定成本的工作。通常，这等于成本加成，因为没有一家公司能够负担得起免费做所有事情，而且随着客户更清楚地了解他们想要的是什么，需求的确会发生变化。

固定成本部分的初始要求必须比在典型的迭代环境中更加谨慎地完成，从而使过程的迭代性降低。如果我们或多或少地满足了客户对固定成本部分的要求，则合同的“加”部分可以重复进行。

我想提出一个反问：

固定范围+固定期限+固定价格合同是否可以生效？

“好/快/便宜-两选一”的说法不仅仅是一些愚蠢的工程笑话。每个值得他精打细算的项目经理都知道项目管理三角区：

您是在告诉我们费用，范围和时间表都是固定的。这样就不会留下任何可操作性或错误的余地。 无。您可以选择将“质量”视为属性，但这不是“真实”属性，它更像是从其他属性（成本/范围/进度表）派生的元属性。

问题在于，只要您的项目是由人来计划和执行的，这就永远不会发生。

• 要求和规范永远不会涵盖所有的极端情况，除非合格的建筑师和设计师对它们进行了详尽的描述，在这种情况下，该项目已经完成了一半。而即使这样，还是有错误的可能性。

• 意外的费用将弹出，导致预算超支。订阅已过期。制造商停止了对您正在使用的产品的支持，您必须找到一个新的产品。一个时薪的承包商在出发威胁下提高了工资。您的整个团队都进行了罢工，要求加薪10％和休假一周。

• 日程安排单。不可预见的问题浮出水面；您连续使用5年的图表组件与您的客户端仍在使用的Windows 95不兼容。64位Windows中一个模糊的错误会导致严重的UI故障，您花了近一周的时间对其进行跟踪并开发解决方法（这实际上发生在我身上）。您的高级开发人员被公共汽车撞到了，您必须去招募和培训新的公共汽车。您的预计交货日期总是错误的。总是。

  参见霍夫施塔特定律：

  霍夫施塔特定律：即使您考虑霍夫施塔特定律，也总是比您期望的更长。

敏捷方法就是围绕成本，进度和范围进行折衷。在大多数情况下，它们特别是在范围和时间表之间徘徊，这就是为什么要从模糊的用户故事和计划修订而不是完整版本入手。不同的方法使用不同的术语，但这是相同的基本前提：频繁发布以及每个发布计划和范围的重新平衡。

这使得没有任何意义与一个项目，是（或权利要求书来定）任一固定范围或固定的时间表。

如果固定了一个项目属性（成本/范围/进度表），我会告诉您，它可能不适用于敏捷方法。

如果固定了两个项目属性，那么您的项目绝对不适合敏捷方法。

如果所有三个属性都固定，则您的项目可能会失败。如果实际发货，那么要么原定的时间表被大量篡改，要么客户设法欺骗自己以为您实际上已兑现了承诺。

如果该合同仍然存在，我敦促您拒绝该合同。如果您已经接受了，愿上帝怜悯您的灵魂。

我喜欢这句话：

“对于固定日期的可变范围或“固定范围”（总是不断增长）的可变日期而言，Scrum都非常有用。如果您正在使用固定日期的固定范围，我建议使用Waterfall或RUP，它们将为您提供几个月的时间来寻找新工作。”〜Michael James

当然，只要您的质量标准保持非常低。我相信“交货时间/质量/价格”这个旧的铁三角，您可以选择两个，但另一个浮动。听起来您已经确定了交货时间和价格（以及功能），所以真正唯一可以提供的就是质量。

就是说，如果您使用的是燃尽图，并且首先完成了最高优先级的项目，那么可以在指定的时间范围内以指定的金额完成一些最重要的项目。至少，您的客户会看到您正在某种程度上控制流程，并且在每次迭代结束时都会交付成果，并且他们能够说出最重要的内容。

否则，我认为承诺按固定的时间，功能集和价格进行操作是很困难的，并且会导致英雄般的努力，从而导致质量降低和维护性降低。敏捷不是魔仙尘。

固定价格/固定期限/固定范围至少可以像在瀑布中一样灵活地完成。

在瀑布中，时间估算不准确，并且最终实现的细节与原始规格不同。换句话说，截止日期/范围无法事先确切知道。

在敏捷中，您可以冲零来生成用户案例的积压，并进行一些估算。然后同意在固定的期限内以固定的价格满足价值故事。根据您要实现的价值故事，范围是固定的，并且对用户故事不做任何承诺。

换句话说，您保证交付重要的东西，并避免做出与收入/节省/等无关的特定设计决策。该项目应该交付的。

我在一定程度上同意布鲁斯的观点。尽管我对瀑布或RUP不太熟悉，因此无法对此发表评论。

我最近读过的东西（我认为确实很不错）是，即使在敏捷中，我们也忽略了计划。一次迭代就进行一次彻底的计划会议非常重要-没必要-在整个迭代过程中计划也是如此。

我在娱乐行业工作，那里的事物在不断变化。团队需要一定程度的宽容性/灵活性，这将允许他们在冲刺过程中“重新计划”故事，以便与新目标或修订目标保持一致。

我喜欢持续计划的想法，因为开发人员常常会在产品达到中期打印时告诉产品负责人。如果您的团队处理仍然有效的故事，而您的产品所有者只是在烦扰，那将是非常好的。但是在某些情况下，故事在冲刺过程中变得多余，产品所有者必须发现这一点，并且团队必须与变化的目标/故事重新保持一致，这不是敏捷性的意思吗？