该帖子同步发自：(铁托的博客  访问该博客)

　　随着敏捷运动势头日益增长，运用敏捷方法所管理的项目日益多产，项目专业人士必须更为纯熟地运用敏捷方法。尽管敏捷的技术、流程与瀑布式有所不同，许多创新项目团队正开始将非敏捷技术融入到敏捷环境中，并取得了巨大成功。

　　最佳管理智囊档案

　　人们对于敏捷存在一个普遍的误解，以为在敏捷中运用用户故事之后就不需要用例。围绕这一话题，人们在Skillsharks、博客、Twitter、Facebook等各大社交网络纷纷提出疑问。我们不应该简单地问“用户故事可以取代用例吗?”而应当将问题置于下述框架中进行探讨：“开发有效的敏捷需求时，我们如何在用户故事中有效发挥用例的作用?”

　　因为用例与瀑布式方法中的捕获和分析法类似，很多人在敏捷方法中避免使用它。但是，无论我们如何着手进行需求分析，最终目标都是相同的，即帮助商业用户或利益相关者确定他们的真正需要，并将之转化为需求。要想成功开发敏捷需求，必须同时有效运用二者，抓住最佳业务方案的核心，为客户带来价值。

　　根据《BABOK. 指南》第6章，“…商业分析师对利益相关者、解决方案需求进行优先排序和逐步细化，使项目团队得以落实解决方案，满足发起组织和利益相关者的需要。这就要求对利益相关者的需要进行分析，定能够满足这些需要的解决方案，并通过评估业务的当前状态，确定与建议改进事项，开展对所获需求的核实与验证工作。”为了圆满完成任务，商业分析师需要具备过硬的引导、信息捕获以及流程设计技巧，这些是编写有效用例的核心要素。

　　在敏捷开发中，需求是逐步细化的。每一个迭代或Sprint均允许商业用户或利益关者更好地阐述他们的需要，确保高效开发解决方案。商业用户或利益相关者“讲述”集成用户关注与直接交互特性的用户故事，奠定每一个迭代或Sprint的基础。这些简短的用户期望脚本仅是编写用户故事过程中的一部分。用户故事还包括另外两个要素：

　　1. 笔记：为帮助阐明期望而就相关故事进行深入讨论所做的记录(交谈)

　　2. 故事意图和验证测试：向用户确认故事交付后确实满足其期望(确认)

　　需求远景是敏捷开发中运用用例的关键

　　敏捷团队在开始收集描述系统特性的详细需求之前，确定项目的总体远景和目的至关重要，其中也包括产品远景。产品远景是项目的边界，迭代增量工作即在此范围内开展。产品远景应回答下列三个问题：

　　1. 该产品是什么?

　　2. 该产品为什么有用?

　　3. 该产品将有什么特性来吸引客户?

　　我们可以首先在此处看到运用用例建模的捕获技巧，对于收集并整合用户故事的强大作用。图1向我们生动地展示了用例在此过程中是如何被有效运用的。

　　创建解决方案时，从需求的角度来设定产品远景至关重要。这样既可以设定参数，确保我们交付的产品满足需求，在涉及跟踪需求时亦能标记 终点。

　　在敏捷开发中为何，何时使用用例?

　　用例是展示参与者及其目标的图表。参与者通常是人或系统，而目标就是参与者所希望实现的。敏捷开发中的用例用以帮助明确“谁”要用系统做“什 么”，并确定交互的商业价值。

　　在敏捷项目中，不仅要从项目的角度而且要从产品的角度，充分发挥用例的作用。从项目角度来看，用例可用直观易懂的方式展示“谁需要什么”。 从产品远景的角度来看，无论是开始进行用户驱动型系统的需求预想，亦或是确定主题和特性，使用用例都大有裨益。

　　敏捷开发中有四个层次的需求。主题用以描述可能包含多个特性的较大需求，特性则是一系列相关故事。这两个需求层次提供了一个使用用例的良机，因为它们能够提供简单直观的产品范围，且同时允许改进需求优先级。另外两个需求层次更加详细，分别是史诗和故事。史诗用以描述因太大而不能在一个迭代或Sprint中完成的故事，这些故事需要分解成更小的故事。用户故事是最小的且有价值的业务需求，此类故事遵循INVEST原则。

　　有效的敏捷需求非常倚重用例和用户故事。请谨记，用户故事侧重于用户期望在使用最终产品时能够具备的特性。它们旨在表示用户期望的简短场景，帮助敏捷团队的商业分析师在更深层面上将这些期望与适当的解决方案价值联系起来。用例则用以帮助开展用户价值分析，进而对产品backlog进行优先排序。

　　用例和用户故事的精确使用时间无定法可循。对产品backlog进行优先排序时，二者都需要用到。更好地了解客户的需要及其重视之处，也离不开二者。敏捷项目需要运用用例和用户故事，但是，何时运用它们取决于团队开展的敏捷项目类型。