ruby-on-rails - 理解敏捷

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。




Improve this question




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

Ruby on Rails 是用于开发的平台。由于我不能问一个模糊的问题，我将把它缩小到这一点。

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

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

Answer 1

In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)

没关系(虽然不明智；-)...所以敏捷开发团队会告诉他们“好家伙，这将花费这么多额外的时间，因此会导致这么多的进度延误。”

如果他们愿意付出代价，那一切都很好。

如果他们认为新功能毕竟不是那么紧急，那么一切都很好。

如果他们坚持包含新的需求并保持原来的时间表，那么这个项目就不是敏捷的:-(

Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

我认为设计不应该准备好接受任何类型的更改和任何新功能——这只会导致膨胀软件，以及最终证明无用的大量额外工作。

敏捷项目也应该有某种路线图，以便开发人员至少有一个粗略的想法，产品应该在一年后的位置等。这将使他们能够提前计划并扩展设计，为可能的 future 腾出空间变化。

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