常见的敏捷开发工具_常见的敏捷异议

常见的敏捷开发工具

上次（ “瀑布在……时起作用” ）我答应讨论一些对“敏捷”的普遍反对意见。 （实际上，读回这篇文章后，我对我的“敏捷开发的十二个神话”的感觉很震惊，该博客最初是两年前的博客文章，名为“ 11个敏捷的两个真理的神话” 。）

（顺便道歉， “瀑布在……发生时才起作用”是第一次被误贴了，我已经解决了。）

“瀑布是最合适的，因为我们的要求是已知且稳定的”

所以呢？ 敏捷在稳定的需求下工作出色，在变化的需求下也能很好地工作。

“范围无法灵活”

往上看。

如果范围无法灵活调整，您将全部完成。 范围一直在传统项目上扩展。 不管有多少传统项目说“范围是固定的”，一旦它们接近尾声并且没有更多的钱，人或时间可用， 范围总是在变化 。

“我们同时从事多个项目”

和？ 它所有的工作要做。 如果您想进行全面讨论，请参阅Xanpan 。

我认为一些Scrum文章谈论的是“专用”或“环围”团队。 我从未见过一支没有行李的球队。 正如约翰·列侬（John Lennon）可能说的那样：“在制定计划时，没有项目工作发生在我们身上。”

“正在建造的东西不能分解成较小的碎片”

好吧，你试图分解它吗？ –许多团队跳到这个假设，而没有试图分解它。 分解工作是一种技能，仅仅是因为您尝试了一次却没有神奇地发生，并不意味着它就不能分解。

如果您不能寻求帮助？ 您是否要求某人（例如我！）提供帮助？ –分解问题并不总是那么容易，获得一些帮助可能会有所帮助。

如果您无法分解但您的竞争对手可以怎么办？

我相信，如果您采取正确的措施，几乎所有事情都可以分解。 而且，如果您不能分解它，那么也许它不是可以在软件中实现的东西。

“敏捷在未开发的项目上工作，但是我们有一个遗留系统。”

和

“敏捷可以在遗留系统上工作，但我们正在构建新的东西。”

（现在，我真的是在重复自己–参见“两个真理的11个敏捷神话” ）

他们俩都不对吗？ 我已经看到敏捷在新旧开发上都在工作，而且我听说双方都说“因为……而行不通”。

草地的另一侧总是较绿。

“我们的项目融资模式不允许敏捷”

所以呢？ 您可以做很多事，而这对财务没有影响。

不要再指着其他阻止你的人，尽你所能，一次解决一个问题。

翻译自: https://www.javacodegeeks.com/2015/03/common-agile-objections.html

常见的敏捷开发工具