敏捷过程中的软件需求分析(2)

这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？
3.1需求的参与者
敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中[3]，强调了客户一起现场工作的重要性。而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。
对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。
开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。
对于角色及其参与方式，我们可以比较如下：

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

表1：需求的主要参与者
（其他的stakeholders并未全部列出，比如PM、QA等）
这些参与者如何工作的呢？我们引入到需求分析的工作形式。
3.2敏捷需求分析工作形式
敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。比如，敏捷联盟所推荐的现场客户工作。但多数情况下，客户都是很忙碌的，很难全力投入到过程中。这时候，我们就需要BA这个角色，来充当客户的角色。
BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。
敏捷思想的核心是人与人的交流。聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。在某省电信运营商的项目中，我们已经发现了这一点。用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。
迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。这些将在下文中讨论。迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。
3.3需求分析时机
传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。
敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。

原文转自：http://www.ltesting.net