在 Scrum 和/或其他敏捷方法中，您如何简单地处理需求版本？我假设有很多组织是敏捷的，但出于监管等目的，还需要跟踪需求变化。
您可能在版本 1 中有一个需求，而在版本 8 中进行了重大更改。您如何跟踪版本之间的这种变化？
【问题讨论】：
标签： agile scrum requirements
简单的答案是：我们不这样做，因为跟踪更改通常没有多大意义或带来任何好处。
但是，如果出于任何原因您必须跟踪更改（例如“法规”强加给您的浪费性开销 - 并非闻所未闻，对吧？），最好的办法是保持您的积压工作，以便您将能够说出它是如何以及何时发生变化的。这就是 Scrum 软件工具可以提供帮助的地方，因为使用白板和索引卡会很痛苦。有时，任何积压项目的所有更改的简单历史记录（例如我们在our Scrum tool 中的内容）就足够了，有时您将需要更复杂的报告（在一些更复杂的工具中可用），有时您将不得不产生一些额外的文件。
顺便说一句 - 我理解“要求”是指单个待办事项，通常是用户故事（或史诗）。因此，这些通常不会发生太大变化，他们在积压工作中的位置会发生很大变化，但通常不会改变故事本身。记录 backlog 中故事位置的变化在敏捷项目中没有多大意义，但是记录故事何时完成（保留有关过去 sprint 的数据）是一种很好的做法。记录故事本身的更改（编辑、附件更改等）将是 Scrum 工具应该帮助您的地方，如果这是您想要/必须跟踪的内容。
【讨论】：
您可以将您的需求文档与源代码一起版本化...这样，您将拥有在任何时间点详细说明需求的文档，以及实现（或尝试实现）的代码) 那些要求。
话虽如此，我认为这在“敏捷”或“Scrum”中与在任何开发过程中没有什么不同。
【讨论】：
链接到您的用户故事/需求工具的 wiki 可能是您的最佳选择。
我们使用Assembla 作为我们敏捷项目的主要协作工具。它有一个 wiki，您可以在其中记录您的需求和一个票务工具，该工具可以通过简单的标签轻松链接到 wiki（和代码签入）以实现需求可追溯性。
wiki 和票务工具都保留历史记录，因此很容易查看和记录随时间发生的变化。
正如其他人所提到的，从流程的角度来看，最好将您的需求/故事从史诗分解成更小的故事，并添加新故事以随着事情的进展捕捉新的需求。我提到的工具（我相信还有其他一些工具）可以让您轻松完成此操作，并将项目链接在一起，如果您想了解某个功能是如何随着时间的推移而进展或添加的。
【讨论】：
为什么需要跟踪需求更改（我有很多原因，但您要解决什么问题？）。您是否可以选择以迭代方式构建您的产品，或者您是否需要预先确定大部分内容？
如果您能够迭代构建，我会跳过需求版本管理。单独的 sprint 交付将在不同的时间点定义产品。下一个 sprint backlog 将定义已提交的工作。
主积压或愿望清单可以根据需要更改。由于工作尚未提交，因此可能没有必要跟踪更改。
如果您确实需要更多控制权，我喜欢 Paddyslacker 推荐的 Wiki。大多数其他机制不处理史诗的关系概念和需求分解。我一直发现单个文件不足以处理复杂的功能。
【讨论】：
没有任何类似于需求版本管理的内置 SCRUM。您需要它可能表明您没有真正实施 SCRUM，或者 SCRUM 不是适合您的流程。如果我必须实现类似的东西，我会首先查看您的产品待办事项（从中派生出详细的 sprint 任务）并将故事/用例/需求版本映射到它们，然后我会在 sprint 计划期间检查已发布项目的更新以查看冲刺是否需要新的“更新代码以匹配要求”任务。
（我避免谈论敏捷，因为那里有数百个敏捷流程，也许其他人可以就 AUP 或 Crystal Clear 发表他们的观点）
【讨论】：
你没有提到你在什么平台上开发，但如果你使用 TFS；它会跟踪对积压项目的所有更改、更改时间以及更改人。
【讨论】：