在Scrum或其他敏捷流程中 - 您如何处理需求版本

Question

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

您可能在版本1中有一个要求，在版本8中有很大的改变。您如何跟踪版本之间的这种变化？

Answer 1

简单的答案是：我们不这样做，因为跟踪变化通常没有多大意义或带来任何好处。

然而，如果出于任何原因你必须跟踪变化（例如“法规”强加给你的浪费开销 - 不是闻所未闻，对吗？）最好的办法就是保持你的积压工作以便你能够告诉它如何以及何时发生变化。这是scrum软件工具可以提供帮助的地方，因为使用电路板和索引卡进行操作将是一个主要的痛苦。有时只是简单记录所有积压项目的所有更改（就像我们在our Scrum tool中所做的那样）就足够了，有时您需要更复杂的报告（在一些更复杂的工具中可用），有时您将不得不生产一些额外的文件。

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

Answer 2

您可以将您的需求文档与源代码一起编辑......这样，您就可以获得在任何时间点详细说明需求的文档，以及实现（或尝试）那些要求。

话虽如此，我认为“敏捷”或“混乱”与任何开发过程中没有任何不同。

Answer 3

与您的用户故事/需求工具相关联的Wiki可能是您最好的选择。

我们使用Assembla作为敏捷项目的主要协作工具。它有一个wiki，您可以在其中记录您的需求，以及可以通过简单的标签轻松链接到wiki（和代码签入）的票务工具，以便跟踪需求。

wiki和票务工具都保留了历史记录，因此随着时间的推移，查看和记录更改很容易。

正如其他人所提到的那样，从流程的角度来看，最好将您的需求/故事从史诗分解为更小的故事，然后添加新故事以随着事情的发展捕捉新的需求。我提到的工具（我确定其他几种工具）可以让您轻松完成这项工作并将项目链接在一起，如果您想了解功能如何进展或随着时间的推移而添加。

Answer 4

为什么需要跟踪需求变化（我有很多原因，但你想解决什么问题？）。您是否可以选择迭代地构建产品，还是需要预先确定大部分产品？

如果您能够迭代构建，我会跳过需求版本管理。个别冲刺交付将在不同时间点定义产品。下一个sprint backlog将定义已提交的工作。

主要积压或愿望清单可以根据需要进行更改。可能没有必要跟踪工作尚未提交的更改。

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

Answer 5

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

（我正在避免谈论敏捷，因为那里有数百个敏捷流程，也许其他人可以在AUP或Crystal Clear上提出他们的观点）

Answer 6

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