文章目录
[+]
三、自上而下
自上而下是最主要最常规的任务分解方法，是从一般到特殊，从项目的大型着手，根据一定的逻辑和结构分解成子项目。
这是一个“变化计数器”系统，这个项目是比较两个程序之间代码变化情况，根据需求首先分解为版本比较等六个细目这是第二层，其次是第三层。
其实任务分解的层次没有统计的标准，可以根据对任务的工作量，任务安排来决定。例如版本比较细目再分解为三个细目，这样可以更好的估算和分配任务，其他以此类推，直到分解到足够清晰，详细为止。
（图片来自网络侵删）
四、自下而上
那么自上而下是对细目大致有把握的，需求有了解，熟悉的。如果对项目不够清晰，可以采用自下而上的方法。
例如下图：从特殊到一般，从先定义特殊任务开始，那么这些特殊任务没有很强的逻辑关系。
例如对项目的需求不清楚，我们可以找一个白板，将想到的所有工作细目直接写在白板上，可能很随意，没有逻辑关系，然后我们按照一定的逻辑关系组织起来，形成更高级别的WBS。一般情况下，自下而上的分解方法很少使用。
WBS任务分解建议最低层是可控可管理的，但是不必要过细。每个Work package必须有一个提交物。定义任务完成的标准。分解结果有利于责任分配。任务分解有个规则叫做88规则，既大于8小时，小于80小时，而软件项目比较特殊，所以我们推荐任务分解到40小时以内，敏捷项目分解到小时。总结
总之 通过任务分解方法可以将项目分解到足够小，方便后续的任务估算。
到这里，第五章 第二节任务分解方法就讲解完毕！
下一节介绍敏捷任务分解方法~
如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~
后续将持续更新【软件项目管理初级学习路线】的全知识点，大家感兴趣的多多关注博主哟~————————————————
