【摘要】 在日趋激烈的电信业竞争态势下，持续而快速地发掘和响应商机成为新的课题。作为响应机制中的关键环节，需求工程应用敏捷过程方法，以关注商业价值、快速响应、持续迭代的特征来应对变化和难测的未来，是尝试提高组织敏捷能力的核心。在这其中，作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。本文将结合电信业背景及企业实际情况，对敏捷需求分析作出初步的探索。
1、敏捷需求分析：电信行业背景与敏捷过程的需要
从中国电信行业ITSP战略推出至今，数年中我们已经看到了明显的变化，作为其信息化体系落地的CTG-MBOSS，也已初具规模和成效。大规模实施的下一个阶段，将是在商业价值引领下的重构竞争模式、市场细分，以及作为支撑的需求深入研究。在项目实施过程中，各种挑战和困难纷至沓来，项目管理者不管是做时间、成本、质量的三角平衡，还是人与技术的双向选择，始终无法绕开的一个问题跟源是：如何快速响应环境的变化，使客户在优化的体验过程中满足其商业目标，从而实现企业本身的价值？
用失控的过程膨胀来形容近10年的许多软件公司的情形是很合适的。虽然有很多团队在工作中没有使用过程的方法，但是采用庞大、重型的过程方法的趋势却在快速增长，在大公司中尤为如此。但现实的发展确与此不相同步，竞争态势造成了更多的不确定性和快速调整的机会。从近年ERP上线的平均速度来看，项目的交付时间都比较长，这让用户产生了顾虑。但实际上软件上线仅仅是一个软件生命周期早期的阶段，软件的价值是在使用中体现出来的，其投资回报也只能在后期的运营得到完成。未来的变化如同纳西姆？塔勒布的黑天鹅一般不可预测且重要，已知和过去琐碎的重复并不足以预测未来的重大影响。以预测性度量为控制基础的过程模型，只能以经验涵盖一般性事件，所以与此同时，随机应变，保持快速集成和持续改进以应对商业环境的不确定性，延长软件的生命周期提高它的最大价值，从而为获取更多投资回报提供保障，也成为软件工程发展的必然。
敏捷过程（Agile Process）的主要优势是能够适应系统需求的不确定性，将客户作为需求团队中密不可分的成员，而在实现过程中尽量在最短时间内实现对用户来说业务价值最大的需求；同时，敏捷开发（Agile Development）是一种面临迅速变化的需求快速开发软件的能力，它帮助处理了未来不确定性的问题；但是对于过去，应该没有不确定的事。而敏捷需求分析，是面对迅速变化的商业状况，提高其响应和组织成可理解和接受的需求说明并对敏捷开发作出能力保证的方法论。
2、敏捷与过程改进和度量模型
从软件工程发展起，过程改进在全球日益得到重视，ISO 9000/SW-CMM/CMMI各级的评估也在业界得以推展，这种氛围下，以RUP等为代表的过程模型也得到了广泛的应用。但与此同时，敏捷的论调却异军突起，方兴未艾。软件过程的多样性，源于过程环境和层次的不同；而过程选择的多样性和CMMI目标的通用性决定了过程改进途径的多样化。
运用一系列重方法，将在应对商机方面造成挑战；尤其是在企业的管理考核和过程模板仍更多的是一种瀑布式体系下，软件的实现过程将在不同模型下摇摆却显得不那么灵活。一个合适的生命周期模型选择是重要的，由于惯性的教育，瀑布在我们的工作环境中随处可见。但如果不去分析CMMI等的实质，将无助于改进这一点而提高响应。
强调结构化方法与重型的管理策略，往往在内心中拒绝变更，把变更作为被管理甚至被“管制”的对象；而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。这是一种理论上的理想状态，尽管我们可以采取诸如CMMI的一些理念及过程改进模板对其管理，但实际上往往会出现与用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，最终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。
但实质上，重型、轻型过程方法论之间并不存在根本性的矛盾冲突，这体现于它们最终理念和出发点的一致。把这些互补方法论拼在一起，“恰好可以发现整个软件过程体系全貌的一部分”。CMM/CMMI 中不包括更为具体一点的如何写好需求，如何做好设计，如何写好测试等许多方面的软件工程技术、技能方面的指导，而这些恰好是敏捷的强项。敏捷方法整合了一套轻量的管理、过程和工程技术方法，这是它作为一种先进方法体系补充于CMMI 的地方。敏捷过程并不像业界所传的那样只适合小项目和新项目的研发，实际上它对于各种类型，包括企业所定义的A类、B类、C类在CMMI体系基础上都是可取舍适用的。这需要过程体系间的适当裁剪和调整组合。敏捷需求分析，将在全过程中扮演衔接、沟通和渗透的作用。
3、敏捷需求分析的过程特性
IEEE对需求的定义是用户解决问题或达到目标所需的条件或性能；系统或系统部件要满足合同、标准或其他正式规定文档的条件或性能。 需求是设计、构造产品的前提，简单地说，是必须完成的事及其所必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为提交的产品的一部分[5]。
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
图1. 需求的层次及组成
我们可以看到，不管是传统的还是敏捷的需求开发阶段，需求的层级及组成，其基本特性是一致的，这反映方法的差异并不改变需求的本身属性。一般的需求三个层次，忽略了一个问题，即每个层次所需的知识、技能、经验、背景等是不同的，不同的层次过程中，需要不同资源的整合。业界相关的论述中，只是给出了笼统的需求分析人员的统一角色，但并未对其作出区别。实际上，这很难映射到中小企业的现实操作层面。
这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？
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：需求的主要参与者
（其他的stakeholders并未全部列出，比如PM、QA等）
这些参与者如何工作的呢？我们引入到需求分析的工作形式。
3.2 敏捷需求分析工作形式
敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。比如，敏捷联盟所推荐的现场客户工作。但多数情况下，客户都是很忙碌的，很难全力投入到过程中。这时候，我们就需要BA这个角色，来充当客户的角色。
BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。
敏捷思想的核心是人与人的交流。聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。在某省电信运营商的项目中，我们已经发现了这一点。用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。
迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。这些将在下文中讨论。迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。
3.3 需求分析时机
传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。
敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。
3.4 需求的划分
开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放——这种情况是最多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。
敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。
3.5 敏捷需求分析与细化过程
迭代是敏捷需求分析与细化过程中最显著的方式。迭代的特征包含如前文所述的两部分：全生命过程、小粒度的以业务价值为基础的划分。Robert C. Martin认为每一次迭代都是一个完整的项目产品[3]，换言之，迭代是要产生最终产品的反复[4]，也就是说你的一次一次的反复必须都能产生最终的产品，而不是中间的半成品。这也反映了需求划分的原则，以及每一次小的迭代，其结果都是可确认的。因此，迭代过程中重要的一种方法是分解，以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接，那么它应该被分解和延后，而不是草草地做一个似是而非的大方案而囊括之。
迭代是一种快速反应和逐步确认成果的方式。敏捷意味着快速反应、注重核心价值， 但并不是要求每件事都尽快地完成和提交。迭代计划的依据便是优先级的确定。因此，迭代的实施要求正确引导客户划分优先级，实施逐步的集成改进。必要时，项目上线也是可以逐步推行的，因为仅仅上线并不意味着价值的实现。
传统的需求分析总是希望能一定完成所有的事情以便于直接作出功能划分和设计，但这在我们以往经历的项目实践中遇到了挑战，不得不把项目的需求分析肢解成似乎是多个不同项目的需求集合。敏捷而持续的过程，对此作出修正。
3.6 文档与变更
正如Martin对那种什么文档也不写就自称为敏捷的善意批评，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，就不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。
传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。
敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” ，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。
3.7 敏捷需求分析小结
综合以上的陈述，对敏捷需求分析归纳如下表（角色职责的变化也是一种重要的对比，请参见表1，此处不赘言）：
| 角度 | 传统需求分析 | 敏捷需求分析 |
| 需求分析时机 | 更多地集中在项目早期 | 近乎均匀地贯穿于项目的整个生命周期 |
| 需求划分单位 | 基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大 | 基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；用户故事是小粒度的，可测试的，可见的，并且是有价值 |
| 需求细化过程 | 一步到位，可供开发人员设计开发 | 逐步细化，仅就下一个迭代需要实现的部分进行详细分析 |
| 需求文档要求 | 正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪），很多产出物最终难以被阅读。 | 非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求。（对于组织过程资产管理要求，可以在此基础上形成可阅读可理解的轻型文档）。 |
| 需求文档同步 | 项目中后期一般都处于不同步状态 | 即时的同步 |
| 需求传递过程 | 单向的陈述与记录，文档传导（线性的传递，误导放大，缓慢） | 聚议，共同参与，业务场景与用户故事，及时的非正式沟通 |
| 应对需求变更 | 有严格的控制流程，视变更为风险 | 视变更为必然或预期中的事情 |
表2：敏捷需求分析的特征对比
4、应用敏捷需求分析的质量保证
一个传统的软件实现过程，遵循计划与严格的控制来保证质量。管理手段的控制有时不能及时纠正工程领域的偏差，即使控制体系给了更多的回馈机制，实质上更多地只是增加了信息层级和复杂度。
一个典型的缺陷放大过程如下图所示：
图2：软件实现各阶段的缺陷放大
敏捷需求分析参与生命周期的迭代，而每一次迭代都是一个完整的过程，并产生项目交付品，而在下一个迭代之前，其交付品都是可用的。这种方法能有效地及时调整，从源头消除可能被放大的缺陷。
敏捷过程中，需要BA、QA的全程参与（当然，在企业实践中，可能存在着职能划分的现状。从更有效的角度看，由于项目经理参与了项目全生命周期，尤其是对需求管理的全过程的跟踪，项目经理担任某一项目的BA角色，也是现实可行的，其优点是可以保证有及时的客户沟通、长期而细致的跟踪），保证需求能始终被正确地理解、传递和验证。从敏捷需求出发导出的场景拟合验收测试，能从更广阔的层级（业务价值视角）来验证需求的达成性而不仅仅是软件的可用性等指标。这对质量保证是一个提高。迭代演进中应对需求变更，是从客户视野上的更高的质量改进。
5、总论
敏捷过程是一种结合管理理念与工程方法的最佳实践，它关注人的价值，倡导客户合作与响应变化，是中小企业持续过程改进的最有效途径之一。敏捷过程意味着全过程的敏捷，而不仅仅只是片面理解诸如XP、Scrum等方法而局限于开发环节。这其中，敏捷需求分析构成了方法体系的重要因素，它以沟通、迭代、响应变化、独立业务价值导出的可见的用例等特征，贯穿于产品全生命周期。
在电信业竞争态势与管理细化背景下，将出现需求迭出但保持持续演进的特征。应用敏捷过程方法论，结合CMMI体系的适度裁剪与敏捷化，化变化为商机，关注商业价值，是应对挑战的有效方法。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
