问Scrum是否为需求不变的项目创建额外的开销？

EN

我认为，如果说有些项目的需求不会改变，这是一个错误的假设。在国防工业和制药业都工作过的软件，我可以告诉你，一旦软件最终掌握在主题专家手中(无论是内部还是外部)，就会有反馈。有时，这种反馈是在满足需求的过程中进行的，而在其他情况下，反馈实际上取决于需求本身是否错误或不完整。

敏捷性是指缩短反馈周期，使工作软件更快地落入他人手中，得到反馈，并决定下一步应该如何确保在客户决定接受该软件时，交付的内容会增加价值。即使在像嵌入式系统这样带有自定义硬件的领域(就像您在航空航天、汽车或医疗设备等领域中可能发现的那样)，快速交付薄薄的功能来集成和原型可以帮助确保软件和硬件系统按预期工作，并以帮助最终用户的方式工作。

反馈周期长度的缩短是降低风险的一个巨大因素。从项目管理的角度来看，如果您为一个项目提供2-4周的资金，并且定期了解项目的进展情况，这就可以确保您已经步入正轨。通过能够交付薄薄的功能片段，您可以逐步向目标状态工作，并开始预测何时到达目标状态。如果时间成为一种约束，您可以对较低的值函数进行去监视，因为首先完成的工作应该是高值函数或高值函数的启用器。在任何时候，你都可以决定是否值得继续投资，还是转向另一个方向，在为时已晚之前停止一个项目。

简单地说，是的，Scrum在设计上是一种更昂贵的方法，但是如果你把它称为一个项目，它几乎肯定无关紧要，而且最终几乎肯定会带来更好的ROI。

更完整的答案是：

一般说来，过程控制有三种形式:定义过程控制、统计过程控制和传统过程控制。定义的过程控制是目前为止最便宜的。这在频繁的情况下是可能的--随着时间的推移，可重复的工作得到了改进，以找到“最佳”的方法来完成这项工作。软件开发中的CI/CD就是这一范畴。您不希望在您的构建过程中发生变化，因此您可以标准化流程，调整直到您满意为止，然后将其自动化。显然，与通过部署进行手动战斗相比，运行该自动化流程的成本要低得多。

统计过程控制是下一个最便宜的，但它解释了一个已知过程的变化。按计划进行的医疗程序属于这一类。我不想每次都重新做旁路手术。我遵循基本过程，并根据变化进行调整。这有一个相对较低的认知负荷和相当高的成功率。

接下来是经验过程控制，这是迄今为止最昂贵的，因为您必须在进行过程中发现该过程。学习是令人难以置信的高，但代价是生产力和效率。然而，几乎所有的项目工作都需要这样做，因为以前很少有项目完成过。当然，也有例外。设置一个大型的active目录环境更具有统计意义，因为您使用的是一些尝试过的和真实的指令，这些指令会根据情况的需要稍微偏离。但是，除非你的项目是做之前做过的精确工作，否则它几乎肯定需要帝王式的过程控制。

为了把它带回Scrum，Scrum被设计用来解决帝王式过程控制的问题。因此，是的，它比其他方法有更多的开销。然而，由于大多数项目都需要这种方法，所以这是一个没有意义的论点。

在医学和军事项目的对立面上，这听起来像是有缺陷的逻辑。如果你正在完成500架飞机的订单，那么是的，你完全是在重新创造一些东西，而Scrum可能是没有好处的。如果你正在建造一架新飞机，而你的要求永远不会改变，我就不会驾驶那架飞机。

当然，如果您有一个项目，您有非常明确的需求在前面，那么您可以瀑布式地把它们抛在开发人员面前，两年后再回来满足您的梦想软件。

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

通常，顾客不知道他们需要什么。它们无法提供完整和具体的要求。迭代方法在这里有帮助:构建一个小东西，然后向客户征求反馈。是的，这“浪费”了演示和计划下一个迭代的时间。但是，为一个sprint构建错误的东西，然后快速地纠正需求，比为整个项目构建错误的东西要好得多。也就是说，尽管预先的需求可能允许更有效的开发，但迭代方法将更加有效。

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

最后，世界不会在这个项目中停滞不前。外部制度改变，优先次序改变，人也改变。假装软件项目的需求不会改变是个坏主意，除了简短的项目。

所有这些过程级的好处都忽略了敏捷方法的重大优势:如果做得正确，敏捷会让每个人都更快乐。其中最大的一个是敏捷技术专注于在短时间内提供真正的价值。这给开发过程带来了可见度，使涉众对项目有了合理的控制，而且比朝着一个遥远的目标努力更有动力。与此相关的是敏捷团队在很大程度上是自组织的。对日常工作的掌控感让人们觉得自己很有价值，因此更有可能做出最好的贡献。

你的同事并没有错，瀑布式的项目可以有他们的位置。你也没有错，一些敏捷的实践可能是浪费时间的仪式。但是忽略敏捷和迭代方法的好处是完全愚蠢的，特别是更好的风险管理和对个人的尊重。这些是你在每个项目中都想要的东西。如果有必要的话，团队可以尝试在内部实现其中的一些功能，但是当每个人都在工作的时候，流程会更好地工作。