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

3.2敏捷需求分析工作形式

敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。比如，敏捷联盟所推荐的现场客户工作。但多数情况下，客户都是很忙碌的，很难全力投入到过程中。这时候，我们需要BA这个角色，来充当客户的角色。

BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。

敏捷思想的核心是人与人的交流。聚议是一种面对面的好形式，它能促成问题从多个角度的现场核清。在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。对于需求分析中所用的各种形式，用户其实并不排斥参与??尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。在某省电信运营商的项目中，我们已经发现了这一点。用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。

迭代是敏捷显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。这些将在下文中讨论。迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。

3.3需求分析时机

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

敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。

3.4需求的划分

开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放??这种情况是多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。

敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）[7]”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。

3.5敏捷需求分析与细化过程

迭代是敏捷需求分析与细化过程中显著的方式。迭代的特征包含如前文所述的两部分：全生命过程、小粒度的以业务价值为基础的划分。Robert C. Martin认为每一次迭代都是一个完整的项目产品[3]，换言之，迭代是要产生终产品的反复[4]，也是说你的一次一次的反复必须都能产生终的产品，而不是中间的半成品。这也反映了需求划分的原则，以及每一次小的迭代，其结果都是可确认的。因此，迭代过程中重要的一种方法是分解，以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接，那么它应该被分解和延后，而不是草草地做一个似是而非的大方案而囊括之。

迭代是一种快速反应和逐步确认成果的方式。敏捷意味着快速反应、注重核心价值， 但并不是要求每件事都尽快地完成和提交。迭代计划的依据便是优先级的确定。因此，迭代的实施要求正确引导客户划分优先级，实施逐步的集成改进。必要时，项目上线也是可以逐步推行的，因为仅仅上线并不意味着价值的实现。

传统的需求分析总是希望能一定完成所有的事情以便于直接作出功能划分和设计，但这在我们以往经历的项目实践中遇到了挑战，不得不把项目的需求分析肢解成似乎是多个不同项目的需求集合。敏捷而持续的过程，对此作出修正。

3.6文档与变更

正如Martin对那种什么文档也不写自称为敏捷的善意批评[3]，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。

传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。

敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” [3]，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。

3.7敏捷需求分析小结

综合以上的陈述，对敏捷需求分析归纳如下表（角色职责的变化也是一种重要的对比，请参见表1，此处不赘言）：