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

3.4需求的划分
开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放——这种情况是最多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。
敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）[7]”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。
3.5敏捷需求分析与细化过程
迭代是敏捷需求分析与细化过程中最显著的方式。迭代的特征包含如前文所述的两部分：全生命过程、小粒度的以业务价值为基础的划分。Robert C. Martin认为每一次迭代都是一个完整的项目产品[3]，换言之，迭代是要产生最终产品的反复[4]，也就是说你的一次一次的反复必须都能产生最终的产品，而不是中间的半成品。这也反映了需求划分的原则，以及每一次小的迭代，其结果都是可确认的。因此，迭代过程中重要的一种方法是分解，以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接，那么它应该被分解和延后，而不是草草地做一个似是而非的大方案而囊括之。
迭代是一种快速反应和逐步确认成果的方式。敏捷意味着快速反应、注重核心价值， 但并不是要求每件事都尽快地完成和提交。迭代计划的依据便是优先级的确定。因此，迭代的实施要求正确引导客户划分优先级，实施逐步的集成改进。必要时，项目上线也是可以逐步推行的，因为仅仅上线并不意味着价值的实现。
传统的需求分析总是希望能一定完成所有的事情以便于直接作出功能划分和设计，但这在我们以往经历的项目实践中遇到了挑战，不得不把项目的需求分析肢解成似乎是多个不同项目的需求集合。敏捷而持续的过程，对此作出修正。
3.6文档与变更
正如Martin对那种什么文档也不写就自称为敏捷的善意批评[3]，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，就不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。
传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。
敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” [3]，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。
3.7敏捷需求分析小结
综合以上的陈述，对敏捷需求分析归纳如下表（角色职责的变化也是一种重要的对比，请参见表1，此处不赘言）：

角度	传统需求分析	敏捷需求分析
需求分析时机	更多地集中在项目早期	近乎均匀地贯穿于项目的整个生命周期
需求划分单位	基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大	基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；用户故事是小粒度的，可测试的，可见的，并且是有价值
需求细化过程	一步到位，可供开发人员设计开发	逐步细化，仅就下一个迭代需要实现的部分进行详细分析
需求文档要求	正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪），很多产出物最终难以被阅读。	非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求。（对于组织过程资产管理要求，可以在此基础上形成可阅读可理解的轻型文档）。
需求文档同步	项目中后期一般都处于不同步状态	即时的同步
需求传递过程	单向的陈述与记录，文档传导（线性的传递，误导放大，缓慢）	聚议，共同参与，业务场景与用户故事，及时的非正式沟通
应对需求变更	有严格的控制流程，视变更为风险	视变更为必然或预期中的事情

表2：敏捷需求分析的特征对比
4. 应用敏捷需求分析的质量保证
一个传统的软件实现过程，遵循计划与严格的控制来保证质量。管理手段的控制有时不能及时纠正工程领域的偏差，即使控制体系给了更多的回馈机制，实质上更多地只是增加了信息层级和复杂度。

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