scrum - 当需求明确时我们是否应该使用 Scrum

Question

我尝试在我的团队中练习 Scrum。但是我的同事问我：

我们的软件有明确的要求。那么为什么我们应该使用 Scrum

我该如何说服他从这个案子中解脱出来。

Answer 1

没有人应该使用 scrum，就像他们应该使用 vi 或 emacs、Tide 洗衣粉或松脆的花生酱一样。Scrum 只是团队合作的众多方式之一。如果您的团队已经很好地协同工作，则可能没有充分的理由切换到 Scrum。

Scrum 的好处在于它可以帮助团队将一个大问题简化为一系列小问题，并及时、按优先顺序为这些问题提供解决方案。它还可以让您更轻松地查看您是否尽早而不是稍后构建错误的东西，以便您仍有时间进行更正。

如果软件行业在过去几十年中学到了什么，那就是需求一直在变化。Scrum 旨在接受这一事实，而不是希望它不会发生。

从管理的角度来看，scrum 允许项目经理更准确地预测整个项目何时完成。历史表明，任务越小，估计就越容易。如果您已经拥有并了解您的要求，但您正在构建您估计需要两个月的东西，可能需要两个月，但可能需要三个月。或四个。或八。经历制作故事和调整大小的过程可能会产生更准确的估计。

综上所述，如果您的团队不愿意，您绝对不应该使用scrum。当团队使用 Scrum ，而不是个人集合时，Scrum 就可以工作。如果整个团队没有一起想要遵循 scrum，scrum 将是无效的。

Answer 2

敏捷可能是一件好事的原因有很多，假设尽管 100% 清楚需求是什么，但不清楚最有价值的执行顺序是什么，并且提早交付部分产品可能已经提早返回价值。

1. 一些功能的早期交付可能已经释放了价值。可以通过首先发布管理模块，然后是打印模块，然后是报表模块，最后是底层业务逻辑来构建应用程序。按照这个顺序，在实际实现业务逻辑之前，值将是 0。在那段时间里，其他模块将尘土飞扬，它们的价值将被延迟。通过首先发布业务逻辑和部分报告和管理模块，您可以更早地将应用程序投入生产并更快地释放价值。这样你会有更好的投资回报率。

2. 提前交付使您能够证明您的架构、部署和基础设施。通过以较小的部分交付您的产品（这可能允许您的一小部分用户及早使用它），您可以及早证明您的架构（从而降低风险），并且您有多个机会来测试您的部署脚本，确保一旦您的应用程序被大量使用，您可以在更短的时间内部署修复程序，并且对最终用户的影响要小得多。

3. 提前交货给出反馈。您认为（假设）要求是 100% 明确的。在许多情况下，它们很少是这样，或者通过查看实际应用程序可能会意识到它实际上并没有完全完成它需要做的事情。通过定期展示工作软件，您有机会不断证明您 100% 了解需求。如果你做更传统的瀑布，你赌你知道要求。在敏捷的方式中，出错的风险要低得多，因为你会很早就知道自己错了，并且仍然有机会改变方向。

4. 许多应用程序的 60% 功能从未使用过. 以微软word为例。有多少人实际使用可扩展性模型？嵌入式 XML？以及随着时间的推移潜入产品中的更多功能。诚然，这些功能中的每一个都有市场，但很多人可以使用稍微高级一点的写字板版本。除非你有 Microsoft 的市场影响力，否则以瀑布方式构建具有 word 的所有功能然后发布它的应用程序将非常、非常、昂贵。敏捷地做它可以让你尽早停止，从不构建无论如何都不需要的功能。对于许多瀑布式开发项目，需求通常比实际需要的要多。许多“企业”要求的比他们最终会得到的要多，比许多人认为的遗憾要安全得多，

5. 你能证明 100% 已知需求的假设是正确的吗？我想一个人做不到。特别是因为需求往往会随着时间而变化。但是对于小型项目或非常明确的工作（可能是法律或某种认证要求），人们可以确切地知道需要什么并构建它。

您只提到要求是已知的。这是否意味着您的开发人员已经确切知道如何构建它？你有没有弄清楚如何以及是否可以测试它？你知道最有用的交付顺序是什么吗？您的基础架构是否能够处理应用程序？所有这些问题都可以通过构建实际产品的一小部分并不断集成它们来轻松回答。

当然，您可能能够在纸上准确地计算出所有部分如何组合在一起，在极少数情况下可行，当您了解领域，使用经过验证的技术（通常是稍旧的技术）并且已经构建了非常相似的东西至少 3 次。在这些情况下，如果您允许自己通过使用旧的东西来制造一些技术债务，那么您可能不需要任何形式的敏捷。

现在，您是否需要在此过程中进行大量的积压工作？如果很多要求是已知的，也许不会。出于所有其他充分的理由，我说以敏捷的方式工作有很多好处，尤其是在所有需求都被假定为已知的情况下。

如果您的团队认同这些理由，那么一定要敏捷。无论是 Scrum 还是其他。至少定期交付并确保您的工作得到持续测试和部署。如果您的团队不购买它，请尝试以尝试包含上述要点的方式构建您的瀑布项目。定期交付，确保您的工作得到持续测试和部署……等等……这听起来很敏捷，至少是迭代和增量交付；）。