什么是分而治之/了解WBS _wbs

什么是分而治之/了解WBS
分而治之（Work, WBS）
不知道大家有没有和我一样的情况，就是想写一篇博客，不知道从何写起，如何组织语言，如何安排这篇博客的要交待的事情的前因后果；如果在写作过程中被打断，又不知道如何重新拾起键盘，从哪里写起。“就如愚公和家人站在王屋山前一样，他们可能都在想：这座大山到底要花多少时间才能搬完呢？”这也像在软件工程中，一个团队要完成一个项目，从哪里入手呢，如何才能实现用户的需求，并能用一个完美的架构，让软件的后期便于二次开发和维护。在《构建之法》（第二版，181页）中，给了一个完美的解决方案：分而治之（WBS,Work）。啥意思呢？就是一个完整的蛋糕，一下吃掉很难，但把蛋糕分成若干块，一块一块的吃掉就能变胖。在软件工程中也是如此，一个项目千头万绪，要一下完成很难，所以我们要把一个项目拆分成若干个需求，每一次只干其中的一件事，然后一件一件的完成后，一个项目就完成啦。
为啥要拆分呢？拆分了有啥好处呢？其实前面也说过了，一个大蛋糕，一下吃不到嘴里嘛，那还想吃掉蛋糕咋办呢？就切着吃呗。切到一口那么大，就能完美的吃掉蛋糕啦。软件工程中也是如此，一个项目可能有若干的需求，你的团队一下子完成不了，或者不知道从哪里下手啊；可能知道如何开始了，中间被哪个同学叫去打游戏了，回来的时候忘记写到哪里了，或者看之前写的代码完全不知为何物，那就不好办了嘛。但是，当我们把一个项目拆成若个块，一个一个的解决他们就不用怕这样的问题出现啦，如果小伙伴把你叫去打游戏了，你回来的时候只要知道自己在吃哪块蛋糕就行啦，如果你发现这块蛋糕之前被你咬得太丑，那你就修整一下，把它变好看了，再把它吃下去就行了，而不用修整一整个蛋糕，工作是不是变容易了一些呢？再强调一变，这种好方法叫WBS 。

文章插图
那如何做到WBS呢？书中说得很清楚：从最终的产品开始，一层一层往下，把大型交付件（）分割为小型、具体的交付件。WBS分割的结果是一棵树。
我用一个我们学《构建之法》时做的项目为例。我们团队当时做得是“抢答器”(做得太烂啦，不要见笑) 。我们将抢答器这个产品按照最后想提交给用户的软件功能来做WBS，我们将抢答器分割成：
这样一个抢答器想要交付给用户的功能就都在这棵树上啦。那如何验证你的WBS做得对不对呢？书中说得也很清楚：

文章插图
保证所有子节点覆盖了全部父节点包含的内容。比如在“抢答器”这个项目中，用户所能看到的全部功能有：登录、看题、抢答、弹幕、查看点击抢答后自己在所有抢答者的点击时间中的排名、抢答倒计时、查看自己抢答积分结果。“抢答器”整个项目只包含抢答用户模块、主持用户模块和管理模块三个部分。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点，当然就要再细分，直到每一个独立的子节点都被细分出来，这棵大树才会强建。比如“题目增删改查”这个叶子结点还可以再细化成题目的导入、题目的修改、题目的展示、题目的删除，其实在后来实现项目的过程中，我们也的确是这么做的。
保证各个子节点不要相互覆盖。比如在“抢答器”这个项目中，抢答用户模块和主持用户模块都有“看题”这个叶子节点，则要在两个用户模块下分别列出，而不能只在一个父节点中列出。