bra*_*boy 3 agile ruby-on-rails
我最近转向了一个遵循敏捷开发模式的新组织.由于最近报告的许多需求变化,我们正在进行的当前项目已经停滞不前.由于这是我的第一个敏捷任务(在非敏捷环境中工作4年后),因此有点难以区分问题所在.
Ruby on Rails是用于开发的平台.既然我不能问一个模糊的问题,我会把它缩小到这个范围.
在敏捷中,业务团队可以放松并随意提出要求吗？(在最后冲刺期间给出的一些要求改变了我们应用的整个设计)
或者,开发团队的错误是没有预见到应用程序的众多可能性,也没有一个可能会遇到异常变化的具体设计？
Pét*_*rök 10
在敏捷中,业务团队可以放松并随意提出要求吗？(在最后冲刺期间给出的一些要求改变了我们应用的整个设计)
这是好的(虽然不明智 ; - )......所以敏捷的开发团队会告诉他们"好人,这会花费额外的时间,因此会导致这么多的时间滑点."
或者,开发团队的错误是没有预见到应用程序的众多可能性,也没有一个可能会遇到异常变化的具体设计？
我不认为设计应该准备好迎接任何变化和任何新功能 - 这只会导致膨胀软件,以及许多额外的工作,最终证明是无用的.
敏捷项目也应该有某种路线图,这样开发人员至少可以大致了解产品应该在一年的时间内等等.这将使他们能够计划前进并扩展设计,为可能的未来腾出空间.变化.
如果企业没有及时提供有关路线图的信息(或者证明它不可靠),那就是(通常 - 除非真正无法预料的市场/环境变化)企业的错误.如果团队没有明智地使用这些信息,那就是他们的错.
敏捷并不意味着您没有要求或规格,或者您可以随心所欲地使用它们.业务线索需要知道他们想要什么.敏捷的好处是,如果你确实需要改变路径,你可以更容易地做到这一点,这样你就可以快速适应.
无论您的开发方法如何,需求的变化都将是痛苦的.至少在那个时候,仍然必须有一个强有力的明确计划.
| 归档时间： |
|
| 查看次数： |
592 次 |
| 最近记录： |