从长远来看，需求管理在敏捷项目中如何工作？
在短期内，敏捷项目的需求管理对我来说似乎是一个已解决的问题。 从Scrum角度，新需求或对现有需求的更改是通过用户故事交付的。并且，按Epic或Feature分组的User Stories有助于交付更大，更复杂的需求。 当然，从技术上讲，用户故事不是要求文档。这是一个可管理的工作分组，映射到通常称为功能的垂直切片的内容。这些故事的范围可以通过使用接受标准（AC）来明确定义。 因此，尽管用户故事不是正式的要求，但浏览它们可以使您对他们的基本要求有一个清晰的认识。在短期内。 我之所以说是短期的，是因为随着项目的进展，用户故事的数量会增加。因此，随着时间的流逝，浏览不断增加的故事列表以找到需求的效率越来越低。 当您考虑扩展，取代甚至否定先前故事的用户故事时，此问题会更加复杂。 现在，假设一个项目的开发迭代（生产稳定）之间存在2年的差距。最初的团队消失了，他们所有的知识也消失了。 如果原始团队知道这将要发生（例如，这是企业的性质），那么他们可以采取哪些措施来帮助后续团队？ 当然，待办事项将提供一些信息，但是它几乎不容易浏览。 那么，可以做些什么来帮助后续团队了解项目的状态，包括为什么以及如何到达那里？ 以我的经验，以下几项无效： 积压整理以删除或更新以前的用户故事，以便可以将积压阅读为需求文档。 文档冲刺团队成员的任务是记录系统的当前状态。 通过行为测试的文件。这种方法是我所见过的唯一接近可行的方法。不幸的是，编码行为测试是命名问题的受害者。尽管这些测试可能正确记录了该系统，但要使变动的开发人员团队按照相同的Domain术语，措辞和样式编写测试几乎是不可能的。 因此，重申一下： 长期如何管理敏捷项目需求？