不知道大家有没有和我一样的情况，就是想写一篇博客，不知道从何写起，如何组织语言，如何安排这篇博客的要交待的事情的前因后果；如果在写作过程中被打断，又不知道如何重新拾起键盘，从哪里写起。“就如愚公和家人站在王屋山前一样，他们可能都在想：这座大山到底要花多少时间才能搬完呢？”这也像在软件工程中，一个团队要完成一个项目，从哪里入手呢，如何才能实现用户的需求，并能用一个完美的架构，让软件的后期便于二次开发和维护。在《构建之法》（第二版，181页）中，给了一个完美的解决方案：分而治之（WBS,Work Breakdown Structure）。啥意思呢？就是一个完整的蛋糕，一下吃掉很难，但把蛋糕分成若干块，一块一块的吃掉就能变胖。在软件工程中也是如此，一个项目千头万绪，要一下完成很难，所以我们要把一个项目拆分成若干个需求，每一次只干其中的一件事，然后一件一件的完成后，一个项目就完成啦。
为啥要拆分呢？拆分了有啥好处呢？其实前面也说过了，一个大蛋糕，一下吃不到嘴里嘛，那还想吃掉蛋糕咋办呢？就切着吃呗。切到一口那么大，就能完美的吃掉蛋糕啦。软件工程中也是如此，一个项目可能有若干的需求，你的团队一下子完成不了，或者不知道从哪里下手啊；可能知道如何开始了，中间被哪个同学叫去打游戏了，回来的时候忘记写到哪里了，或者看之前写的代码完全不知为何物，那就不好办了嘛。但是，当我们把一个项目拆成若个块，一个一个的解决他们就不用怕这样的问题出现啦，如果小伙伴把你叫去打游戏了，你回来的时候只要知道自己在吃哪块蛋糕就行啦，如果你发现这块蛋糕之前被你咬得太丑，那你就修整一下，把它变好看了，再把它吃下去就行了，而不用修整一整个蛋糕，工作是不是变容易了一些呢？再强调一变，这种好方法叫WBS。
那如何做到WBS呢？书中说得很清楚：从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。WBS分割的结果是一棵树。
我用一个我们学《构建之法》时做的项目为例。我们团队当时做得是“抢答器”(做得太烂啦，不要见笑)。我们将抢答器这个产品按照最后想提交给用户的软件功能来做WBS，我们将抢答器分割成：
这样一个抢答器想要交付给用户的功能就都在这棵树上啦。那如何验证你的WBS做得对不对呢？书中说得也很清楚：
- 保证所有子节点覆盖了全部父节点包含的内容。比如在“抢答器”这个项目中，用户所能看到的全部功能有：登录、看题、抢答、弹幕、查看点击抢答后自己在所有抢答者的点击时间中的排名、抢答倒计时、查看自己抢答积分结果。“抢答器”整个项目只包含抢答用户模块、主持用户模块和管理模块三个部分。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点，当然就要再细分，直到每一个独立的子节点都被细分出来，这棵大树才会强建。比如“题目增删改查”这个叶子结点还可以再细化成题目的导入、题目的修改、题目的展示、题目的删除，其实在后来实现项目的过程中，我们也的确是这么做的。
- 保证各个子节点不要相互覆盖。比如在“抢答器”这个项目中，抢答用户模块和主持用户模块都有“看题”这个叶子节点，则要在两个用户模块下分别列出，而不能只在一个父节点中列出。
- 叶子节点要保证足够小，能在一个里程碑中完成。这就是刚才说的，切得蛋糕要一口就能吃掉，否则就切得不成功，要不一口吃不掉，要不会噎死。做项目也是一样，把功能划分得细不要紧，一天多做两个功能呗，更有成就感，但你划分得不够细，很久很久都做不完，你就有可能慢慢就看不到希望了。还是“题目增删改查”这个需求，其实在实现的时候，我们还是划分了四天去实现它，这样项目控制起来就容易很多。
- 从结果出发构建WBS，而不是从团队的活动出发。这点其实是很重要的，“从结果出发”就是你想呈现给用户的样子，你的所有父结点和叶子结点都是用户能看得懂的，而不是你们团队将要使用什么技术来解决这个问题。就比如抢答用户模块中的“抢答”，我说参赛者一定可以进行“抢答”，用户一定可以看得懂，但我说要使用监听来监测请求，这用户一定看不懂，因为这是你团队要干的事，不是要呈现给用户的结果。
下面介绍几个非常好用的工具，帮助大家来做WBS：
- coding.net内置的Issue管理
- github内置的Issue管理
- 列表式Issue管理：redmine
- 看板式Issue管理：trello Beginner Tips for Using Trello
- wroktile
- teambition
以上这些工具都是不错得选择，下面我介绍一个我用过的，而且感觉非常棒的Leangoo，这是杨贵福老师推荐我用的，和上面提到的trello差不多。它可以微信登录，所以对我来说添加朋友共同讨论这个项目比较方便。
如上图，这展示了一个项目的全部内容，作者将这个项目进行了WBS，并且使用目标, 待办事项, 进行中, 已完成来划分泳道，清晰的表明我还有哪些任务没有做，接下来要做哪些任务，我正在做哪些任务，我已经完成哪些任务，这样一个项目就清晰的呈现在你的面前了。如下图，还能看到你的燃尽图，多么美妙的工具啊！
总结一下，一个项目不可能一下就开发完成，那么就要采取WBS。采用了WBS，整个项目会更加清晰，也会在每个里程碑时期，感觉有事可干，每个团队成员都能行动起来，向着一个共同的目标努力。采用WBS要按照最后希望交付给用户的所有功能进行拆分。这就是吃蛋糕，发胖的全过程，你懂了吗？