3.2 敏捷需求分析工作形式

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

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

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

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

　　3.3 需求分析时机

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

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

　　3.4 需求的划分

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

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

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

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

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

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