在Scrum中或其它敏捷过程 - 你怎么处理要求的版本

Question

在Scrum和/或其他敏捷方法你如何处理的要求简单版本？我认为有很多组织是敏捷的，但也需要跟踪为了监管目的的需求变更等等。

您可以在第1版要求其在8版本实质性改变你要如何追踪那种版本之间的变化呢？

Answer 1

简单的回答是：我们不，因为跟踪这些变化通常没有多大意义或带来任何好处。但是，如果出于任何原因，你必须跟踪变化（比如“条例”强加给你的浪费性开销 - 这是前所未闻的，对吗？）最好的办法是让你的积压保持这样的状态你将能够知道它是如何以及何时改变的。这正是Scrum软件工具可以提供帮助的地方，因为使用电路板和索引卡做这件事会是一大痛苦。有时候，任何积压项目的所有变化（如我们在our Scrum tool中的变化）的所有变化的简单历史就足够了，有时您需要更复杂的报告（可用于一些更复杂的工具），有时您必须生成一些额外的文档。

顺便说一句 - 我明白了“要求”是指单积压的项目，通常是用户故事（或史诗）。因为这些通常不会发生很大的变化，所以他们在积压中的位置确实如此，但通常不是故事本身。在积压项目中记录故事位置的变化在敏捷项目中没有多大意义，但是当故事完成时（记录关于过去的冲刺的数据）是一个好习惯。记录故事本身的变化（编辑，附件更改等）将是Scrum工具应该帮助您的位置，如果这是您想要/必须跟踪的。

Answer 2

你可以版本的需求文档（S）右随着源代码......这样一来，你就必须在那个任意时间点的详细要求，用代码实现沿文件（或企图到）这些要求。

话虽这么说，我不认为这是“敏捷”或“争球”比在任何开发过程中的任何不同。

Answer 3

没有什么内置的SCRUM类似于需求版本管理。你需要它可能是一个迹象，你要么没有真正实施SCRUM，要么SCRUM不适合你。如果我必须实现类似的东西，我会首先查看您的产品积压（从中派生出详细的冲刺任务），并将故事/用例/需求版本映射到他们，然后我会在冲刺计划期间检查已发布项目的更新查看是否需要新的“更新代码以匹配需求”任务。

（我避免谈论敏捷，因为有数百个敏捷过程的摆在那里，也许别人可以给他们的观点对AUP或水晶透明点）

Answer 4

链接到您的用户故事/需求工具的维基可能是您最好的选择。

我们用Assembla作为我们为我们的敏捷项目的主要协作工具。它有一个wiki，您可以在其中记录需求，并且可以通过简单的标签轻松链接到wiki（以及代码签入）以获取需求可追溯性。

维基和票务工具都保留了历史记录，因此可以轻松查看和记录随着时间​​的变化。

正如其他人所提到的，从流程的角度来看，将史诗般的需求/故事分解成更小的故事，并添加新故事以捕捉新事物随着事情的发展可能会更好。我提到的工具（以及我确定的其他几个工具）可让您轻松完成此操作，并将这些项目链接在一起，以便查看某个功能的进展情况或随着时间的推移而添加的功能。

Answer 5

为什么你需要跟踪需求变化（我有很多原因，但你想解决什么问题？）。你有没有选择迭代地构建你的产品，还是你需要预先考虑大部分内容？

如果你能够迭代构建，我会跳过需求版本管理。个人冲刺运送将在不同的时间点定义产品。下一次冲刺积压将定义提交的工作。

主积压或愿望清单可根据需要更改。由于工作没有落实，因此可能没有必要跟踪更改。

如果你确实需要更多控制，我喜欢Paddyslacker对Wiki的推荐。大多数其他机制不处理史诗和关系要求的关系概念。我总是发现一个文件不足以适应复杂的功能。

Answer 6

你没有提到你开发的平台，但是如果你使用TFS;它会跟踪对Backlog项目的所有更改，更改时间以及由谁进行的更改。