1. 程式人生 > >使用看板進行敏捷開發

使用看板進行敏捷開發

今天想與大家分享一款敏捷開發工具“看板”,該詞彙來自於島國,當我看到看板的英文時,我真的驚呆了,看板竟然就是 Kanban?!

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

  • 對於專案經理而言,最擔心的就是專案進度不可控,不知道每位開發人員具體的工作進度,有了 Kanban 一切都是那麼地清晰。

  • 對於開發經理而言,最擔心的就是資源分配不合理,忙的人忙死,閒的人閒死,有了 Kanban 一切都是那麼地自然。

  • 對於開發人員而言,最擔心的就是績效考核不公平,“憑什麼我做的比他多,拿的工資卻比他少?不公平啊!”有了 Kanban 一切都是那麼地公平。

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

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

image

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

  • 這個表格有 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,有意思的事情即將發生!

image

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

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

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

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

image