五、软件项目任务分解
5.1、任务分解基本概念
任务分解过程： 将一个项目分解为更多的工作细目或者子项目，使项目变得更小，更易管理，更易操作。
任务分解结果： WBS(Work Breakdown Structure) 任务分解结构
软件需求分解： 需求拆分以获取范围灵活性
- WBS是对项目由粗到细的分解过程
- 面向交付结果的
- WBS组织并定义了整个项目范围(即只有WBS中的细目才是项目该完成的工作，不在WBS中包括的工作就不是该项目的工作)
工作包(Work Package)
- WBS的最低层次的可交付成果
- 工作包应当由唯一主体负责
工作包可以以外包的形式给另外一个项目经理通过子项目的形式来完成。
WBS可以采用图标形式，也可以采用清单形式
WBS字典： 可以通过WBS字典对WBS相关性进行描述，WBS字典的具体描述相关性进行描述，WBS字典的具体描述项没有统一标准。是否编写WBS字典主要靠管理者的需求。
任务分解是项目管理的基础，有了任务分解可以方便进行项目估算和规划。
检验分解结果的标准
- 最底层的要素是否实现目标的充分必要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人
- 是否可以进行成本估算和进度安排
5.2、任务分解方法
分解方法：
- 类比
- 模板参照
- 自上而下
- 自下而上
类比： 有些项目有相同或相似的周期和因此而形成的相同或相似的工作细目可用类比法。
模板参照： 如果项目有可以参照的WBS模板，可以用模板参照的方法进行分解。
自上而下(最主要最常规的分解方法)：
- 从一般到特殊，从项目的大局着手，按照一定的逻辑和结构分析子项目。
- 任务分解层次没有统一标准，根据对任务的工作量安排来工作
- 是要对项目大局有把握的，需求有了解熟悉的，如果不了解可以用自下而上方法
自下而上(一般很少用)： 从特殊到一般
WBS分解建议
- 最底层是可控的和可管理的，但是不必要过细
- 每个Work Package必须有一个提交物
- 定义任务完成的标准
- 有利于责任分配
- 推荐任务分解到40小时以内，敏捷项目分解到小时(任务分解有一个规则叫88规则，大于8小时，小于80小时)
通过任务分解方法可以将项目分解到足够小，方便后续任务估算
步骤：
- 确认并分解项目的组成元素
- 确认分解标准，按照项目实施管理的方法分解，而且分解的标准要统一
- 确认分解是否详细，是否可以作为费用和时间估计的标准，明确责任
- 确定项目交付成果(可以编制WBS字典)
- 验证分析正确性，验证分解正确后，建立一套编号系统
5.3、敏捷任务分解
敏捷开发过程是通过用户故事将需求具体化成可以进行迭代开发的任务。
敏捷项目的任务分解(基于story的分解)
- Epics(由许多较大的不确定的需求组成)
- Epics break down
Epics
- 用户故事可以用不同层次的级别来编写
- 大的用户故事通常被认为是epic
- 因为一个epic对于敏捷团队来说太大了，不可能在一次迭代中完成，所以在开发前，它会被分解成多个更小的用户故事。
敏捷任务分解
story编写完成后应给出Acceptance Criteria(接收标准)
Acceptance Criteria(作为用户测试story的依据)
- 验收标准只是一个高层次的验收测试，在敏捷用户故事完成后，它将是真实的
- 通常写在故事卡片的背面
- 这是确保一个故事被理解并邀请团队就我们试图创建的业务价值协商的好方法
敏捷项目任务分解的输出可以是对Backlog列表进行细化的过程，将编写完成的story汇总到Backlog列表中。