敏捷开发管理--需求分解经验之谈

敏捷开发是快速迭代，快速交付的开发模式。这也就要求迭代周期内任务量不宜过大，以保证在预期内能够按时完成开发计划。敏捷开发中怎样保证开发任务的适宜呢？答案是任务分解。 而任务分解的前提则是 需求确认。

敏捷开发中的需求确认

我们都知道需求的来源渠道很多（如用户调查问卷，用户访谈，客户服务人员/商务人员的反馈，产品的技术交流群，用户使用数据分析等，甚至还有一部分来源于产品经理对产品的定义，以及对技术的把握和对竞品的分析），通常产品经理收集到的用户故事需要经过分析筛选整理，形成最初的产品需求。此时的产品需求算是草稿状态的产品需求。

产品经理通过发布计划会议对初步的产品需求进行讲解传达，由敏捷团队讨论细化，对其评估和排序之后形成需求条目，也就是可以排到敏捷开发计划里面去实现的需求列表。至此为需求确认的完成阶段。

需要注意的是，在需求分解时需要面对的一个问题是 需求的优先级问题。先做哪个后做哪个？你可以参考下面几个标准。

1. 价值，包括对产品自身的价值和对用户的价值，价值越高优先级越高。
2. 必要性，先做必需的功能特性，然后再做其他高级特性。
3. 紧迫性，时间要求越高的优先级越高，特别是线上问题的解决。

除了优先级问题，在敏捷开发中我们还需要面对 需求变更问题。需求变更之所以可怕，主要是因为变更影响的范围无法预估。在传统项目管理中，由于没有有力工具的支撑，产品经理在变更需求的时候，无法知晓该需求的影响范围，也就很被动。

而如今的项目管理工具已经很好的解决了这个问题，像禅道就是将需求、任务、bug和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给产品经理更好的指导。 虽然敏捷开发最大的优势是拥抱变化。但这并不意味着需求想变就变，产品经理还是要尽量控制变更情况的发生。

需求确认后就进入为需求分解任务阶段。 如何为需求分解任务呢？

敏捷开发的特性决定了迭代内任务量要适宜。任务量太大导致项目延期，任务量太小则工作量不饱和。所以需求的分解过程是一个对资源的评估再分配过程（这里的资源一般是指团队的开发能力，包括人员、任务量、工时等的合理统筹）。

需求分解在敏捷开发中一般通过迭代计划会议实现。敏捷团队对每一个需求进行分解，分解的标准是完成该需求（stroy）的所有任务，最终实现每个任务都有明确的负责人。敏捷开发中需求分解的目的在于将需求细化为可执行可评估的开发任务。

我们常用的管理软件禅道中这个过程就表现为“为需求分解任务”。研发团队对需求进行详细的评估和细分，生成完成这个迭代内的所有任务（这里的所有任务，包括但不限于设计，开发，测试等），团队成员领取任务，并进行工时的估计。

在具体操作上表现为通过创建任务，关联相应的需求来实现。在禅道的项目需求列表页面，可以方便的对某一个需求进行任务分解，同时还可以查看这个需求已经分解的任务数，指派的成员等（动态演示地址 为需求分解任务 - 禅道使用手册 - 禅道开源项目管理软件）。

分解任务的注意事项

需要将所有的任务都分解出来。这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等。

1. 任务分解的粒度越小越好，尽量控制在几个小时就可以完成。
2. 如果一个任务需要多个人负责，继续考虑将其拆分。
3. 任务应做到相对独立完整，某个任务的延期不至于影响到其他任务的进行。
4. 多个子任务要进行排序，要区分轻重缓急。
5. 任务的分配最好是自由领取，这样可以大程度上调动大家的积极性。

说到底，任务分解是敏捷开发管理中不可或缺的基本流程，任务分解的作用就在于将需求转变为可量化可执行的具体工作内容。同时敏捷团队也可以做到心中有数，项目经理更好的掌握研发进度，随时调整，以保证按时交付。因此，任务分解的实现使得敏捷开发得以更好的实现。