理解敏捷

Question

我最近转到了一个遵循敏捷开发模式的新组织。我们正在工作的当前项目由于最近报告的许多需求更改而停滞不前。由于这是我的第一个敏捷任务(在非敏捷环境中工作了4年)，所以很难区分真正的问题所在。

Ruby on Rails是用于开发的平台。既然我不能问一个模糊的问题，我就把范围缩小到这个范围。

在敏捷中，业务团队可以随意放松和提出需求吗？(在最后的冲刺过程中给出的一些要求改变了我们应用程序的整个设计)

或者，是开发团队的错误，没有预见到应用程序的无数可能性，并且没有一个可以欢迎异常变化的具体设计？

Answer 1

在敏捷中，业务团队可以随意放松和提出需求吗？(在最后的冲刺过程中给出的一些要求改变了我们应用程序的整个设计)

这是可以的(尽管不明智;-)...因此，敏捷开发团队会告诉他们“好吧，伙计们，这将花费这么多额外的时间，从而导致这么多的进度延误。”

• 如果他们愿意付出代价，那么一切都很好。
• 如果他们决定也许新功能毕竟不那么紧急，那么一切也都很好。
• 如果他们坚持包括新需求并保持原来的时间表，那么这个项目就不是敏捷的:-(

，或者，是开发团队的错误，没有预见到应用程序的无数可能性，没有一个可以欢迎异常变化的具体设计？

我不认为设计应该准备好欢迎任何类型的变化和任何新的功能-这只会导致臃肿的软件，以及大量的额外工作，最终证明是无用的。

敏捷项目也应该有一些路线图，以便开发人员至少有一个粗略的想法，产品应该在一年的时间等。这将允许他们向前计划和扩展设计，为未来可能的变化腾出空间。

如果业务没有及时提供有关路线图的信息(或者如果它被证明是不可靠的)，那就是(通常-除非真正不可预见的市场/环境变化)业务的错误。如果团队没有明智地使用这些信息，那是他们的错。

Answer 2

敏捷并不意味着你没有需求或规范，或者你可以自由和轻松地使用它们。业务领导需要知道他们想要什么。敏捷的好处是，如果您确实需要更改路径，您可以以一种更容易的方式完成，因此您可以快速适应。

无论您的开发方法是什么，更改需求都将是痛苦的。至少在那个时间点上，仍然需要有一个强有力的明确计划。

Answer 3

敏捷项目应该有需求收集、设计、分析、编码、测试，就像瀑布开发模型一样。然而，在敏捷项目中，阶段应该覆盖较少的基础，因此发生得更快。

我同意Péter Török的回答，但它也是敏捷团队或敏捷团队经理的责任，告诉业务团队，如果他们将新需求推迟到下一个需求阶段，项目将在每一轮都提供更好的结果。由于一轮应该是30 - 90天，大多数新的要求可以等待。少数不能等待的需求，需要有时间和进度成本。