敏捷者希望开发高质量和高价值的软件，而开发高价值软件最简单的方法就是首先实现最高优先级的需求。这使他们能够最大化涉众的ROI。因为需求经常变化，您需要一个精简的、灵活的方法来进行需求变更管理:简而言之，敏捷者努力真正地管理变更，而不是阻止变更。这一做法有三个版本:
- 产品待办事项列表(Scrum)
- 工作项目列表(有纪律的敏捷)
- 选择池(精益)
1. 产品待办事项列表:简单
图1概述了Scrum管理需求的方法，其中您的软件开发团队有一堆需要处理的优先级和估计需求(Scrum将这个优先级堆栈称为“产品backlog”)。有几个要点需要理解:
- 新需求由项目涉众确定优先级，并添加到堆栈的适当位置。
- 从根本上说，当涉及到需求优先级时，一个人需要成为最终的权威。在Scrum和纪律严明的敏捷交付(DAD)中，这个角色来自Scrum，这个人被称为产品负责人。
- 尽管经常有许多项目涉众，包括最终用户、经理、架构师、运营人员，但仅举几个例子，产品所有者负责代表他们所有人。
- 堆栈/待办事项列表最初是由您在项目开始时设想的需求所填充的(在Scrum中，他们称之为“填充待办事项列表”)。
- 每次迭代(Scrum术语中的“sprint”)，您的团队都将迭代的工作价值从栈顶提取出来，并承诺在迭代结束时实现它。
- 您的项目涉众有权定义新的需求，改变他们对现有需求的想法，甚至根据他们认为合适的情况重新排列需求的优先级。
- 利益相关者负责及时做出决策并提供信息。在一些项目中，业务分析师(通常扮演产品负责人的角色)可能会承担此职责。无论谁担任这个角色，都需要与其他利益相关者合作，确保每个人都得到公平的代表，这通常是一项艰巨的任务。
- 非需求工作项目的优先级要么由团队与涉众协商，要么作为计划中空闲时间的一部分处理。许多Scrum团队现在不仅仅把需求(比如缺陷)放在他们的backlog上。
图1所示。Scrum需求管理。
2. 工作项目列表:有纪律的敏捷
图1中描述的方法非常简单，反映了我认为敏捷构建级别的思想。图2概述了一种更规范的方法，它扩展了上面描述的管理工作项的方法。这种方法是有纪律的敏捷交付(DAD)所建议的默认方法，两者都反映了敏捷交付团队所面临的现实世界。你应该考虑以下几个有趣的改进:
超越功能需求。我们知道我们做的不仅仅是在每次迭代中实现新的需求，我们经常做与需求无关的工作，比如接受培训，检查其他团队的产品，处理缺陷(我认为缺陷只是另一种类型的需求)等等。重点是，不仅仅需要将需求放在堆栈上，我们还需要工作项。
- 采用风险价值方法。纪律严明的敏捷团队认识到开发团队面临着一些共同的风险，他们希望尽快解决这些风险。这些风险包括在项目早期达成涉众一致意见的需要，可以通过需求设想，或者开发一个共享的远景或者项目章程来解决这个风险。另一个常见的风险是需要证明您的体系结构策略(通过体系结构设想标识)确实有效。最有效的方法是通过为您的系统构建一个端到端框架(或钢框架)来使用工作代码证明您的体系结构，该框架解决了您的团队所面临的主要技术风险。有纪律的敏捷交付(DAD)团队将在项目的早期查看他们的工作项堆栈，通常是在项目的初始阶段/“迭代0”/“sprint 0”部分，以确定哪些需求展示了这些技术上有风险的特性。如果这些要求没有堆栈的顶部,他们常常因为风险和回报(值)倾向于使相互,然后他们用产品所有者讨论这个问题,看看他们能激励人(负责优先级)将这些需求转移到堆栈的顶部。如果一个高风险的需求目前接近于栈底，那么您应该质疑这个需求是否真的是需要的，因为很有可能您永远不会真正抽出时间来处理它，因为优先级更高的工作总是会成为先例。
- 提前一点建模。因为我们知道所有的需求，更不用说一般的工作项，都不是平等创建的，所以我们不应该天真地假设我们应该在迭代开始的时候等待从堆栈顶部取出迭代的工作值。如果一个工作项非常复杂，需要比迭代计划会话中通常发生的更多的思考，该怎么办?纪律严明的敏捷团队将采用前瞻性建模实践，对工作项堆栈进行一两次迭代，并投入时间研究即将到来的复杂工作项，以降低总体项目风险。提前建模在Scrum中称为backlog梳理，揭示了Scrum实践中一些不必要的概念耦合。
图2。有纪律的敏捷工作管理流程。
3.选择池:精益
图3描述了一种在看板团队中常见的需求管理精益方法。需求/工作管理的敏捷方法和精益方法之间有几个关键的区别:
- 选项。工作项被视为解决方案中要处理的潜在选项，而不是必需的工作项。顺便提一下，IT中的术语“需求”一直以来都是有问题的(如果某个东西是一个需求，那么如何将它的一部分或全部从您的交付范围中删除呢?)
- 选项被管理为一个池。敏捷团队将工作项管理为优先级队列，精益团队将选项管理为一个池，当他们有能力执行相应的工作时，他们将从这个池中与涉众一起选择最有价值的工作。实际上，优先级是在团队涉众的准时(JIT)基础上完成的。这可能很复杂，因为单个涉众将有不同的优先级，因此需要进行权衡，而且团队可能支持不同的服务类别。当然，纪律严明的敏捷策略所描述的风险缓解问题也应该考虑接下来选择哪个选项。
- 选项可能被组织到服务类中。并不是所有的选项都是相同的。在《看板》一书中，David J. Anderson描述了您的团队可能考虑的几种潜在的选项类别(Anderson将其称为服务类)。许多工作项属于“标准”类，它们的优先级主要基于它们对组织的业务价值。有些工作项目有固定的交付日期，这对于政府立法或与外部客户签订的合同所产生的需求来说是很常见的。您还可能有少量(希望如此)的加急工作项，比如针对生产问题的关键修复或高优先级的客户需求。最后，你可能有一些低优先级的“无形”工作项目，你知道在将来的某个时候你需要处理它们，你决定在团队认为合适的时候处理它们(也许是为了简化其他工作，从更具挑战性的工作中休息一下，……)。需要注意的是，这里描述的类别并不是一成不变的，您的团队可能会识别出不同的类别，或者根本不需要进行分类。此外，在上面描述的敏捷策略中，服务类可以被支持为多个队列。
- 目标是限制正在进行的工作(WIP)。当敏捷团队努力选择一个固定数量的功能，刚好足够他们在一次迭代中实现时，精益团队选择产生一个连续的功能流，当他们有能力这样做时，将工作拉入他们的“交付系统”。限制WIP可以提高团队的交付可预测性，提高质量(由于反馈周期较短)，并提高生产力。
- 淘汰旧的工作项。精益团队通常会努力确定老化规则,如果一个工作项池中超过一定的时间,从池中移除的假设下,如果它已经很长时间没有重要到可以选择从池中就可能永远不会。如果工作项确实被证明是需要的，那么它总是可以在将来的某个日期添加到池中。请注意，老化规则在不同的团队之间会有所不同，一个团队可能需要3个月，而另一个团队可能需要5个月。此外，此策略可以应用于前面描述的产品backlog或工作项列表方法。
图3。精益工作管理流程。
利益相关者可以通过以下几种方式添加选项:
- 当团队最初形成时，通过需求想象会话。
- 以利益相关者认为的即兴方式。
- 当选项池接近空时，通过有目的的建模会话。
- 通过使用现有的生产系统来识别增强请求或缺陷报告。
4. 哪种策略适合你?
没有一种策略在所有情况下都是最好的，你需要确定并选择最适合你的策略。表1比较了这些策略。
表1。比较的策略。
原文：http://agilemodeling.com/essays/prioritizedRequirements.htm
本文：https://pub.intelligentx.net/node/709
