需求分析的思考

        敏捷开发的需求以用户故事的方式呈现和管理。用户故事描述需求简单明了，方便客户、市场、产品经理和开发等利益相关方的基本交流，不像以前的需求规格说明书，虽然描述毕竟完整，但不利于多方的交流，只适合开发内部使用。而需求规格说明书，不仅编写复杂繁琐，阅读理解起来也不容易，即使编写再细，总还是遗漏，再加上各个方面的变更，使得需求规格说明书的维护更加困难。

        敏捷开发中的需求是以用户故事列表形式呈现，并按照商业价值、依赖关系、必要性、紧迫性进行排序 ，来安排优先级。但这种用户故事列表，缺乏需求全局信息，在创建用户故事列表前，最好有一个总体需求分析，了解需求背景，要实现商业核心目标，参与的主要角色，使用的主要场景，核心的业务逻辑等等。在总体需求分析下，建立故事地图，逐渐分解用户故事，分解成一个迭代周期能完成的粒度，从史诗级故事分解成特性，再从特性分解成用户故事。根据反馈再不断添加新故事，生成和维护有价值的用户故事列表。

        在迭代开发时，产品经理从用户故事列表中，挑选出适合本次迭代周期开发的候选用户故事，并做需求精细化，然后需求评审，任务分解和领取。本次迭代周期中的故事尽量不要相互关联，否则开发时容易相互干扰，影响协作，不利于并行。在挑选本次迭代开发的用户故事时需要产品经理和敏捷教练协商，选取的用户故事正如上面说的，没法直接作为开发的依据，需要产品经理把需求精化。在需求精化之前，先确定一些主要功能点，或拆分成更小更多的子用户故事，和相关用户、市场进行初步沟通，达成基本的一致，然后再细化需求。细化需求时输出可以用原型图，也可以用文字描述的文档，也可以用思维导图。一般情况下，建议还是用思维导图，从用户使用的角度来描述详细需求，复杂的地方可以用备注来详细描述，其余的尽量用关键字描述即可，有些复杂的交互流程可以再加一些补充文档，通过状态图、时序图等 UML 图来进一步描述。这些需求细化输出的文档，目的是为了交流协作，所以只要能达到相关人员基本理解即可，更多的信息可以在接下来需求评审时讲解讨论。在开始需求评审前，相关开发人员需要先把需求文档仔细看看，理解整个需求，记录下存在的问题和疑问，在会上进行讨论。为了防止一些人，没有提前阅读需求文档，可以要求相关人，每人最少记录 5 个问题发出来，这样在一定程度上迫使他们去认真地了解需求。 大家都仔细看了需求相关文档后，开始组织需求评审会，参会人员一般是敏捷教练、产品经理、UI、前端、后端、测试这些角色。产品经理依据思维导图或其它文档，先说明需求的总体结构和模块，模块和结构之间的关系，然后逐一展开细讲。在讲述需求过程中，允许随时被打断来沟通讨论问题，发生变更的，直接修改需求文档，因为主要是思维导图，所以修改一些关键字即可，比较方便。讨论需求时，尽量不要带上实现的细节问题，代码设计结构，数据库表等相关事情，一旦出现需尽快阻止，否则偏离本次需求评审的主题。每当一个功能模块讲解完时，停顿询问大家还有没有什么问题，没有后再讲下一个模块。需求评审过程中，如果出现大的争议，并且现场很难确定，并且影响后续大量的需求细节，可以先暂停会议，等这些问题解决了后再继续会议，一般的非关键性问题，现场也解决不了的，可以先记录下来，会后解决后再通知给大家。需求评审时，谨防临时添加更多的需求功能点，最好等这些必要基本功能上线后，根据用户的反馈再来完善，否则，不仅很容易白做，而且还引起返工。需求评审会议快结束时，需要做一下任务分解，每个任务工作量大致分为 4 到 16 个小时，除了需求任务，还有非需求的相关任务，虽然此时的任务分解可能还会有问题，但随着后面工作进展，再进行补充调整。根据初步分解的任务，看看能否在本次迭代周期内开发完成，如果存在风险，则需要把一些商业价值低的任务砍掉，或遗留到下个迭代周期。然后让大家开始领取任务，这样更能提高积极性，每个人任务最好由一个人单独负责，如果出现多个人负责任务，需要进一步细分任务。以上阶段完成后，就开始各个阶段的设计，例如， UI 开始，概要设计和测试用例的设计等

        有的人说，按照敏捷开发 scrum 的指导，应该是所有参与开发人员，一起对把用户故事的需求精化，这样大家参与感强，后续的开发时更积极主动。理论上是没错，前提需要一帮能力很强开发人员，他们非常乐意参与讨论当中，并能让问题快速收敛。但实际当中，一个团队需求分析的能力差距很大，总会发现在讨论中，只有个别几个人在不停思考讨论完善需求细节，更多的人是观望和偶尔的发言，并且经过长时间的讨论还是有不少遗漏。所以，与其大家共同参与细化需求，还不如由一个人主导，其余人补充完善，这样效率和质量反而更高。关于参与性不足的问题，可以在后面的设计过程中弥补。