文章摘要: 你可以將團隊所有的工作流程對映到單個看板上並通過在每個泳道上放置特定列來推進看板工作流程
關鍵要點
- 盲目實現複雜的看板很可能會導致長期失敗。
- 在熟練使用看板後,需要詳細的工作流程圖來優化流程。
- 應該將最重要的流程步驟放到看板的列中。
- 藉助泳道將相似的活動分組,並根據優先順序安排工作流程。
- 使用每個泳道的不同列建立靈活的工作流有助於充分發揮工作流程的潛力。
看板的受歡迎程度日益增長。這種方法適用於各種行業,比如從建築行業到營銷行業。因為使用了這種方法,數以百萬計的人產出更好的結果。
雖然實現看板看起來相當簡單,但只有那些願意嘗試自己的工作流程並且將測試結果反映到實際步驟中的人才能夠充分利用該方法。
在下面的段落中,你將看到實現看板的最常見階段,並在逐漸熟練掌握該方法時學習如何提高工作流視覺化和控制程度。
堅持到最後一刻,看看如何在不造成混亂的情況下,優化團隊流程中的每一個步驟。
從你所在的位置開始
如果你的團隊剛剛開始使用看板,絕對不要急於繪製出複雜的設計圖或設定難以遵循的WIP限制。花一些必要的時間讓你的團隊參與進來,讓他們有機會做一些基礎練習。
看板的最簡單變體由三個列組成:
- 已請求
- 進行中
- 已完成
這種基本的看板佈局對於沒有看板經驗的團隊來說是非常有用的,因為它很容易引起人們對工作流視覺化的興趣。這樣有助於養成根據任務狀態來移動卡片的習慣,這是一個很好的開始。
讓團隊成員自己去拉取工作任務,可以更好地建立起流程管理。
這種看板佈局很容易就可以保持最新狀態,併爲WIP限制(看板的基礎之一)打下了堅實的基礎,對於使用物理白板來實現看板的團隊來說尤其如此。
基本看板的侷限性
通常,最基本的看板足以為團隊工作方式帶來可見的改進,但很快會遇到瓶頸。
等你熟悉了看板,就會注意到三列看板的侷限性,特別是當你在知識密集型的工作環境中使用看板時。
對於初學者來說,可以限制正在進行的總任務量,他們可以看到每一項已經開始的任務,但不知道每個任務的狀態。
你可能知道某人正在進行某項任務,但除非去找他要一份狀態報告,否則就無法知道這個人是否正在積極地處理任務或在等待什麼。
因此,可以說,基本看板除了讓你可以限制正在進行的工作量之外,它能夠提供的工作流程可見性和改進指導是非常有限的。
如何進行精確的工作流對映
在團隊熟悉了看板之後,應該向看板中新增幾個列和幾個泳道,以獲得更準確的工作流程檢視。
這樣有助於看到改善團隊工作方式的潛在機會,並實驗流程的不同步驟。
可能的列
例如,在軟件開發方案中,可以將「進行中」分成多個列,代表流程中最重要的幾個步驟,如:
- 技術設計
- 編碼
- 準備好程式碼評審
- 程式碼評審
- 準備部署
通過將「正在進行」分解為五個獨特的步驟,你就可以看到每項任務的進度,而不會讓看板變得太複雜,以致於團隊無法理解。此外,你將能夠視覺化開發過程中最常見的一個階段——評審階段。
可能的泳道
在使用額外的列完善看板的佈局之後,可以新增一些泳道,以使工作流視覺化更加精確。
泳道一般按照優先順序或活動進行分類。通常情況下,IT Ops團隊會優先按照優先順序劃分看板。這種情況下的標準垂直佈局是這樣的:
- 加速
- SLA 24小時
- SLA 48小時
邏輯很簡單,就是你的團隊根據優先順序開始新的任務。例如,如果你在「已請求」中有加速卡,那麼就暫停所有其他操作(除非是另一個加速卡)並立即開始處理加速卡中的任務。遵循這一思路,最後將卡片從SLA 48中移走。
根據工作型別分解看板是軟件開發團隊的常見做法。例如,開發團隊的一些泳道如下:
- 客戶問題
- Bug
- 技術債務
- 客戶/業務功能
- 技術特性
與優先順序泳道看板佈局類似,這個看板上的任務由開發人員從最高位置的泳道中拉出。邏輯幾乎是一樣的,頂部泳道包含最重要的卡片型別。
這裏有一個問題,在上述的兩種情況下都是根據優先順序拉取卡片,那麼根據工作型別對卡進行分組又有什麼意義?
答案隱藏在「計劃」當中。雖然看板沒有規定計劃機制,但在軟件開發中,這在一定程度上是必要的。
例如,產品的bug很少,技術債務很少,甚至是沒有,這是很重要的,但如果你想在這樣一個充滿活力的市場中生存下去,就不能完全停止開發新功能。
簡而言之,根據作業型別將卡分組在泳道中,可以優化團隊的能力,並以最有利的方式為客戶和僱主保持工作流程。
釋放看板工作流程的力量
通過實踐上述的知識,就能夠構建出堅實的看板工作流程,從多個方面來看,這樣的工作流程已經算得上是先進的。不過,這種方法可以給你帶來的好處遠不止這些。
橫向對映實驗
對流程中最重要的步驟進行視覺化足以優化工作流程,但還達不到先進的程度。只要你和你的團隊適應了看板,就應該對你的工作流程中的所有重要步驟進行詳細的橫向對映。
只有這樣,你才能夠精確地發現瓶頸,並通過放置階段/列WIP限制來組織特定步驟的吞吐量,以確保瓶頸不會堵塞(如果無法移除瓶頸或不值得這麼做)。
重點應集中在看板「進行中」部分。
例如,將開發過程的每個重要步驟分解為幾個較小的步驟。
可以將技術設計步驟分成四個不同的列:
- 技術設計
- 準備好設計評審
- 技術設計評審
- 準備好編碼
下一步,將實際的開發分解成另外四列:
- 編碼
- 測試
- 準備好程式碼評審
- 程式碼評審
你甚至可以將軟件開發的最後一步(部署)分解成多個步驟,如:
- 準備進入生產環境測試
- 進行生產環境測試
我們可以清楚地看到,這樣的看板佈局為我們提供了關於團隊任務狀態的更多資訊。你正在尋找穩定的工作流程和增加團隊完成的任務數量,所以可以儘可能多地嘗試使用看板的列。
優化你的泳道
看板泳道的主要功能是組合相似的卡片。因此,只有當看板能夠讓任務以一種非常穩定且快速的方式向最終交付目標前進時,才能稱得上是充分利用了看板的優勢。
所以在這個階段,我們不應該猶豫去打破典型的看板限制,並通過在每個泳道上放置特定列來推進看板工作流程。
讓我們將其付諸實踐。如果回到軟件開發看板,我們可以很容易看到之前提到的幾個列被完美地對映到一個新的泳道中。
但是,在這個看板中,有一些任務是處理客戶問題和修復錯誤。它們需要更多的靈活性,而且在大多數情況下,每一個都要經過10個步驟,這是沒有必要的。
在已部署功能遇到問題時,通常會直接從編碼階段啟動卡片。問題解決後,需要進行快速評審,以確定卡片上所寫的內容是否可行,然後直接進入部署階段。
在這種情況下,我們可以合併技術設計、編碼和測試。為此,我們建立了這些泳道,用於問題修復,這樣就變得更加靈活。
我們甚至可以考慮跨泳道進行垂直列合併。對於依賴相同人員進行所有泳道卡片評審的團隊來說,這是一個完美的方案。如果進行橫跨泳道的垂直合併程式碼評審列,則提交評審的所有卡片都將顯示在看板的頂部。
這樣就可以保留所有等待評審的卡片,並讓責任利益相關方更容易在適當的時間處理它們。我們甚至可以將一個單獨的WIP限制放置在待評審狀態,並在達到限制後立即進行批量評審。
即使對於高階的看板實踐者來說,合併列仍然是在不增加看板複雜度的情況下實現靈活看板結構的最佳方法。在考慮每個泳道的工作流程步驟時,應該牢記這一點。
是的,你可以將團隊所有的工作流程對映到單個看板上,並且每個泳道的步驟完全不同,但是這樣更容易造成混亂。
總而言之,看板乍一看起來很簡單。掌握看板方法並充分利用看板的優勢需要進行大量的練習和實驗。從三列看板到靈活的工作流程設計可能需要幾個月的時間。
不要因此而灰心,持續改進並逐步推進你的看板工作流程。
關於作者
Alex Novkov 是 看板軟體 開發公司Kanbanize的內容負責人。他是一個經驗豐富的看板實踐者,致力於幫助全世界人們提高工作效率。
檢視英文原文: Kanban Step-by-Step Guide: from 3-Columns to Flexible Board Design