The simple answer is: we don't, as keeping track of the changes doesn't usually make much sense or bring any benefits.
However, if for any reason you must keep track of changes (like wasteful overhead forced upon you by "regulations" - not unheard of, right?) the best thing to do is to keep your backlog in such a way that you would be able to tell how and when it did change. This is where scrum software tools can help, as doing it with a board and index cards would be a major pain. Sometimes just a simple history of all changes to any backlog item (like what we have in our Scrum tool) will suffice, sometimes you will need more complex reporting (available in some more complex tools), and sometimes you will have to produce some additional documents.
BTW - I understand "a requirement" to mean a single backlog item, usually a user story (or epic). As such those usually don't change a lot, their position on the backlog does, but usually not the stories themselves. Recording changes of stories position on the backlog doesn't make much sense in an agile project, however recording when stories were done (keeping data about past sprints) is a good practice. Recording changes to the story itself (edits, changes of attachments etc.) would be where the Scrum tool should help you if this is what you want/have to track.
You could version your requirements document(s) right along with the source code... that way, you'd have the documents that detailed the requirements at any point in time, along with the code that implements (or attempts to) those requirements.
That being said, I don't think this is any different in "agile" or "scrum" than it is in any development process.
A wiki linked to your user stories / requirements tool is probably your best bet.
We use Assembla as our main collaboration tool for our agile projects. It has a wiki where you can document your requirements and a ticketing tool that can be easily linked to the wiki (and code check-ins) through simple tags for requirements traceability.
Both the wiki and the ticketing tool keep history, so it would be easy to view and document changes over time.
As others have mentioned, from a process perspective, it's probably better to break down your requirements / stories from epics into smaller stories and ADD new stories to capture new requirements as things progress. The tool I mentioned (and I'm sure several other tools) allow you to do this easily and link the items together if you want to see how a feature progressed or was added to over time.
Why do you need to track requirement changes (I have a lot of reasons, but what problem are you trying to solve?). Do you have the option of building your product iteratively or do you need to figure most of it out up front ?
If you are able to build iteratively, I would skip requirements version management. Individual sprint deliveries will define the product at different points in time. The next sprint backlog will define committed work.
The master backlog or wish list can change as needed. It may not be necessary to track changes as the work hasn't been committed.
If you do need more control, I like Paddyslacker's recommendation of a Wiki. Most other mechanisms don't handle the relationship concepts of epics and the break down of requirements. I have always found a single file to be insufficient for complex features.
There is nothing built-on SCRUM that resembles requirement version management. That you require it may be a sign that you are either not really implementing SCRUM or that SCRUM is not the right process for you. If I had to implement something similar I would first look into your product backlog (from which detailed sprint tasks are derived) and map stories/use cases/requirements versions to them, then I would check for updates on already released items during sprint planning to see if a new "update code to match requirement" task are required for the sprint.
(I'm avoiding talking about agile as there are hundreds of agile processes out there, perhaps somebody else can give their point of view on AUP or Crystal Clear)
You didn't mention what platform you develop on but if you use TFS; it keeps track of all changes to Backlog items, when they were changed, and by whom.
发布评论
评论（6）
简单的答案是：我们不这样做，因为跟踪变化通常没有多大意义或带来任何好处。
但是，如果出于任何原因您必须跟踪更改（例如“法规”强加给您的浪费性开销 - 并非闻所未闻，对吧？），最好的办法就是以这样的方式保留您的积压工作，以便您能够告诉我们它是如何以及何时发生变化的。这就是 Scrum 软件工具可以提供帮助的地方，因为使用看板和索引卡来完成此操作将是一个很大的痛苦。有时，只需对任何待办事项项进行所有更改的简单历史记录（例如我们在 我们的 Scrum 工具 中的内容）就足够了，有时您将需要更复杂的报告（在一些更复杂的工具中可用），有时您将不得不生成一些额外的文档。
顺便说一句 - 我理解“要求”是指单个积压项目，通常是用户故事（或史诗）。因此，这些内容通常不会发生太大变化，它们在积压工作中的位置会发生很大变化，但故事本身通常不会发生太大变化。在敏捷项目中记录待办事项中故事位置的变化没有多大意义，但是记录故事何时完成（保留有关过去冲刺的数据）是一个很好的实践。如果您想要/必须跟踪，记录故事本身的更改（编辑、附件更改等）将是 Scrum 工具应该为您提供帮助的地方。
The simple answer is: we don't, as keeping track of the changes doesn't usually make much sense or bring any benefits.
However, if for any reason you must keep track of changes (like wasteful overhead forced upon you by "regulations" - not unheard of, right?) the best thing to do is to keep your backlog in such a way that you would be able to tell how and when it did change. This is where scrum software tools can help, as doing it with a board and index cards would be a major pain. Sometimes just a simple history of all changes to any backlog item (like what we have in our Scrum tool) will suffice, sometimes you will need more complex reporting (available in some more complex tools), and sometimes you will have to produce some additional documents.
BTW - I understand "a requirement" to mean a single backlog item, usually a user story (or epic). As such those usually don't change a lot, their position on the backlog does, but usually not the stories themselves. Recording changes of stories position on the backlog doesn't make much sense in an agile project, however recording when stories were done (keeping data about past sprints) is a good practice. Recording changes to the story itself (edits, changes of attachments etc.) would be where the Scrum tool should help you if this is what you want/have to track.
您可以将需求文档与源代码一起版本化...这样，您就可以在任何时间点获得详细说明需求的文档，以及实现（或尝试）这些需求的代码。
话虽这么说，我认为“敏捷”或“scrum”与任何开发过程没有任何不同。
You could version your requirements document(s) right along with the source code... that way, you'd have the documents that detailed the requirements at any point in time, along with the code that implements (or attempts to) those requirements.
That being said, I don't think this is any different in "agile" or "scrum" than it is in any development process.
链接到您的用户故事/需求工具的 wiki 可能是您最好的选择。
我们使用 Assembla 作为敏捷项目的主要协作工具。它有一个 wiki，您可以在其中记录您的需求，还有一个票务工具，可以通过简单的标签轻松链接到 wiki（和代码签入），以实现需求可追溯性。
wiki 和票务工具都会保留历史记录，因此可以轻松查看和记录随时间的变化。
正如其他人提到的，从流程的角度来看，最好将您的需求/故事从史诗分解为更小的故事，并随着事情的进展添加新的故事以捕获新的需求。我提到的工具（我相信还有其他几个工具）可以让您轻松地完成此操作，如果您想了解某个功能如何随着时间的推移进展或添加，可以将这些项目链接在一起。
A wiki linked to your user stories / requirements tool is probably your best bet.
We use Assembla as our main collaboration tool for our agile projects. It has a wiki where you can document your requirements and a ticketing tool that can be easily linked to the wiki (and code check-ins) through simple tags for requirements traceability.
Both the wiki and the ticketing tool keep history, so it would be easy to view and document changes over time.
As others have mentioned, from a process perspective, it's probably better to break down your requirements / stories from epics into smaller stories and ADD new stories to capture new requirements as things progress. The tool I mentioned (and I'm sure several other tools) allow you to do this easily and link the items together if you want to see how a feature progressed or was added to over time.
为什么需要跟踪需求变更（我有很多原因，但是你想解决什么问题？）。您是否可以选择迭代地构建您的产品，或者您是否需要预先计算出大部分产品？
如果您能够迭代构建，我会跳过需求版本管理。单独的冲刺交付将在不同的时间点定义产品。下一个冲刺积压工作将定义承诺的工作。
主待办事项或愿望清单可以根据需要进行更改。由于工作尚未提交，因此可能无需跟踪更改。
如果您确实需要更多控制，我喜欢 Paddyslacker 推荐的 Wiki。大多数其他机制不处理史诗的关系概念和需求分解。我一直发现单个文件不足以满足复杂的功能。
Why do you need to track requirement changes (I have a lot of reasons, but what problem are you trying to solve?). Do you have the option of building your product iteratively or do you need to figure most of it out up front ?
If you are able to build iteratively, I would skip requirements version management. Individual sprint deliveries will define the product at different points in time. The next sprint backlog will define committed work.
The master backlog or wish list can change as needed. It may not be necessary to track changes as the work hasn't been committed.
If you do need more control, I like Paddyslacker's recommendation of a Wiki. Most other mechanisms don't handle the relationship concepts of epics and the break down of requirements. I have always found a single file to be insufficient for complex features.
没有任何内置 SCRUM 类似于需求版本管理。您需要它可能表明您没有真正实施 SCRUM，或者 SCRUM 不是适合您的流程。如果我必须实现类似的东西，我会首先查看您的产品待办事项（从中派生出详细的冲刺任务）并将故事/用例/需求版本映射到它们，然后我会在冲刺计划期间检查已发布项目的更新查看冲刺是否需要新的“更新代码以匹配需求”任务。
（我避免谈论敏捷，因为那里有数百个敏捷流程，也许其他人可以就 AUP 或 Crystal Clear 发表他们的观点）
There is nothing built-on SCRUM that resembles requirement version management. That you require it may be a sign that you are either not really implementing SCRUM or that SCRUM is not the right process for you. If I had to implement something similar I would first look into your product backlog (from which detailed sprint tasks are derived) and map stories/use cases/requirements versions to them, then I would check for updates on already released items during sprint planning to see if a new "update code to match requirement" task are required for the sprint.
(I'm avoiding talking about agile as there are hundreds of agile processes out there, perhaps somebody else can give their point of view on AUP or Crystal Clear)
你没有提到你在什么平台上开发，但如果你使用TFS；它会跟踪待办事项列表项的所有更改、更改时间以及更改者。
You didn't mention what platform you develop on but if you use TFS; it keeps track of all changes to Backlog items, when they were changed, and by whom.