从长远来看，需求管理在敏捷项目中如何工作？

在短期内，敏捷项目的需求管理对我来说似乎是一个已解决的问题。

从Scrum角度，新需求或对现有需求的更改是通过用户故事交付的。并且，按Epic或Feature分组的User Stories有助于交付更大，更复杂的需求。

当然，从技术上讲，用户故事不是要求文档。这是一个可管理的工作分组，映射到通常称为功能的垂直切片的内容。这些故事的范围可以通过使用接受标准（AC）来明确定义。

因此，尽管用户故事不是正式的要求，但浏览它们可以使您对他们的基本要求有一个清晰的认识。在短期内。

我之所以说是短期的，是因为随着项目的进展，用户故事的数量会增加。因此，随着时间的流逝，浏览不断增加的故事列表以找到需求的效率越来越低。

当您考虑扩展，取代甚至否定先前故事的用户故事时，此问题会更加复杂。

现在，假设一个项目的开发迭代（生产稳定）之间存在2年的差距。最初的团队消失了，他们所有的知识也消失了。

如果原始团队知道这将要发生（例如，这是企业的性质），那么他们可以采取哪些措施来帮助后续团队？

当然，待办事项将提供一些信息，但是它几乎不容易浏览。

那么，可以做些什么来帮助后续团队了解项目的状态，包括为什么以及如何到达那里？

以我的经验，以下几项无效：

• 积压整理以删除或更新以前的用户故事，以便可以将积压阅读为需求文档。
• 文档冲刺团队成员的任务是记录系统的当前状态。
• 通过行为测试的文件。这种方法是我所见过的唯一接近可行的方法。不幸的是，编码行为测试是命名问题的受害者。尽管这些测试可能正确记录了该系统，但要使变动的开发人员团队按照相同的Domain术语，措辞和样式编写测试几乎是不可能的。

因此，重申一下：

长期如何管理敏捷项目需求？

在我看来，这是敏捷项目中不为人知的大象：如何防止它们演变为混乱？

让我们看一下敏捷宣言。敏捷的愿望：

1. 尽早连续交付
2. 适应不断变化的需求
3. 经常交付工作软件
4. 开发商和业务利益相关者每天一起工作
5. 围绕有积极性的人建立项目，为他们提供所需的环境和支持，并信任他们完成工作
6. 面对面交谈是主要的交流方式
7. 工作软件是进度的主要衡量标准
8. 可持续发展
9. 持续关注技术卓越和良好的设计
10. 简便性-最大限度地提高您无需做的工作
11. 团队定期检查如何提高效率，然后相应地调整和调整其行为

我强调了最后四个。为什么？因为它们是可以防止项目因自身重量而倒塌的工具。

可持续发展意味着（希望）您有一个监督整个开发过程的人，可以指导飞船超越每次一点软件开发的人，对整个项目有总体愿景的人，有敏锐的知识的人软件体系结构，系统设计，业务逻辑原理和UI人体工程学。换句话说，就是建筑师。

架构师说：“我知道您要这样做，但是如果我们构建其他东西，我们可以避免其他三个令人困惑的功能，而专注于核心需求。” 他是使团队有时间减少技术债务的人。他是为项目带来总体结构和组织的人。他是召集团队聚会的会议的人，问“我们如何做得更好？”

他是维护主需求文档的人。

在“ 掌握需求过程 ”一书中，作者认为有三种客户，三种软件项目：Rabbit，Horses和Elephants。Rabbit是仅需要非正式需求的小型软件项目。您可以直接与客户一起进行小规模的冲刺，合理地限制了项目的范围，并且可以在相对较短的时间内完成软件。大象是那些庞大的项目，需要大量的前期计划，大量的文档和较长的时间。它们可以说不是敏捷的，尽管您可以将它们分解为可以使用敏捷构建的较小项目。

从敏捷的角度来看，马项目有些令人困惑。它们仍然可以迭代构建，您仍然可以使用短距离的sprint，但是如果在需求收集和规划过程中没有任何纪律，则它们很容易脱离轨道。这些项目可以从有条理的需求收集过程中受益，然后随着项目的发展而对这些需求进行仔细的适应和修改，同时仍保持整个项目的总体愿景。

从个人的角度来看，我与大约十二名开发人员组成的小团队一起工作。在任何时候，我们可能同时从事三个软件项目，范围从几千行代码到十万多个代码。我们的客户认为它们是兔子，但实际上是一匹马。客户参与，但不是每天都有。

到目前为止，我们最薄弱的领域是收集特定的，可测试的，可测量的要求，并管理与项目范围相关的客户期望。但是我们正在努力。

这个问题尚不完全清楚，但听起来您似乎在关注需求的可追溯性。根据我的经验，在敏捷中经常会迷失的一个想法是，业务需求是客户希望系统执行的工作，而用户故事实际上是说明系统工作方式的功能需求。“作为用户，我希望能够X。” 但这是为了满足可能会丢失在用户故事中的要求。

根据我的经验，行之有效的是将业务需求和用户案例双向链接。BR＃1可以通过故事A和B来实现。故事C可以覆盖BR＃2和＃3。不管使用什么，都将其放在项目跟踪器，电子表格中。

从长远来看，这有助于将客户的要求（BR）与系统为达到这些要求所做的（故事）联系起来。这应该是相当少的文档，不繁重的维护工作，保持敏捷的思维方式，即不产生任何人都不需要的文档，并且是保持最新状态的琐事。

它还为新项目成员提供了一种加快速度的方法，因为他们需要进行一些检查以了解软件为何执行其操作的历史记录。

我实际上正在一家大型网上商店的看板维护项目中工作，那里不再有原始开发人员。

每个用户故事/需求/错误修正都有一个票证号，每个源代码更改都链接到sourcecontrol-comment字段中的票证号。

sourcecontrol-checkin-s（svn）原子地更新核心响应票证，以便在票证中我具有指向所有sourceconrtol-changesets的链接。

如果新实现了模块/功能，则源代码中也会有票据编号。

在票证系统（redmine）中，票证之间是相互链接的，（（重复，错误，完善……）。

这样您就可以跟踪票证并查看需求随时间的变化。

示例：我必须在“ orderConfirmation-Web-page”中添加一些内容。在页面的源代码中，我看到一条注释：“为“＃4711”创建”，因此我可以将新票证链接到旧票证“ 4711”或它的后继票证之一。

就个人而言，我将用户故事作为系统可以做什么的文档来源而丢弃。除非采取了积极的步骤来创建文档（我们已​​经为一些更传统的客户端完成了这些工作），否则应用程序库确实是最好的文档。

虽然，这并不是什么新鲜事。

如果您使用的是更大比例的Agile版本（例如SAFe），那么您将拥有其他未实现的积压订单。基本上看起来像这样：

1. 投资组合积压（史诗和预算的战略规划）
2. 计划/发行积压（功能和史诗）
3. 项目/团队积压（故事，尖峰，错误）

我不建议在团队积压级别进行文档记录。它太精细了，几乎没有人想讲那么详细的信息。更不用说发行版中可能存在与团队积压的先前故事相矛盾的故事。

相反，我建议您在发行积压级别上工作以提供发行级文档。这些故事一旦分配给特定版本后就很少爆破，并且可以是一种稳定，快速的方式来查看给定版本中正在处理的内容。