不知道大家有沒有和我一樣的情況，就是想寫一篇博客，不知道從何寫起，如何組織語言，如何安排這篇博客的要交待的事情的前因后果；如果在寫作過程中被打斷，又不知道如何重新拾起鍵盤，從哪里寫起?！熬腿缬薰图胰苏驹谕跷萆角耙粯?#xff0c;他們可能都在想：這座大山到底要花多少時間才能搬完呢？”這也像在軟件工程中，一個團隊要完成一個項目，從哪里入手呢，如何才能實現用戶的需求，并能用一個完美的架構，讓軟件的后期便于二次開發和維護。在《構建之法》（第二版，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要按照最后希望交付給用戶的所有功能進行拆分。這就是吃蛋糕，發胖的全過程，你懂了嗎？

轉載于:https://www.cnblogs.com/zhengrui0452/p/6653964.html

總結

以上是生活随笔為你收集整理的分而治之（Work Breakdown Structure, WBS）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。