轉自：http://blog.csdn.net/lifuxiangcaohui/article/details/48342315

        敏捷開發工具“看板”,該詞彙來自於島國，當我看到看板的英文時，我真的驚呆了，看板竟然就是 Kanban？！

我們可以結合 Scrum 與 Kanban，讓專案管理更加有效，讓資源分配更加合理，讓績效考核更加公平！

• 對於專案經理而言，最擔心的就是專案進度不可控，不知道每位開發人員具體的工作進度，有了 Kanban 一切都是那麼地清晰。
• 對於開發經理而言，最擔心的就是資源分配不合理，忙的人忙死，閒的人閒死，有了 Kanban 一切都是那麼地自然。
• 對於開發人員而言，最擔心的就是績效考核不公平，“憑什麼我做的比他多，拿的工資卻比他少？不公平啊！”有了 Kanban 一切都是那麼地公平。

可見，專案經理、開發經理、開發人員擁有了 Kanban，也就擁有了和諧與快樂！

那麼 Kanban 到底是什麼呢？我們先來看看這張表格吧：

下面我們來理解一下這個表格吧！

• 這個表格有 5 列：Backlog（原始需求）、Selected（被選中的需求）、Develop（開發階段）、Deploy（部署階段）、Live（上線階段）
• 其中 Develop 階段包括 2 個子階段：Ongoing（進行中）、Done（已完成）
• 包括 3 中角色：產品經理（紅色小人）、開發人員（藍色小人）、部署人員（綠色小人），其實還有專案經理，只是他/她貫穿於始終，所有就沒有畫出來了。

在 Backlog 中放置了許多小卡片，它們在 Kanban 中被稱為 WIP（Work In Process，在製品）。對於產品經理而言，WIP 是需求，而對於開發人員與部署人員而言，WIP 卻是任務。

實際這些 WIP 卡片上都帶有一些文字描述，包括：標題、描述、優先順序等資訊。

需要注意的是，Selected、Develop、Deploy 下方有一個數字，該數字表示此階段中最多可以放置的 WIP 數量。例如，在 Selected 中最多隻能放 2 個 WIP；在 Develop 中（包括它的子階段）最多隻能放置 2 個 WIP。這裡的數字只是一個示例，具體多少可根據團隊實際情況而定。有一個經驗公式可以參考“WIP 上限 = 團隊規模 * 2 - 1”，減 1 表示大家需要協作，例如：4 人的團隊，WIP 上限是 7。

也許有人會提出，為什麼沒有 Test 階段？—— 這個可以有，這裡只是一個示例而已，你不妨自行加上去。

對於多個專案而言，可以在這張表格中新增更多的泳道（行），每一行相當於一個專案，所有的專案進度清晰明瞭。

好！繼續我們的 Kanban，有意思的事情即將發生！

產品經理挑選了 2 個 WIP 到 Selected 中，此時，由開發經理決定該任務的技術難度，並由專案經理將任務分配到指定的開發人員，也可將同一個任務分配給兩個人，讓他們去結對程式設計。

開發人員（架構師與程式設計師）可對 Selected 中的需求進行工作量評估，可採用投票的方式進行，最終給出一個合理的評估值，整個估算過程，專案經理無需參與，主要是開發人員共同完成。

開發經理可以對任務設定一個“分值”，這個分值可直接影響到後續的績效考核，所以對大家來說，這個分值是公開可見的，誰做的多，誰做得少，一目了 然。當然，開發人員也可以主動承擔具有更具挑戰的任務（為了鍛鍊自己，也為了多拿點錢），但任務分配的決定權始終在專案經理手中。

現在假設 A、B 兩個任務已經分別被不同的開發人員處理了，那麼這些任務就應該移動到 Ongoing 中，同時，產品經理可以從 Backlog 中挑選出 2 個優先順序較高的需求到 Selected 中。這樣就保證 Selected 與 Develop 都達到了 WIP 的上限。

有人已經把 A 做完了，那麼 A 就可以移動到 Done 中了。隨後，部署人員就可以開始幹活了。

部署人員就可以將 A 從 Done 中移動到 Deploy 中，表示部署人員正在做這件事情。同時，做完了 A 任務的開發人員可以再做其它新任務，只需從 Selected 中移動到 Ongoing 中，移動這件事情不是開發人員隨意操作的，而是有專案經理負責的。產品經理髮現 Selected 中只有一個 D，就可以考慮放入一些新的需求了。

此時，部署人員遇到了問題，發現 A 部署的時候總是報錯，跑不起來了。同時，其他開發人員也完成了 B 任務。

完成了 B 任務的開發人員本來是可以做新需求的，但專案經理髮現 Develop 中只能放 2 個任務，所以肯定是後面的階段出現了問題，導致整個流程受阻了。專案經理可以靈活排程人力資源，集中火力解決現在所遇到的問題。

所以專案經理不得不放棄新的任務，去讓開發人員去幫助部署人員來解決問題。此時，其他的開發人員還在進行 C 任務。

部署的問題還沒來得及解決，此時 C 任務也完成了，同時，產品經理也放入了新的 K 需求，確保 Selected 這個水池是裝滿水的。

整個部署問題看起來比較搞人，所有的開發人員全都上陣了，集中更多人的智慧，解決這個棘手的問題。此時，產品經理不能放入更多的需求，由於此時 Selected 已經滿額了。其實，開發人員面對太多的需求時，往往都會倍感壓力，身心憔悴。

看來這個部署問題，確實夠折騰的，連產品經理都過來了湊熱鬧了。但他或許不懂技術，但多個人多個頭腦吧，正所謂“當局者迷，旁觀者清”，最終經過大家的努力，肯定會攻克這座碉堡！

幾天之後，Kanban 流程依舊是穩定的，大家分工協作，人力資源合理利用。大家是一個團隊，目標就是把專案做好，不會因為自己的事情做完了就閒置了。

我們不妨將這張表格貼到牆上去吧！讓每個員工都可以看到，讓過路的老闆們也可以看到我們的辛苦努力，這確實是一種非常好的專案管理方法！