常见的敏捷开发工具
上次( “瀑布在……时起作用” )我答应讨论一些对“敏捷”的普遍反对意见。 (实际上,读回这篇文章后,我对我的“敏捷开发的十二个神话”的感觉很震惊,该博客最初是两年前的博客文章,名为“ 11个敏捷的两个真理的神话” 。)
(顺便道歉, “瀑布在……发生时才起作用”是第一次被误贴了,我已经解决了。)
“瀑布是最合适的,因为我们的要求是已知且稳定的”
所以呢? 敏捷在稳定的需求下工作出色,在变化的需求下也能很好地工作。
“范围无法灵活”
往上看。
如果范围无法灵活调整,您将全部完成。 范围一直在传统项目上扩展。 不管有多少传统项目说“范围是固定的”,一旦它们接近尾声并且没有更多的钱,人或时间可用, 范围总是在变化 。
“我们同时从事多个项目”
和? 它所有的工作要做。 如果您想进行全面讨论,请参阅Xanpan 。
我认为一些Scrum文章谈论的是“专用”或“环围”团队。 我从未见过一支没有行李的球队。 正如约翰·列侬(John Lennon)可能说的那样:“在制定计划时,没有项目工作发生在我们身上。”
“正在建造的东西不能分解成较小的碎片”
好吧,你试图分解它吗? –许多团队跳到这个假设,而没有试图分解它。 分解工作是一种技能,仅仅是因为您尝试了一次却没有神奇地发生,并不意味着它就不能分解。
如果您不能寻求帮助? 您是否要求某人(例如我!)提供帮助? –分解问题并不总是那么容易,获得一些帮助可能会有所帮助。
如果您无法分解但您的竞争对手可以怎么办?
我相信,如果您采取正确的措施,几乎所有事情都可以分解。 而且,如果您不能分解它,那么也许它不是可以在软件中实现的东西。
“敏捷在未开发的项目上工作,但是我们有一个遗留系统。”
和
“敏捷可以在遗留系统上工作,但我们正在构建新的东西。”
(现在,我真的是在重复自己–参见“两个真理的11个敏捷神话” )
他们俩都不对吗? 我已经看到敏捷在新旧开发上都在工作,而且我听说双方都说“因为……而行不通”。
草地的另一侧总是较绿。
“我们的项目融资模式不允许敏捷”
所以呢? 您可以做很多事,而这对财务没有影响。
不要再指着其他阻止你的人,尽你所能,一次解决一个问题。
翻译自: https://www.javacodegeeks.com/2015/03/common-agile-objections.html
常见的敏捷开发工具