【摘要】在日趋激烈的电信业竞争态势下，持续而快速地发掘和响应商机成为新的课题。

作为响应机制中的关键环节，需求工程应用敏捷过程方法，以关注商业价值、快速响应、持续迭代的特征来应对变化和难测的未来，是尝试提高组织敏捷能力的核心。

在这其中，作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。

敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。

本文将结合电信业背景及企业实际情况，对敏捷需求分析作出初步的探索。

1、敏捷需求分析：电信行业背景与敏捷过程的需要从中国电信行业ITSP战略推出至今，数年中我们已经看到了明显的变化，作为其信息化体系落地的C TG-MBOSS，也已初具规模和成效。

大规模实施的下一个阶段，将是在商业价值引领下的重构竞争模式、市场细分，以及作为支撑的需求深入研究。

在项目实施过程中，各种挑战和困难纷至沓来，项目管理者不管是做时间、成本、质量的三角平衡，还是人与技术的双向选择，始终无法绕开的一个问题跟源是：如何快速响应环境的变化，使客户在优化的体验过程中满足其商业目标，从而实现企业本身的价值？用失控的过程膨胀来形容近10年的许多软件公司的情形是很合适的。

虽然有很多团队在工作中没有使用过程的方法，但是采用庞大、重型的过程方法的趋势却在快速增长，在大公司中尤为如此。

但现实的发展确与此不相同步，竞争态势造成了更多的不确定性和快速调整的机会。

从近年ERP上线的平均速度来看，项目的交付时间都比较长，这让用户产生了顾虑。

但实际上软件上线仅仅是一个软件生命周期早期的阶段，软件的价值是在使用中体现出来的，其投资回报也只能在后期的运营得到完成。

未来的变化如同纳西姆？塔勒布的黑天鹅一般不可预测且重要，已知和过去琐碎的重复并不足以预测未来的重大影响。

以预测性度量为控制基础的过程模型，只能以经验涵盖一般性事件，所以与此同时，随机应变，保持快速集成和持续改进以应对商业环境的不确定性，延长软件的生命周期提高它的最大价值，从而为获取更多投资回报提供保障，也成为软件工程发展的必然。

敏捷过程（Agile Process）的主要优势是能够适应系统需求的不确定性，将客户作为需求团队中密不可分的成员，而在实现过程中尽量在最短时间内实现对用户来说业务价值最大的需求；同时，敏捷开发（A gile Development）是一种面临迅速变化的需求快速开发软件的能力，它帮助处理了未来不确定性的问题；但是对于过去，应该没有不确定的事。

而敏捷需求分析，是面对迅速变化的商业状况，提高其响应和组织成可理解和接受的需求说明并对敏捷开发作出能力保证的方法论。

2、敏捷与过程改进和度量模型从软件工程发展起，过程改进在全球日益得到重视，ISO 9000/SW-CMM/CMMI各级的评估也在业界得以推展，这种氛围下，以RUP等为代表的过程模型也得到了广泛的应用。

但与此同时，敏捷的论调却异军突起，方兴未艾。

软件过程的多样性，源于过程环境和层次的不同；而过程选择的多样性和CMMI目标的通用性决定了过程改进途径的多样化。

运用一系列重方法，将在应对商机方面造成挑战；尤其是在企业的管理考核和过程模板仍更多的是一种瀑布式体系下，软件的实现过程将在不同模型下摇摆却显得不那么灵活。

一个合适的生命周期模型选择是重要的，由于惯性的教育，瀑布在我们的工作环境中随处可见。

但如果不去分析CMMI等的实质，将无助于改进这一点而提高响应。

强调结构化方法与重型的管理策略，往往在内心中拒绝变更，把变更作为被管理甚至被“管制”的对象；而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。

这是一种理论上的理想状态，尽管我们可以采取诸如CMMI的一些理念及过程改进模板对其管理，但实际上往往会出现与用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，最终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。

但实质上，重型、轻型过程方法论之间并不存在根本性的矛盾冲突，这体现于它们最终理念和出发点的一致。

把这些互补方法论拼在一起，“恰好可以发现整个软件过程体系全貌的一部分”。

CMM/CMMI 中不包括更为具体一点的如何写好需求，如何做好设计，如何写好测试等许多方面的软件工程技术、技能方面的指导，而这些恰好是敏捷的强项。

敏捷方法整合了一套轻量的管理、过程和工程技术方法，这是它作为一种先进方法体系补充于CMMI 的地方。

敏捷过程并不像业界所传的那样只适合小项目和新项目的研发，实际上它对于各种类型，包括企业所定义的A类、B类、C类在CMMI体系基础上都是可取舍适用的。

这需要过程体系间的适当裁剪和调整组合。

敏捷需求分析，将在全过程中扮演衔接、沟通和渗透的作用。

3、敏捷需求分析的过程特性IEEE对需求的定义是用户解决问题或达到目标所需的条件或性能；系统或系统部件要满足合同、标准或其他正式规定文档的条件或性能。

需求是设计、构造产品的前提，简单地说，是必须完成的事及其所必须具备的品质。

需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为提交的产品的一部分[5]。

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

业务需求（bu siness requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。

功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

图1. 需求的层次及组成我们可以看到，不管是传统的还是敏捷的需求开发阶段，需求的层级及组成，其基本特性是一致的，这反映方法的差异并不改变需求的本身属性。

一般的需求三个层次，忽略了一个问题，即每个层次所需的知识、技能、经验、背景等是不同的，不同的层次过程中，需要不同资源的整合。

业界相关的论述中，只是给出了笼统的需求分析人员的统一角色，但并未对其作出区别。

实际上，这很难映射到中小企业的现实操作层面。

这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？3.1 需求的参与者敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。

在《敏捷宣言》（Manife sto for Agile Software Development）中，强调了客户一起现场工作的重要性。

而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。

但应该清楚，这种纳入并不能真正代替真实的客户参与。

对于客户无法全程现场参与的情况，BA的出现是一种弥补。

BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。

同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptancetest）。

而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。

当然，这项工作可以分解为另外的角色来进行。

开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。

一个完整描述的用例可以很方便地导出测例（test case）。

而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。

我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为Acceptance Driven Development。

从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。

各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。

对于角色及其参与方式，我们可以比较如下：表1：需求的主要参与者（其他的stakeholders并未全部列出，比如PM、QA等）这些参与者如何工作的呢？我们引入到需求分析的工作形式。

3.2 敏捷需求分析工作形式敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。

比如，敏捷联盟所推荐的现场客户工作。

但多数情况下，客户都是很忙碌的，很难全力投入到过程中。

这时候，我们就需要BA这个角色，来充当客户的角色。

BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。

而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。

敏捷思想的核心是人与人的交流。

聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。

在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。

对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。

在某省电信运营商的项目中，我们已经发现了这一点。

用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。

在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。

迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。

这些将在下文中讨论。

迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。

包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。

3.3 需求分析时机传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。