我最近转向了一个遵循敏捷开发模式的新组织。由于最近报告的许多需求变化，我们正在进行的当前项目已停滞不前。由于这是我的第一次敏捷任务（在非敏捷环境中工作4年后），因此有点难以区分问题所在。
Ruby on Rails是用于开发的平台。由于我不能提出一个模糊的问题，我将把它缩小到这个范围。
在敏捷方面，业务团队可以放松并随意提出要求吗？ （最终冲刺期间给出的一些要求改变了我们应用程序的整个设计）
或者，开发团队的错误是没有预见到应用程序的众多可能性，也没有一个可能会遇到异常变化的具体设计？
答案 0 :(得分：10)
在敏捷方面，业务团队可以放松并随意提出要求吗？ （最终冲刺期间给出的一些要求改变了我们应用程序的整个设计）
没关系（虽然不是明智的; - ）......所以敏捷的开发团队会告诉他们“好人，这会耗费额外的时间，因此很多时间表滑点。“
或者，开发团队的错误是没有预见到应用程序的众多可能性，也没有一个可能会遇到异常变化的具体设计？
我认为设计不应该随时欢迎任何类型的更改以及任何新功能 - 这只会导致英国媒体报道，而且还有很多额外的功能最终证明无用的工作。
敏捷项目也应该有某种路线图，这样开发人员至少可以大致了解产品应该在一年的时间内等等。这将使他们能够计划前进并扩展设计以腾出空间可能的未来的变化。
如果企业没有及时提供有关路线图的信息（或者证明它不可靠），那就是（通常 - 除非出现无法预料的市场/环境变化）业务的错误。如果团队没有明智地使用这些信息，那就是他们的错。
答案 1 :(得分：6)
敏捷并不意味着您没有要求或规格，或者您可以随心所欲地使用它们。业务线索需要知道他们想要什么。敏捷的好处是，如果你确实需要改变路径，你可以更容易地做到这一点，这样你就可以快速适应。
无论您的开发方法如何，需求变更都会很痛苦。至少在那个时候，仍然必须有一个强有力的明确计划。
答案 2 :(得分：1)
敏捷项目应该有需求收集，设计，分析，编码，测试;就像瀑布式开发模型一样。但是，在敏捷项目中，阶段应该覆盖较少的地面，因此发生得更快。
我同意PéterTörök的回答，但敏捷团队或敏捷团队经理也有责任教导业务团队，如果他们将新要求推迟到下一个需求阶段，那么该项目每轮都会提供更好的结果。由于一轮应该是30-90天，大多数新要求可以等待。无法等待的少数要求，需要有时间和进度成本。
答案 3 :(得分：0)
Scrum Master的观点在这里。听起来，企业缺乏对“敏捷”是什么或者如何实现它的清晰认识。敏捷需要应用于结构，无论是Scrum还是看板或类似的东西。它常常是“我们不设计或记录”事物的同义词。
如果您的意思是使用Scrum的团队，只要产品负责人和Scrum Master处于他们的游戏之上，这就是可以管理的。
如果业务团队“随意”提出不符合要求的要求，则由产品负责人承担这些要求，并在进行sprint规划之前确定任务列表的优先级。如果他们与已经完成的工作不一致，由于团队需要重构等，他们可能被估计为大型故事。然后由产品负责人决定是否值得继续使用它们，或者处理与已经完成的工作一致的替代故事。
对于整个Scrum团队来说，这将是一个艰难的环境，但是你会期望企业通过改变冲刺之间的方向来看到失去的价值，并希望在不久之前将产品与方向对齐。由于没有预料到这一点，开发团队当然不是错，我更想说Scrum Master和产品负责人需要对所涉及的业务部门说些话。
答案 4 :(得分：0)
sprint和backlog之间需要有一个缓冲区。
业务团队拥有积压的积压和优先级，但是一旦开发团队在sprint中承诺了x个故事，那么业务团队修改其内容是不明智的。如果你发现这种情况发生，我会建议缩短短跑的长度。
然而，如果出现一个超级紧急的新要求，就是不能等待下一个冲刺，那么必须删除另一个类似点值的故事/故事。
业务团队管理他们的待办事项非常重要，这样在sprint计划会议中，下一组故事可以完全显示，确定优先级并准备就绪。
答案 5 :(得分：0)
在敏捷方面，业务团队可以放松并随意提出要求吗？
是的，可以改变要求（可能不会放松），但在我们的团队中，我们不会破坏或改变sprint的范围，除非当前sprint范围内的工作因此而变得多余产品所有者（而不是sprint积压）添加到产品待办事项中的新要求另请注意，如果您承诺在sprint中完成100分的工作，那么您将完成80分并且需求发生变化以使sprint中断，然后团队仍然根据PO的原始要求提供80个冲刺点。 （在与外部客户打交道时很重要）
开发团队的错误是没有预见到应用程序的众多可能性，而且没有一个可以迎接异常变化的具体设计？
我们对正在处理的整体功能/项目有非常高层次的了解，但在我们接受用户故事（功能/项目的细分）之前，我们确保我们完全了解产品负责人想要的内容。如果产品所有者不确定，那么我们会询问知情人。注意我并不是说你计划整个项目，你只需要记下1或2个冲刺的用户故事。
（我就是这样做的，但没有规定性的规则，每条敏捷规则都会让敏捷变得更敏捷 - 我的意见）
答案 6 :(得分：0)
不，不能随意提出要求。
有一个普遍的概念，即业务和开发每天都在一起工作，并且不是以书面形式进行主要工作，而是面对面（通常是审查或计划内容）。我们的想法不是对未来作出太多假设，而是对其进行过多假设。
作为一名程序员完成了这项工作，我能给出的唯一建议是：改变设置。当您了解您的框架时，产品方面将了解业务。 如果你遇到这样的问题：解决这个问题真的很重要。这就是你的冲刺：在某事情上失败然后在复古之后修复它。这样做一段时间应该导致一个理智的组织过程如何在适当的时刻获得所有要求。
然而：正确的工程设计已经损害了任何人，以及适当的安全和需求工程。如果你需要这样做尽管你的敏捷过程：那就这样吧。