Scrum是否为需求不变的项目增加了额外的开销？

我正在阅读Gunther Verheyen撰写的Scrum-A Pocket Guide，它说：

Standish Group的2011年混乱报告标志着一个转折点。在比较传统项目和使用敏捷方法的项目时，进行了广泛的研究。该报告表明，即使以前认为软件必须按时，按预算并在所有承诺范围内交付的旧期望，采用敏捷方法进行软件开发也会带来更高的收益。该报告显示，敏捷项目的成功率是传统项目的三倍，失败的敏捷项目则少三倍。

因此，我与一位同事争论，他说对于某些项目（例如要求不变的医学/军事），敏捷（尤其是Scrum）在所有会议中都是开销，等等，这更合乎逻辑。例如使用瀑布。

我的观点是，应该在此类项目中采用Scrum，因为这将使过程更加透明并提高团队的生产力。我还认为，如果不需要Scrum事件，将不会花费很多时间，因为我们不需要在Sprint Planning中花整个8个小时来进行1个月的冲刺。我们可以抽出5分钟的时间来确保我们都在同一页面上并开始工作。

那么，Scrum会为需求不变的项目增加额外的开销吗？

我认为说有些项目的需求没有变化是错误的假设。我曾在国防工业和制药工业中工作过，所以可以告诉您，一旦软件最终落入主题专家（内部或外部）的手中，就会得到反馈。有时，这种反馈是关于满足需求的方式，而在其他情况下，实际上是关于需求本身是错误的还是不完整的。

敏捷性是指缩短反馈周期，更快地将软件投入用户的手中，获得反馈，并确定下一步应该做什么，以确保当客户决定接受软件时，交付的产品会增加价值。即使在具有自定义硬件的嵌入式系统这样的领域（例如您可能在航空航天，汽车或医疗设备等领域中发现），快速交付功能薄层以进行集成和原型设计也可以帮助确保软件和硬件系统能够按预期方式工作，并会为最终用户提供帮助。

反馈周期的缩短是降低风险的重要因素。从项目管理的角度来看，如果您资助一个2-4周的项目并定期了解进度，则可以确保您按计划进行。通过提供功能的薄片，您可以逐步实现目标状态，并可以开始预测何时到达目标状态。如果时间成为限制，则可以取消对低值函数的作用，因为首先完成的工作应该是高值函数或高值函数的启用码。在任何时候，您都可以决定是否值得继续努力，还是朝着不同的方向前进，在为时已晚之前停止项目。

简短的答案是，是的，Scrum从设计上讲是一种更昂贵的方法，但是如果您将其称为项目，则几乎可以肯定这无关紧要，最后几乎可以肯定总会带来更好的ROI。

更完整的答案是这样的：

一般来说，过程控制有以下三种形式：定义过程控制，统计过程控制和虚拟过程控制。到目前为止，定义的过程控制是最便宜的。随着时间的推移，经常重复进行的工作经过细化以找到“最佳”工作方式，这是可能的。软件开发中的CI / CD属于此类。您不想在构建过程中发生变化，因此您可以标准化过程，进行调整直到满意为止，然后将其自动化。与通过部署手动进行战斗相比，该自动化过程显然要便宜得多。

统计过程控制是第二便宜的，但是它考虑了已知过程的变化。按照计划进行的医疗程序属于这一类。我不想每次都重塑一次搭桥手术。我遵循基本流程并适应变化。这具有相对较低的认知负担和相当高的成功率。

接下来是经验过程控制，它是迄今为止最昂贵的方法，因为您必须随行发现过程。学习是难以置信的高，但是却以生产力和效率为代价。但是，几乎所有项目工作都需要这样做，因为以前很少完成任何项目。当然也有例外。设置大型的活动目录环境更具统计意义，因为您会根据一些实际需要而反复尝试的说明来进行工作，这些说明可能会根据情况有所不同。但是，除非您打算做之前已经做过的确切工作，否则几乎可以肯定，这需要Emperical Process Control。

为了将其带回Scrum，Scrum旨在解决Emperical Process Control的问题。因此，是的，它比其他方法具有更多的开销。但是，由于大多数项目都需要这种方法，因此这是没有根据的论点。

相对于医药和军事项目，这听起来像是有缺陷的逻辑。如果您要订购500架飞机，那么可以，您正在完全重新创建某些东西，而Scrum可能没有任何好处。如果您要建造一架新飞机，而您的要求永远不变，那么我就不会驾驶那架飞机。

当然，如果您有一个项目，您对项目有明确的要求，那么您可以将它们以瀑布般的方式倾倒在开发人员的面前，并在两年后回来满足您梦想中的软件。

但是绝大多数软件项目不是这样。

通常，客户不知道他们需要什么。他们无法提供完整且特定的要求。迭代方法在这里有帮助：构建一个小东西，然后向客户征求反馈。是的，这在演示和计划下一次迭代上“浪费”了时间。但是，为一次冲刺构建错误的东西，然后快速纠正需求要比为整个项目构建错误的东西好得多。即，虽然预先的要求可以允许更有效的开发，但是迭代方法将更有效。

开发人员要构建有用的软件，必须正确理解需求。在为时已晚之前发现误解的好方法是什么？同样，迭代方法可以提供帮助。但是，开发人员自己与客户合作而不是仅通过需求文档作者获得经过过滤的信息也很重要。

最后，在项目期间世界不会停滞不前。外部系统在变化，优先级在变化，人在变化。假装软件项目的需求不会改变，这是一个坏主意，除了短期项目。

所有这些过程级收益都缺少敏捷方法的日常优势：如果正确执行，敏捷会使每个人都更加快乐。其中最大的一项是，敏捷技术致力于在短时间内提供真实价值。这使开发过程具有可见性，使利益相关者可以合理地控制项目，并且比实现遥远的目标更有动力。与此相关的是，敏捷团队将在很大程度上自我组织。对日常工作的控制感使人们感到被重视，因此更有可能发挥出自己的最大才能。

您的同事没有错，瀑布式项目可以占有一席之地。而且，一些敏捷的习惯可能是浪费时间的仪式，这是您没有错。但是，忽略敏捷和迭代方法的好处是完全愚蠢的，尤其是更好的风险管理和对个人的尊重。这些是您在每个项目中想要的。如有必要，团队可以尝试在内部实施其中一些措施，但是当所有人都参与时，流程会更好地工作。

我认为这很可能是@Cort Ammon所说的话，但这是我的看法：

外部需求（描述“可交付成果”）并不是项目中的唯一需求。即使外部需求不变，“内部”需求也会随着您的工作而发生变化，或者需要被允许更改。开发人员将发现方法上的障碍或问题，​​这将影响团队中其他人员的工作。每日站起来将使每个人都了解这些内部更改。

考虑到：

• 即使功能要求固定，也需要将其转化为技术要求。而且，通过迭代可能会更好。您可能会在项目中期发现更好的方法来解决问题。

• 有些要求可能太笼统或含糊不清：“易于使用”，“安全”。很难分析尚未完成的系统的安全性或可用性。有些可能具有隐藏的含义，或者可能没有被很好地理解。

• 某些要求可能会得到改善。在200毫秒内响应可能会很好，但100毫秒可能会更好。您可以针对可能的最佳结果，但是在项目期间需要时可以牺牲它。

• 您可能会发现一些隐藏的要求，这些要求不会写在合同上，但是可能会使项目从失败变为成功。即使交付项目，客户也可能不满意。也许他们甚至需要更改合同，以增加（并收取）您可以在项目初期以较便宜的价格设计的新功能。

• 您可能会发现您无法在给定的时间内满足您的要求。好像软件项目从来没有迟到过。因此，提供最佳价值将使您可以重新协商要删除的功能。

• 尽早交付将有助于集成，并表明该项目可以交付成果。

可以提出这样的论据：如果所有需求都被完美地布置，那么就存在一种自上而下的方法，该方法可以尽快地实现这些需求。但是，如果这些是好的要求，它们会告诉您要制造什么，而不是如何制造。如果他们告诉您如何做到这一点，我会选择将其称为“工作说明”，而不是“要求”，我们将讨论另一种问题。

因此，总有一个开发“方法”的过程，该过程是公司或团队实施要求的内部。从经验上讲，我们强烈依赖于分层方法，在该方法中，一组设计师设计高级系统来满足这些要求，然后使用该高级系统的详细信息来为较小的团队提供“需求”，以充实我们的细节。

在瀑布过程中，这可以在设计和实现之间的单向箭头中看到。但是，这些需求并非像客户提供的那样是一成不变的。这些在内部定义，并为迭代过程留出空间。在实践中，我们发现设计人员要么在过程中留出了一定的余量来解决这种迭代的不足，要么寻求迭代过程。

SCRUM和许多其他相关的敏捷方法只是提供了一个严格的框架来执行此迭代过程。敏捷方法的一个标志是，他们认为优化这种迭代模式是流程的核心，而不是专注于硬性要求的外层。正如其他人提到的那样，实际的固定需求很少见，但即使存在，SCRUM仍使用迭代方法作为控制其适合的合同方法的方法。

是否成功做到这一点是公开辩论的问题。其他人为此提供了许多指标。我只想指出，要确保领导层下的迭代正确地与上层的契约体系相吻合，这取决于领导者的力量。任何开发方法都是如此，但是在敏捷方法中更明显，因为我们已经被假设为自上而下的方法是“正常的”和受过训练的领导者。