问从长远来看，需求管理如何与敏捷项目一起工作？

EN

在我看来，在敏捷项目中，这似乎是一只默默无闻的大象:你如何防止它们演变成混乱呢？

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

1. 早期和持续交付
2. 拥抱不断变化的需求
3. 频繁交付工作软件
4. 开发人员和业务涉众每天一起工作。
5. 围绕有进取心的个人建立项目，给予他们所需的环境和支持，并信任他们完成工作。
6. 面对面交谈是主要的沟通方式
7. 工作软件是衡量进度的主要指标
8. 可持续发展
9. 持续关注卓越的技术和良好的设计。
10. 简单--最大限度地完成你不需要做的工作
11. 每隔一段时间，团队就会思考如何变得更有效，然后相应地调整和调整自己的行为。

我强调了过去的四个。为什么？因为它们能防止项目在自身的重压下崩溃。

可持续发展意味着你(希望)有一个能监督整个开发过程的人，一个能一次控制软件发展的人，一个对整个项目有总体愿景的人，一个对软件体系结构、系统设计、业务逻辑原则和用户界面人机工程学非常了解的人。换句话说，是个建筑师。

架构师是这样说的：“我知道你要求这样做，但是如果我们构建另一个东西，我们可以避免这三个让人困惑的特性，而只关注核心需求。”他是让球队有时间减少技术债务的人。他是给项目带来总体结构和组织的人。他是召集团队开会的人，他问：“我们怎样才能做得更好？”

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

在“掌握需求流程”一书中，作者认为有三种客户，三种软件项目:兔子、马和大象。兔子是只需要非正式需求的小型软件项目；您可以直接与客户进行小冲刺，项目的范围受到合理的限制，软件可以在相对较短的时间内完成。大象是那些需要大量的前期计划、大量的文件记录和很长的时间跨度的大型项目。它们可以说不是敏捷的，尽管您可以将它们分解为可以使用敏捷构建的较小的项目。

从敏捷的角度来看，有些混乱的是马匹项目。它们仍然可以迭代构建，您仍然可以使用短跑，但是在需求收集和规划过程中没有一些规则，它们很容易脱离轨道。这些项目可以从一个有纪律的需求收集过程中受益，然后随着项目的发展对这些需求进行仔细的调整和修改，同时仍然保持对整个项目的总体愿景。

从个人角度来看，我与一个由十几个开发人员组成的小组一起工作。在任何特定的时刻，我们可能同时进行三个软件项目，从几千行代码到10万多行不等。我们的顾客认为他们是一只兔子，但他们真的是一匹马。客户是被雇用的，但不是每天。

到目前为止，我们最薄弱的领域是收集具体的、可测试的、可测量的需求，并管理客户对项目范围的期望。但我们正在努力。

这个问题还不完全清楚，但听起来您似乎关心需求的可追溯性。在我的经验中，在敏捷中容易迷失的一个想法是，业务需求是客户希望系统做的事情，而用户故事实际上是描述系统工作方式的功能需求。“作为一个用户，我希望能够做到X。”但是这样做是为了满足一个可能在用户故事中丢失的需求。

在我的经验中，最有效的方法是将业务需求和用户故事双向链接起来。BR #1可能是通过故事A和B实现的。Story可能涵盖BRs #2和#3。将其放在您的项目跟踪器、电子表格中，不管您使用什么。

长期而言，这有助于将客户的要求(BRs)与系统为实现这些需求所做的(故事)联系起来。这应该是相当小的文档，维护起来并不繁重，符合敏捷的思想，即不生成任何人都不需要的文档，这是一项需要更新的工作。

它还为新的项目成员提供了一种加快速度的方法，因为他们有一些东西要回顾，以了解为什么软件会这么做的原因。

我实际上是在一家大型网络商店的kanban维护项目中工作，在那里，原来的开发人员不再可用。

每个用户故事/需求/补丁都有一个代码号，每个源代码更改都链接到源控制-注释-字段中的ticketnumber。

源控制-签-S (svn)原子更新的核心应答票，以便在票证我有一个链接到所有的源代码转换集。

如果一个模块/函数是新实现的，那么源代码中也有代码。

在票证系统(红地雷)中，票是相互连接的，因为(是重复的，是错误的，是细化的，.)

因此，您可以跟踪票，并看到需求随着时间的变化。

例句:我必须在“orderConfirmation Web-page”中梳理一些东西。在页面的源代码中，我看到一条评论：“为”#4711“创建”，这样我就可以将我的新票证链接到旧的票证"4711“或它的继任者之一。