3.1 需求的参与者

　　敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中，强调了客户一起现场工作的重要性。而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA??如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。

　　对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA重要的职责是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。

　　开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。从整个过程来说，分析和实现的过程是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，可以全能地做出需求定义。

　　对于角色及其参与方式，我们可以比较如下：

角色及职责
传统的需求参与
敏捷的需求参与
用户/客户
需求的提供者
需求演进的参与者
用户的主要参与方式
陈述
遵循游戏规则的积极的交互参与
BA
需求的定义者
需求的组织者
BA的主要参与方式
前期的调查获取和整理成文档
参与全周期的迭代与演进
开发
需求的接受者和实现者
场景拟合者与改进者
开发的主要参与方式
被传导需求并使之功能化
完成完整的业务场景实现
测试
功能测试者
场景测试者（需求测试者）
测试的主要参与方式
找出软件的显性的bug
找出不满足需求逻辑和不能拟合场景的缺陷

表1：需求的主要参与者

　　这些参与者如何工作的呢？我们引入到需求分析的工作形式。