8.7 分而治之（Work Break Structure）如何分？

[GreyZeng]

原书第八章在第185页提出分而治之的策略，也提出了如下几个要点：

保证所有子节点覆盖了全部父节点包含的内容。
保证各个子节点不要相互覆盖。
叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。
从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。

我认为，在第二点的表述上作者出现了失误，覆盖有包含的意思，表达的不够准确，应该替换为交叉。分而治之可以说是将整个项目流程进行划分，从底部往上进行整合，但子任务是交由不同角色去完成的，必然会存在着部分子任务完成而其余子任务还在进行中的情况，这时候是让其他人帮助进行未完成的子任务，还是等着负责人独自完成该任务呢。所以第四点中说要从结果出发而不是活动出发去构建WBS，我觉得是存在一部分问题的，预期总是会伴随着一些意想不到的事情。就比如COD17的开发，本来是由动视下的大锤完成开发，但因为人员变动的原因，最后交由T组来完成，以致于COD17因为开发周期只有1年半而被称作“半成品”。原本的开发时间本来是十分充裕的三年，到最后只有一年半。构建一个好的WBS，我认为，应该从结果和活动一起出发，以结果为主，活动为辅，考虑到可能出现的人员变动来制定计划。
————————————————
版权声明：本文为CSDN博主「メ幻梦灬虚妄ベ」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/CJQ6661999/article/details/123407887

[SoftwareTeacher]

就比如COD17的开发，本来是由动视下的大锤完成开发，但因为人员变动的原因，最后交由T组来完成

---

这句话讲得太简略， 一个项目的变动和成败有很多原因， 这个和 WBS 的关系是什么呢？