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

Question

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

您可能在版本1中有一个需求，该需求在版本8中发生了很大的更改。您如何跟踪版本之间的这种更改？

Answer 1

简单的答案是:我们没有，因为跟踪变化通常没有多大意义，也没有带来任何好处。

然而，如果出于任何原因，你必须跟踪变化(比如“条例”强加给你的浪费性开销-这不是闻所未闻的，对吧？)最好的方法是保持待办事项，这样您就能够知道它是如何以及何时发生变化的。这是scrum软件工具可以提供帮助的地方，因为用板和索引卡来做这件事将是一个很大的痛苦。有时，只要简单地记录对任何待办事项的所有更改(就像我们在我们的Scrum工具中所做的那样)，有时您将需要更复杂的报告(在一些更复杂的工具中可用)，有时还需要生成一些额外的文档。

顺便说一句--我理解“一个需求”指的是一个单一的待办事项，通常是一个用户故事(或史诗)。因此，这些人通常不会有太大的变化，他们在待办事项中的立场确实如此，但通常不会改变故事本身。在敏捷项目中记录故事位置的变化在敏捷项目中没有多大意义，但是记录故事完成的时间(保存关于过去sprint的数据)是一种很好的做法。记录对故事本身的更改(编辑、附件的更改等)如果这是您想要/必须跟踪的东西，Scrum工具应该帮助您。

Answer 2

您可以将您的需求文档与源代码一起编辑.这样，您就可以得到在任何时间点详细描述需求的文档，以及实现(或尝试)这些需求的代码。

尽管如此，我并不认为这与任何开发过程中的“敏捷”或"scrum“有什么不同。

Answer 3

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

我们使用大会作为敏捷项目的主要协作工具。它有一个wiki，您可以在其中文档您的需求和票务工具，可以很容易地链接到wiki (和代码签入)通过简单的标签需求可追溯性。

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

正如其他人所提到的，从过程的角度来看，最好将您的需求/故事从史诗分解为更小的故事，并添加新的故事来捕捉新的需求。我提到的工具(我肯定还有其他几个工具)允许您轻松地完成这一任务，并将项目链接到一起，如果您想要查看某一特性是如何进展的，或者是随着时间的推移而添加的。