不知道大家有没有和我一样的情况,就是想写一篇博客,不知道从何写起,如何组织语言,如何安排这篇博客的要交待的事情的前因后果;如果在写作过程中被打断,又不知道如何重新拾起键盘,从哪里写起。“就如愚公和家人站在王屋山前一样,他们可能都在想:这座大山到底要花多少时间才能搬完呢?”这也像在软件工程中,一个团队要完成一个项目,从哪里入手呢,如何才能实现用户的需求,并能用一个完美的架构,让软件的后期便于二次开发和维护。在《构建之法》(第二版,181页)中,给了一个完美的解决方案:分而治之(WBS,Work Breakdown Structure)。啥意思呢?就是一个完整的蛋糕,一下吃掉很难,但把蛋糕分成若干块,一块一块的吃掉就能变胖。在软件工程中也是如此,一个项目千头万绪,要一下完成很难,所以我们要把一个项目拆分成若干个需求,每一次只干其中的一件事,然后一件一件的完成后,一个项目就完成啦。

为啥要拆分呢?拆分了有啥好处呢?其实前面也说过了,一个大蛋糕,一下吃不到嘴里嘛,那还想吃掉蛋糕咋办呢?就切着吃呗。切到一口那么大,就能完美的吃掉蛋糕啦。软件工程中也是如此,一个项目可能有若干的需求,你的团队一下子完成不了,或者不知道从哪里下手啊;可能知道如何开始了,中间被哪个同学叫去打游戏了,回来的时候忘记写到哪里了,或者看之前写的代码完全不知为何物,那就不好办了嘛。但是,当我们把一个项目拆成若个块,一个一个的解决他们就不用怕这样的问题出现啦,如果小伙伴把你叫去打游戏了,你回来的时候只要知道自己在吃哪块蛋糕就行啦,如果你发现这块蛋糕之前被你咬得太丑,那你就修整一下,把它变好看了,再把它吃下去就行了,而不用修整一整个蛋糕,工作是不是变容易了一些呢?再强调一变,这种好方法叫WBS。

那如何做到WBS呢?书中说得很清楚:从最终的产品开始,一层一层往下,把大型交付件(Deliverable)分割为小型、具体的交付件。WBS分割的结果是一棵树。

我用一个我们学《构建之法》时做的项目为例。我们团队当时做得是“抢答器”(做得太烂啦,不要见笑)。我们将抢答器这个产品按照最后想提交给用户的软件功能来做WBS,我们将抢答器分割成:

分而治之(Work Breakdown Structure, WBS)-LMLPHP

这样一个抢答器想要交付给用户的功能就都在这棵树上啦。那如何验证你的WBS做得对不对呢?书中说得也很清楚:

  • 保证所有子节点覆盖了全部父节点包含的内容。比如在“抢答器”这个项目中,用户所能看到的全部功能有:登录、看题、抢答、弹幕、查看点击抢答后自己在所有抢答者的点击时间中的排名、抢答倒计时、查看自己抢答积分结果。“抢答器”整个项目只包含抢答用户模块、主持用户模块和管理模块三个部分。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点,当然就要再细分,直到每一个独立的子节点都被细分出来,这棵大树才会强建。比如“题目增删改查”这个叶子结点还可以再细化成题目的导入、题目的修改、题目的展示、题目的删除,其实在后来实现项目的过程中,我们也的确是这么做的。
  • 保证各个子节点不要相互覆盖。比如在“抢答器”这个项目中,抢答用户模块和主持用户模块都有“看题”这个叶子节点,则要在两个用户模块下分别列出,而不能只在一个父节点中列出。
  • 叶子节点要保证足够小,能在一个里程碑中完成。这就是刚才说的,切得蛋糕要一口就能吃掉,否则就切得不成功,要不一口吃不掉,要不会噎死。做项目也是一样,把功能划分得细不要紧,一天多做两个功能呗,更有成就感,但你划分得不够细,很久很久都做不完,你就有可能慢慢就看不到希望了。还是“题目增删改查”这个需求,其实在实现的时候,我们还是划分了四天去实现它,这样项目控制起来就容易很多。
  • 从结果出发构建WBS,而不是从团队的活动出发。这点其实是很重要的,“从结果出发”就是你想呈现给用户的样子,你的所有父结点和叶子结点都是用户能看得懂的,而不是你们团队将要使用什么技术来解决这个问题。就比如抢答用户模块中的“抢答”,我说参赛者一定可以进行“抢答”,用户一定可以看得懂,但我说要使用监听来监测请求,这用户一定看不懂,因为这是你团队要干的事,不是要呈现给用户的结果。

下面介绍几个非常好用的工具,帮助大家来做WBS:

以上这些工具都是不错得选择,下面我介绍一个我用过的,而且感觉非常棒的Leangoo,这是杨贵福老师推荐我用的,和上面提到的trello差不多。它可以微信登录,所以对我来说添加朋友共同讨论这个项目比较方便。

分而治之(Work Breakdown Structure, WBS)-LMLPHP

如上图,这展示了一个项目的全部内容,作者将这个项目进行了WBS,并且使用目标, 待办事项, 进行中, 已完成来划分泳道,清晰的表明我还有哪些任务没有做,接下来要做哪些任务,我正在做哪些任务,我已经完成哪些任务,这样一个项目就清晰的呈现在你的面前了。如下图,还能看到你的燃尽图,多么美妙的工具啊!
分而治之(Work Breakdown Structure, WBS)-LMLPHP

总结一下,一个项目不可能一下就开发完成,那么就要采取WBS。采用了WBS,整个项目会更加清晰,也会在每个里程碑时期,感觉有事可干,每个团队成员都能行动起来,向着一个共同的目标努力。采用WBS要按照最后希望交付给用户的所有功能进行拆分。这就是吃蛋糕,发胖的全过程,你懂了吗?

05-11 13:51