语言 Chinese, Simplified

SEO Title

agilemodeling： Agile Requirements Modeling

许多传统项目团队在尝试预先定义所有需求时遇到麻烦，通常是由于误导的想法导致开发人员实际阅读并遵循需求文档包含的内容。现实情况是，需求文档通常是不够的，无论付出多少努力，需求都会发生变化，开发人员最终最终会直接向利益相关者寻求信息（或者只是猜测他们的利益相关者的意思）。敏捷专家知道，如果他们能够预先获得详细的要求，那么他们也可以在他们真正需要信息时也这样做。他们还知道，当需求不可避免地发生变化时，项目早期对详细文档的任何投资都将被浪费。敏捷者选择不在项目早期浪费时间编写详细的需求文档，因为他们知道这是一种非常糟糕的工作方式。

1.坚果壳中的敏捷需求建模

图1描绘了敏捷模型驱动开发（AMDD）生命周期，描述了敏捷软件开发团队如何应用敏捷建模（AM）。我们现在关注的关键方面是初始需求建模，迭代建模，模型风暴和验收测试驱动开发（ATDD）。基本的想法是，您在项目开始时只进行了足够的建模，以便在高层次上了解系统的要求，然后根据实际需要（JIT）收集详细信息。

图1. AMDD生命周期。

1.1初始需求建模

在项目开始时，您需要花费几天时间来设想高级需求并了解发布的范围（您认为系统应该做什么）。您的目标是深入了解项目的内容，而不是详细记录您认为系统应该执行的操作：如果您确实需要，可以在以后提供文档。对于您的初始需求模型，我的经验是您需要某种形式：

使用模式。顾名思义，使用模型可以让您探索用户如何使用您的系统。这可能是统一过程（UP）项目的基本用例集合，功能驱动开发（FDD）项目的功能集合，或极限编程（XP）项目的用户故事集合，或任何以上是一个训练有素的敏捷团队。
初始域模型。域模型标识基本业务实体类型以及之间的关系。域模型可以被描述为类责任合作者（CRC）卡的集合，细长的UML类图，或甚至是细长的数据模型。该域模型将包含足够的信息：主域实体，它们的主要属性以及这些实体之间的关系。您的模型不需要完整，只需要提供足够的信息以使您熟悉主域概念。
用户界面模型。对于用户界面密集型项目，您应该考虑开发一些屏幕草图甚至是用户界面原型。
你真正需要什么程度的细节？我的经验是，你需要的工件只是勉强足以让你理解而不再需要。例如，图2描绘了一个简单的点形式用例。这个用例很可能已经写在索引卡，一张活动挂图纸或白板上。它包含足够的信息，让您了解用例的作用，实际上它可能包含生命周期中这一点的太多信息，因为只有用例的名称可能足以让您的利益相关者理解其基本原理。你是什么意思。另一方面，图3描绘了一个完整记录的正式用例。这是一个记录良好的用例的一个很好的例子，但它比你现在可能需要的更详细。如果你真的需要这个级别的细节，并且在实践中你很少这样做，你可以在实际需要的时候捕获它，然后通过模型进行攻击。如果没有工作软件的具体反馈，项目团队的工作时间越长，您对不能反映利益相关者真正需要的事物进行建模的危险就越大。

编写需求文档的冲动应转变为强烈要求与利益相关者密切合作，然后根据他们告诉您的内容创建工作软件。

图2.一个点状用例。

姓名：参加研讨会
基本行动方针：
- 学生输入她的姓名和学号
- 系统验证学生是否有资格参加研讨会。如果没有资格，则通知学生并结束用例。
- 系统显示可用研讨会的列表。
- 学生选择研讨会或决定不参加。
- 系统验证学生是否有资格参加所选的研讨会。如果没有资格，则要求学生选择另一个。
- 系统验证研讨会是否符合学生的日程安排。
- 系统计算并显示费用
- 学生验证费用，并表明她想要注册。
- 系统将学生注册到研讨会并为其收费。
- 系统打印登记收据。

图3.详细的用例。

姓名：
- 参加研讨会
标识符：
- UC 17
描述：
- 在现有学生参加她有资格参加的研讨会。
前提条件：
- 学生在大学注册。
后置条件：
- 如果学生有资格并且房间可用，学生将参加她想要的课程。

基本行动方针：

用例从学生想要参加研讨会开始。
学生通过UI23安全登录屏幕将她的姓名和学号输入系统。
系统根据业务规则BR129确定注册资格，验证学生是否有资格参加大学的研讨会。 [Alt Course A]
系统显示UI32研讨会选择屏幕，其中显示可用研讨会的列表。
学生指出她想要参加的研讨会。 [Alt Course B：学生决定不参加]
系统根据业务规则BR130确定学生参加研讨会的资格，验证学生是否有资格参加研讨会。 [Alt Course C]
系统根据业务规则BR143验证学生研讨会时间表验证研讨会是否符合学生的现有时间表。
系统根据课程目录中公布的费用，适用的学生费用和适用的税费计算研讨会的费用。应用商业规则BR 180计算学生费用和BR45为研讨会计算税收。
系统通过UI33显示研讨会费用屏幕显示费用。
系统询问学生是否仍想参加研讨会。
学生表示她想参加研讨会。
系统让学生参加研讨会。
系统通过UI88研讨会注册摘要屏幕通知学生注册成功。
根据商业规则BR100 Bill Student for Seminar，系统向学生开账单。
系统询问学生是否需要打印注册声明。
这名学生表示她想要一份印刷声明。
系统打印注册声明UI89注册摘要报告。
当学生接受印刷的陈述时，用例结束。

替代课程A：学生不符合参加研讨会的资格。

A.3。注册商确定学生没有资格参加研讨会。
A.4。注册商通知学生他没有资格注册。
A.5。用例结束。

替代课程B：学生决定不参加可用的研讨会

B.5。学生查看研讨会列表，但没有看到他想参加的研讨会。
B.6。用例结束。

替代课程C：学生没有先决条件

C.6。注册商确定学生没有资格参加他选择的研讨会。
C.7。注册员通知学生他没有先决条件。
C.8。注册员通知学生他需要的先决条件。
C.9。用例在基本操作过程的第4步继续。

1.2迭代建模

迭代建模是在迭代开始时执行的整体迭代计划工作的一部分。您经常需要比最初更详细的层次探索需求，建模得足以规划满足给定需求所需的工作。

1.3模型风暴

引出了详细的要求，或者可能更好的方式来考虑它是在恰当的时间基础上分析高级要求。当开发人员有新的要求来实施时，也许是图2中的“参加研讨会”用例，他们会问自己是否了解要求的内容。在这种情况下，目前尚不清楚利益相关者想要什么，例如我们没有任何迹象表明屏幕应该是什么样子。他们还会问自己这个要求是否小到足以在不到一天或两天内实施，如果没有，那么将其重组为一个较小的部分集合，他们一次解决一个。较小的东西比较大的东西更容易实现。

为了发现需求背后的细节，开发人员（或采用成对编程方法的项目团队的开发人员）请他们的利益相关者解释他们的意思。这通常通过与利益相关者在纸上或白板上绘制草图来完成。这些“模型风暴会议”通常是即兴事件，通常持续5到10分钟（由于需求块很小，因此很少将风暴建模超过30分钟）。人们聚在一起，聚集在一个共享的建模工具（例如白板）周围，探索问题，直到他们满意他们理解它，然后他们继续（经常编码）。极端程序员（XPers）会将需求建模称为风暴会议“客户问答会议”。
在识别屏幕外观的示例中，与您的利益相关者一起绘制想要屏幕的样子，绘制几个示例，直到您对需要构建的内容达成共识。这样的草图是包容性模型，因为您使用的是简单的工具和建模技术，这使敏捷利益相关者参与的敏捷建模（AM）实践成为可能。建模需求的最佳人选是利益相关者，因为他们是领域专家，而不是您。

敏捷建模
有关如何进行需求建模的详细示例，请阅读文章Agile Requirements Modeling Example。

1.4验收测试驱动开发（ATDD）

测试驱动开发（TDD）（Beck 2003; Astels 2003）是一种进化的开发方法，需要大量的学科和技能（以及良好的工具）。第一步是快速添加测试，基本上只有足够的代码才能失败。接下来，您运行测试，通常是完整的测试套件，但为了提高速度，您可能决定只运行一个子集，以确保新测试确实失败。然后，您更新功能代码以使其通过新测试。第四步是再次运行测试。如果它们失败，您需要更新功能代码并重新测试。一旦测试通过，下一步就是重新开始（您可能首先需要根据需要重构设计中的任何重复）。如图4所示，TDD有两个级别：

验收TDD（ATDD）。使用ATDD，您可以根据自己喜欢的术语编写单个验收测试或行为规范，然后使用足够的生产功能/代码来完成该测试。 ATDD的目标是在即时（JIT）的基础上为您的解决方案指定详细的可执行要求。 ATDD也称为行为驱动开发（BDD）。
开发者TDD。使用开发人员TDD，您可以编写单个开发人员测试，有时不准确地称为单元测试，然后只需要足够的生产代码来完成该测试。开发人员TDD的目标是在JIT基础上为您的解决方案指定详细的可执行设计。开发人员TDD通常简称为TDD。

图4. ATDD和开发人员TDD如何组合在一起。

ATDD and TDD

使用ATDD，您不需要采用开发人员TDD方法来实现生产代码，尽管绝大多数执行ATDD的团队也会使用开发人员TDD。如图4所示，当您组合ATDD和开发人员TDD时，单个验收测试的创建反过来要求您通过编写测试，编写生产代码，在开发人员TDD级别获得工作周期来多次迭代。显然，要使TDD工作，您需要拥有一个或多个测试框架。对于接受TDD人们将使用Fitnesse或RSpec等工具，对于开发人员TDD敏捷软件开发人员经常使用xUnit系列开源工具，如JUnit或VBUnit。商业测试工具也是可行的选择。没有这样的工具，TDD几乎是不可能的。

ATDD有几个重要的好处。首先，测试不仅验证您在确认级别的工作，它们也是以实时（JIT）方式编写的可执行规范。通过改变您的测试工作顺序，实现双重任务。其次，从详细要求到测试的可追溯性是自动的，因为验收测试是您的详细要求（如果您需要做这样的事情，则会减少可追溯性维护工作）。第三，这适用于所有类型的需求 - 尽管敏捷社区中关于ATDD的大部分讨论都集中在为用户故事编写测试，但事实是这适用于用例，使用场景，业务规则和许多其他类型需求建模工件。

采用ATDD的最大挑战是现有需求从业者缺乏技能，而另一个原因是推动组织内部的专家通过狭隘专注的专家进行推广。

TDDS规范示例

2.需求来自哪里？

您的项目利益相关者 - 直接或间接用户，经理，高级经理，运营人员，支持（服务台）工作人员，测试人员，开发人员以及与您和维护专业人员集成或互动的其他系统 - 是唯一的官方来源要求（是的，开发人员可以提出SUGGEST要求，但利益相关者需要采纳建议）。事实上，项目利益相关者有责任提供，澄清，指定和确定需求的优先顺序。此外，项目利益相关者有权利开发人员花时间来识别和理解这些需求。这个概念对于您作为敏捷建模者的成功至关重要 - 项目利益相关者的角色是提供需求，开发人员的角色是理解和实施它们。

这是否意味着你坐在昏迷中等待你的项目利益相关者告诉你他们想要什么？不，当然不。您可以提出问题来探索他们已经告诉您的内容，可以说是分析活动，激励他们更详细地说明他们想要什么，甚至可以重新思考和修改他们的原始要求。您可以向他们提出新的要求，关键词是SUGGEST，他们应该考虑并接受（可能有修改）或拒绝作为官方要求。为了确定潜在需求，您还可以在项目利益相关方的帮助下，通过现有文档（如公司政策手册，现有遗留系统或公共资源，如网站上的信息，书籍，杂志文章或产品）进行工作。和竞争对手的服务。再一次，您的项目利益相关者是最终的需求来源，这是他们的决定，而不是您的决定。我不能更加强调这一点。

您的项目利益相关者从哪里获得想法？他们经常会对现有的环境感到烦恼，“我真的希望我们能做到这一点。”，会看到他们的竞争对手可以做的事情，他们不能做，可能想要避免他们过去经历过的问题其他系统，或者可能只是对新功能有一个愿景。一些项目利益相关者，特别是运营人员和高级IT管理人员，可能需要根据需要与现有或即将存在的系统或IT战略激励的需求集成，例如减少组织内的计算平台数量。要点是您的项目利益相关者应该根据广泛的输入来制定需求，您可能希望通过提出问题来确保这些需求。

我经常发现，对于我正在构建的系统中涉及具有相关专业知识的人来说，有很大的价值，以帮助确定我的系统的潜在需求。例如，就电子商务系统而言，我可能希望引进具有国际设计经验，税法专业知识或物流专业知识的人员。当您的组织构建包含其不熟悉的方面的系统时，这种方法尤其有用，也许您的电子商务系统是您首次尝试为国际客户提供服务。我会经常带外部专家一两天，并且有几个项目利益相关者“挑选他们的大脑”来解决由于我们缺乏经验而可能缺少的相关问题。这是确保我们覆盖基地的好方法，特别是在我们确定项目的初始范围时，以及让项目利益相关者超越当前环境时的思考。但是，要认识到这种方法存在危险 - 您的外部专家可能会建议听起来不错但现在实际上并不需要的想法。换句话说，你仍然需要像对待任何其他人一样，通过外部专家的建议。

3.核心实践

有几个“最佳实践”可以帮助您通过需求建模工作变得更加灵活：

利益相关者积极参与
采用包容性模式
采取广度优先的方法
模型风暴细节及时（JIT）
优先考虑静态文档的可执行规范
您的目标是实现需求，而不是记录它们
创建独立于平台的要求
越小越好
问题可追溯性
解释技巧
采用利益相关者术语
保持乐趣
获得管理支持
将利益相关者转变为开
像处理优先级堆栈一样处理需求

4.要求类型

我坚信将需求分为两类：

行为的。行为要求描述了用户如何与系统交互（用户界面问题），某人如何使用系统（使用）或系统如何履行业务功能（业务规则）。这些通常被称为功能要求。
非行为。非行为要求描述了系统的技术特征，其特征通常与可用性，安全性，性能，互操作性，可靠性和可靠性有关。由于IEEE做出错误的命名决定，非行为要求通常被称为“非功能性”要求（据我所知，非功能意味着它不起作用）。

重要的是要理解行为和非行为要求之间的区别是模糊的 - 描述数据访问的预期速度的性能要求本质上是技术性的，但也会反映在影响可用性和潜力的用户界面的响应时间中。用法。访问控制问题，例如允许谁访问特定信息，显然是行为要求，尽管它们通常被认为是属于非行为类别的安全问题。放松一点，不要让自己挂在这样的问题上。如果您对真正关心的要求进行错误分类，关键是识别并理解给定的要求？

5.潜在要求人工品

因为有几种不同类型的需求，其中一些或全部可能适用于您的项目，并且因为每个建模工件都有它的优点和缺点，所以您需要在智能工具包中有几个需求建模工件才能生效。表1总结了建模需求的常见工件，这些工件在文章“敏捷建模工件”中有更详细的描述。指示工件通常用于建模的要求类型以及可用于创建工件的潜在“简单”工具（使用简单工具的重要性在前面的“一些哲学”一节中讨论过）。

表1.建模要求的候选工件。

Artifact	Type	Simple Tool	Description
Acceptance Test	Either	FITNesse	Describes an observable feature of a system which is of interest to one or more project stakeholders.
Business rule definition	Behavioral	Index card	A business rule is an operating principle or policy that your software must satisfy.
Change case	Either	Index card	Change cases are used to describe new potential requirements for a system or modifications to existing requirements.
CRC model	Either, Usually Behavioral	Index cards	A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities. CRC models are used, during requirements modeling, for conceptual modeling which explores domain concepts and high-level relationships between them.
Constraint definition	Either	Index card	A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your project.
Data flow diagram (DFD)	Behavioral	Whiteboard drawing	A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When modeling requirements a DFD can be used to model the context of your system, indicating the major external entities that your system interacts with.
Essential UI prototype	Either	Post It notes and flip chart paper	An essential user interface (UI) prototype is a low-fidelity model, or prototype, of the UI for your system - it represents the general ideas behind the UI but not the exact details.
Essential use case	Behavioral	Paper	A use case is a sequence of actions that provide a measurable value to an actor. An essential use-case is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner.
Feature	Either, Usually Behavioral	Index card	A feature is a "small, useful result in the eyes of the client". A feature is a tiny building block for planning, reporting, and tracking. It's understandable, measurable, and do-able (along with several other features) within a two-week increment (Palmer & Felsing 2002).
Technical requirement	Non-Behavioral	Index card	A technical requirement pertains to a non-functional aspect of your system, such as a performance-related issue, a reliability issue, or technical environment issue.
Usage scenario	Behavioral	Index card	A usage scenario describes a single path of logic through one or more use cases or user stories. A use-case scenario could represent the basic course of action, the happy path, through a single use case, a combination of portions of the happy path replaced by the steps of one or more alternate paths through a single use case, or a path spanning several use cases or user stories.
Use case diagram	Behavioral	Whiteboard sketch	The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When modeling requirements a use case diagram can be used to model the context of your system, indicating the major external entities that your system interacts with.
User story	Either	Index card	A user story is a reminder to have a conversation with your project stakeholders. User stories capture high-level requirements, including behavioral requirements, business rules, constraints, and technical requirements.

需要记住的一件重要事情是，虽然有几个工件可以用于需求收集，但这并不意味着您需要在任何给定项目中使用所有这些工件。您应该了解何时适合使用每个工件，这些知识使您能够遵循练习将正确的工件应用于您手头的情况。

基础过程通常会激发工件选择。在主页上，我指出AM与另一个软件进程结合使用，例如eXtreme Programming（XP）或Unified Process（UP），其范围是整个生命周期。在XP用户故事和UP用例的情况下，基础流程通常更喜欢某些主要需求工件，这是在需求建模时必须考虑的问题。有关详细信息，请参阅文章AM和XP以及AM和UP。

6.引出要求的技巧

表2总结了几种引出需求的技术。每种技术都有权衡，这意味着如果你想要擅长引出需求，你需要学习几种技术，并且每种技术都可以应用于敏捷和非敏捷方式（我建议你尽可能保持敏捷）。

表2.需求启发技术。

Technique	Description	Strength(s)	Weakness(es)	Staying Agile
Active Stakeholder Participation	Extends On-Site Customer to also have stakeholders (customers) actively involved with the modeling of their requirements.	Highly collaborative technique The people with the domain knowledge define the requirements Information is provided to the team in a timely manner Decisions are made in a timely manner	Many stakeholders need to learn modeling skills Stakeholders often aren't available 100% of the time Airs your dirty laundry to stakeholders	It doesn't get more agile than this
Electronic Interviews	You interview a person over the phone, through video conferencing, or via email.	Supports environments with dispersed stakeholders Provides a permanent record of the conversation	Restricted interaction technique Limited information can be conveyed electronically Risky when it is your only means of communication	Ideally used to support other techniques, not as your primary means of elicitation Face-to-face interviews should be preferred over electronic ones
Face-to-Face Interviews	You meet with someone to discuss their requirements. Although interviews are sometimes impromptu events, it is more common to schedule a specific time and place to meet and to provide at least an informal agenda to the interviewee. It is also common to provide a copy of your interview notes to the interviewee, along with some follow up questions, for their review afterward. One danger of interviews is that you'll be told how the person ideally wants to work, not how they actually work. You should temper interviews with actual observation.	Collaborative technique You can elicit a lot of information quickly from a single person People will tell you things privately that they wouldn't publicly	Interviews must be scheduled in advance Interviewing skills are difficult to learn	Be prepared to follow-up Hold the interview at a whiteboard, so that you can sketch as you talk, turning the interview into a model storming session Actively listen to what they're saying
Focus Groups	You invite a group of actual and/or potential end users to review the current system, if one exists, and to brain storm requirements for the new one.	Collaborative technique Significant amounts of information can be gathered quickly Works well with dispersed stakeholders Works well when actual users do not yet exist	Must be planned in advance Lots of unimportant information will be conveyed It's difficult to identify the right people Focus groups can be diverted by a single strong-willed individual	Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk
Joint Application Design (JAD)	A JAD is a facilitated and highly structured meeting that has specific roles of facilitator, participant, scribe, and observer. JADs have defined rules of behavior including when to speak, and typically use a U-shaped table. It is common practice to distribute a well-defined agenda and an information package which everyone is expected to read before a JAD. Official meeting minutes are written and distributed after a JAD, including a list of action items assigned during the JAD that the facilitator is responsible for ensuring are actually performed.	Facilitator can keep the group focused Significant amounts of information can be gathered quickly Works well with dispersed stakeholders	Restricted interaction technique Facilitation requires great skill JADs must be planned in advance	Loosen the rules about when people can talk Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk
Legacy Code Analysis	You work through the code, and sometimes data sources, of an existing application to determine what it does.	Identifies what has been actually implemented	Restricted interaction technique The actual requirements usually differ from what you currently have It can be very difficult to extract requirements from legacy code, even with good tools	Must be tempered with more interactive techniques such as interviews and active stakeholder participation.
Observation	You sit and watch end users do their daily work to see what actually happens in practice, instead of the often idealistic view which they tell you in interviews or JADs. You should take notes and then ask questions after an observation session to discover why the end users were doing what they were doing at the time.	Helps to identify what people actually do Provides significant insight to developers regarding their stakeholder environments	Restricted interaction technique It is hard to merely observe, you also want to interact Seems like a waste of time because you're "just sitting there" Can be difficult to get permission	Observation is best done passively
On-Site Customer	In XP the customer role is filled by one or more people who are readily available to provide domain-related information to the team and to make requirements-related decisions in a timely manner.	Collaborative technique Information is provided to the team in a timely manner Decisions are made in a timely manner	Airs your dirty laundry to stakeholders Stakeholders need to be educated in their role	Get your stakeholders involved with development by evolving towards an active stakeholder participation approach
Reading	There is often a wealth of written information available to you from which you can discern potential requirements or even just to understand your stakeholders better. Internally you may have existing (albeit out of date) system documentation and vision documents written by your project management office (PMO) to justify your project. Externally there may be web sites describing similar systems, perhaps the sites of your competitors, or even text books describing the domain in which you're currently working.	Opportunity to learn the fundamentals of the domain before interacting with stakeholders	Restricted interaction technique Practice usually differs from what is written down There are limits to how much you can read, and comprehend, and a single sitting	Read details in a just-in-time (JIT) manner

7.共同需求建模挑战

为了敏捷地进行需求建模，您需要处于可能成功的情况，对于许多项目团队而言，不幸的是情况并非如此。通常，需求建模工作会受到您的环境的破坏 - 通常会发现组织的文化不利于有效的软件开发工作，或者项目利益相关者不了解其决策的含义。在本节中，我将确定许多开发团队在需求建模和讨论处理这些问题的潜在解决方案时面临的常见问题。这些常见的挑战（按照链接找出如何克服它们）是：

项目利益相关者访问受限
地理上分散的项目利益相关者
项目利益相关者不知道他们想要什么
项目利益相关者改变主意
优先事项冲突
太多的项目利益相关者希望参与
项目利益相关者规定技术解决方
项目利益相关者无法超越当前的情况
项目利益相关者害怕被压制
项目利益相关者不了解建模工件
开发人员不了解问题域
项目利益相关者过分关注一种类型的需求
项目利益相关者需要有关要求的重要手续
开发人员不了解这些要求

8.敏捷需求变更管理

敏捷软件开发团队接受变革，接受需求将在整个项目中发展的想法。敏捷专家了解，因为需求随着时间的推移不断变化，所以任何对详细文档的早期投资都将被浪费掉。相反，敏捷专家会做足够的初始建模，以确定他们的项目范围，并制定高水平的时间表和估计;这就是你在项目早期真正需要的所有内容，所以你应该做的就是这样。在开发过程中，他们将以及时的方式对风暴进行建模，以便在必要的细节中探索每个需求。

由于需求经常变化，因此需要一种简化，灵活的需求变更管理方法。敏捷专家希望开发高质量和高价值的软件，开发高价值软件的最简单方法是首先实现最高优先级的要求。敏捷主义者努力真正地管理变革，而不是阻止变革，使他们能够最大化利益相关者的投资回报率。您的软件开发团队有一堆需要实施的优先级要求 - XPers实际上会在索引卡上编写一堆用户故事。团队从堆栈顶部获取最高优先级要求，他们认为这些要求可以在当前迭代中实现。 Scrum建议您冻结当前迭代的要求，以便为开发人员提供一定程度的稳定性。如果您这样做，那么您当前正在实施的要求的任何更改都应被视为另一个新要求。

图5概述了管理团队可能需要完成的工作项的敏捷方法（您实际上可能没有足够的时间或资源来完成所有项目）。该策略反映了Disciplined Agile Delivery（DAD）流程框架所倡导的风险价值方法。这种工作管理方法是对Scrum方法的产品Backlog方法进行需求管理的扩展。在Scrum处理优先级堆栈等需求的地方，DAD更进一步认识到，您不仅要将要求作为日常工作的一部分，而且还要进行非需求相关的工作，例如参加其他团队的培训和审查工作产品。新的工作项（包括作为用户测试活动的一部分确定的缺陷）由项目利益相关者确定优先级，并在适当的位置添加到堆栈中。您的项目利益相关者有权定义新需求，改变他们对现有需求的看法，甚至可以根据需要重新确定需求的优先级。但是，利益相关者还必须负责及时做出决策和提供信息。

图5.敏捷需求变更管理流程。