一、为什么要任务分解

  1、情景

  在做项目过程中,经常出现下面几种情况:
  (1)研发说:“由于我当初写开发方案时没想到这个地方这么复杂(或者这里隐藏了很多需要开发的需求),所以想要延长开发时间”。
  (2)项目上线后或者提测后发现,研发有些功能或逻辑没有实现,研发会说:“我开发的时候没有注意到”。
 

  2、根本原因

  上述这些研发的说辞看似解释了这些情况的原因,其实这只是借口,并不是问题的根本原因。
  对于上述两种情况,研发没有想到某些地方存在复杂逻辑以及没有注意到隐藏需求。其根本原因是:
  (1)在需求评审和分析时,没有仔细分析和拆解各个需求任务的逻辑和功能;
  (2)在写开发方案时,比较粗糙和偷懒,没有把所有需求任务分解到最小粒度。
  总结上述两个根本原因,就是在需求分析和编写开发方案时没有做好任务分解。

  3、任务分解的重要性

  要想避免由于没有做好任务分解,而导致项目进度或者项目质量的问题。首先研发需要重视任务分解的重要性。虽然产品经理已经把整个项目的目标和需求描写清楚了,但是距离研发立马上手编写代码还需要两个重要的关键步骤,就是需求分析和编写开发方案。
  研发的需求分析,主要是以下工作:
  (1)了解和掌握项目中的业务逻辑和业务流程,检查逻辑是否自洽;
  (2)研究项目的开发可行性;
  (3)将项目拆解模块(这个阶段不分解到最小粒度),主要是对项目的业务框架有基本的了解,以及对项目的体量和复杂度有大概的了解;
  (4)将本次项目的重点和难点部分标记出来,可能时复杂逻辑、或性能要求、或公共组件和方法等(在编写开发方案和开发时需要重点考虑)。
 
  编写开发方案应该要有以下几个步骤:
  (1)根据需求文档,分解项目任务。
  分解任务是一个综合步骤,具体怎么分解,下面会讲到。
  分解任务时,一定要将任务一层一层分解,直到分解不下去。最终的最小粒度任务是可以交给任何一个开发人员,简单解释就可与让该开发人员明白具体要做什么。
  这一步,需要产出一个任务列表(树状结构)。
  (2)根据第一步产出的任务列表,对项目进行框架设计。比如,某个业务逻辑的实现可以参考哪个设计模式、哪些方法可以抽象成公共方法、哪个业务方法需要使用分布式事务或者消息队列。
   这一步主要是开发人员对整个项目的代码框架进行设计,设计后会得到一个新的任务列表(同样是最小粒度)。这里可以对重点部分和难点部分进行着重设计。
  (3)根据任务列表,进行排期和分配任务。
 
  通过分解任务和得到的任务列表,对我们有什么作用:
  (1)可以准确且清晰地定义项目的范围;
  (2)方便给开发人员分配任务,以及后续寻找负责人;
  (3)可以提高估算开发时长的准确度;
  (4)方便排出各个任务的优先级;
  (5)有利于明确项目的影响范围,最大程度地降低风险。
 

二、怎么任务分解

  每个研发都有自己分解任务的方法,但是都需要遵循以下分解原则:
  (1)分解任务一定要以结果为导向,切不可为了分解而分解。我们分解任务是为了高效地做项目,使项目的最终交付结果符合预期。如果一个小项目,它已经很明确清晰地显示了各个子任务,那大可不必花时间和精力去做分解。
  (2)分解任务要像剥洋葱那样,一层一层地往下分解。切不可跳过中间层级,像切洋葱那样一步就分解到最小单元。
  (3)分解任务一定要分解到最小粒度,分解到不能再细分为止。
  (4)从上向下分解,一般是分解某个任务或者功能的组成元素,这样也符合面向对象的编程范式-组合原则。在最下层可以描述最小任务的具体。
  (5)要遵循 MECE 原则。
      a、相互独立,在同一层级上的任务有明确区分、不可重叠;
      b、完全穷尽,不遗漏,尽可能穷尽所有的小任务。
 
  分解完成后会得到一个项目任务的树状图,然后根据这个树状图进行代码框架设计。设计后根据树状图就可以产出一个项目任务列表,这个列表只是表格形式的任务分解树状图,只是它会有更详细的信息,比如每个任务的开发时长、负责人等。
 
02-10 20:57