《Agile Project Management with Kanban》心得：關於五個看板常見問題的想法
對於看板方法在實務的應用，我心中一直有幾個問題沒有獲得適當的解答。當我在閱讀這本書的過程中，不斷透過文字與作者對話。與作者的對話過程中，我有一些啟發與想法。這篇文章主要分享五個困惑我的問題，以及作者對於這些問題的想法與答案。
如何設計合理的 WIP Limit?
在工作流程中的每個步驟設定 WIP Limit 是看板方法中很重要的一個實踐，但是如何設計合理的 WIP Limit 是我一直感到困惑的地方，在《Agile Project Management with Kanban》中，我找到了一些答案。
我們以這個團隊的工作流程為例子，每個工作項目都會經過三個階段，分別是 Specify、Implement、Validate。Specify 主要在做需求討論、系統分析與設計、將需求拆解成多個尺寸差不多大小的工作項目，由系統分析師（analyst）負責；Implement 主要為開發的工作，由開發人員（developer）負責；Validate 主要為驗證工作，由測試人員（tester）負責。
那我們要怎麼知道每個步驟的 WIP Limit 設定成多少是合適的呢？
根據過去團隊成員的完成需求的紀錄，我們得知以下這些資訊：
- 系統分析師 1 個月可以完成 6 個工作項目。
- 開發人員 1 個月可以完成 2 個工作項目。
- 測試人員 1 個月可以完成 3 個工作項目。
另外，整個工作流程最慢的步驟是 Implement，所以它是我們的瓶頸。因此，這個步驟的 throughput 就是整個看板系統的 throughput，我們可以圍繞著 Implement 步驟設計出合理的 WIP Limit。
如果團隊中有 3 位開發人員，所以一個月在開發階段可以完成 6 個需求 （2 x 3 = 6）。從這個 throught 為 6 反推，可以得知我們需要 1 位系統分析師 (6 / 6 = 1) 和 2 位測試人員 (6 / 3 = 2)。在最佳的情況下，三個步驟的 WIP Limit 依序為 1、3、2。
但是在實際的運作中，需求的尺寸稍微有些不同，工作的效率也會有些不同，我們希望可以最佳化運用開發人員，避免他們的工作提早做完，導致沒有新工作可以做的狀況。考量到這個變異性，我們將 WIP Limit 加大 50%，當作 WIP Limit 初始值。
有了這個初始值以後，當我們實際使用看板後，根據實際的情況，可以繼續針對 WIP Limit 做微調，找到最適合團隊的設定值。
什麼時候要將步驟拆分成 Doing 和 Done 呢？
設計看板的過程中，我們會根據工作流程切分成多個步驟，例如 Specify、Implement 和 Validate。那麼，每一個步驟需不需要進一步切分成 Doing 和 Done 兩個子步驟呢？
乍看之下，每個步驟都分成 Doing 和 Done 子步驟很浪費空間，讓整個看板的版面變得很大。但是實際上，這個切分的動作背後是有很深層的意義的。
我們先假設 Specify 是由系統分析師負責；Implement 是由開發人員負責；Validate 是由驗收人員負責。
在這樣的分工下，如果沒有 Done 子步驟存在，每個人完成工作後，無論下一個步驟是否可以承接更多的工作，我們會把當前步驟中的工作項目往下一個步驟移動。這樣的行為模式是典型的 Push 模式，跟看板系統想達到的 Pull 模式相違背。所以，當步驟與步驟之間，如果是由不同的人交接工作的話，可以在交接處設置一個緩衝區，避免變成 Push 模式。
下一個面對的問題是：如果 Implement 步驟中，Doing 子步驟中有 2 個工作項目，Done 子步驟中有 1 個工作項目。那麼，在 Implement 步驟中有幾個工作項目是需要計算到 WIP 呢？
因為 Done 子步驟屬於 Implement 步驟中，如果不計算在 WIP 中，那意味著我們可以堆積大量的工作項目在 Done 子步驟，等於破壞了看板系統的運作機制。因此，無論需求是停留在 Doing 或 Done 子步驟，一率都需要計算到 WIP 中。
最後，分成 Doing 和 Done 子步驟的好處是，可以在步驟的下方加入 Done Rule，也就是這個工作項目從 Doing 進入到 Done 需要滿足的完成條件。當我們明確設置 Done 子步驟，自然地提醒大家確認是否滿足 Done Rule。
所以，設置 Doing 和 Done 子步驟可以確保我們的系統是一種拉式系統。工作項目在拉動的過程中，唯有下游步驟有能力時，才能將工作項目往後移動。
什麼時候將需求拆解成工作項目呢？
團隊會從各種來源收集到許多不同的需求，有些需求的顆粒度比較大，那麼，看板可以怎麼設計，幫助我們有個明確的步驟把需求做切分呢？
步驟 Specify，有些團隊習慣稱為 Breakdown。在這個步驟中，系統分析師會針對這個需求做分析與設計，並且將顆粒度比較大的需求進行拆分，變成許多小的工作項目。
在第一張圖中，Specify 的 Doing 下面有一個需求，在 Done 下面有排成一列的四個工作項目。在第二張圖中，Specify 的 Doing 下面的需求被拆分了，變成在 Done 下面第二列的 3 個工作項目。
所以，我們很巧妙的把拆分這件事情融入到看板的 Specify 步驟中。
另外，可以注意 WIP 的設計，在 Specify 步驟中是計算「需求」的數量，在其他的步驟，例如 Implemet 和 Validate 步驟中是計算「工作項目」的數量。因此 WIP 的設計其實是可以很彈性的，根據實際的工作流程做調整。
在 Specify 步驟中將需求做拆分的概念在實體看板是很容易實現的，但是在數位看板中，例如 Jira、Azure DevOps，同一個看板中，都是要用同樣層級的工作項目表示。因此，要套用這個概念，可能需要搭配兩個上層和下層看板才能實現。
每個需求都要拆解成一樣大小的工作項目嗎？
在看板上流動的工作項目，是否大小都要一致呢？
我們先看反方陣營怎麼說，從使用者收集到的需求通常會有自然顆粒度，可以交付給使用者價值。如果為了追求把需求都拆解成一樣大小的工作項目，這些獨立的工作項目未必對使用者有價值。
接著我們看正方陣營怎麼說，從使用者收集到的需求通常顆粒度有大有小，如果這些需求不經過適當的切分，我們其實很難設計看板步驟上的 WIP，因為顆粒度大的也算一個，顆粒度小的也算一個。
那我自己怎麼想的呢？我認為需求都應該做適度的切分，讓每個需求都能夠在 1–2 個月內完成。
當我們將需求做初步拆解後，進入到看板的需求，依舊需要做進一步拆分，我們沒有強調每一個工作項目都要一樣的大小，只要他們的大小接近即可，例如每一個工作項目都可以在 1–5 天內完成。
拆解成同樣級距的工作項目時，對於看板的設計會更加簡單，比較容易可以推測每個步驟合理的 WIP Limit。
如果工作項目有依賴性必須要等待，該怎麼處理？
想像一個場景，工作項目正在實作中，但是因為依賴性，需要等待其他團隊的協助。那麼，這個工作項目是否要計算進 WIP 呢？
這個工作項目實際上是處於等待的狀態，如果為了符合 WIP Limit 的原則，會導致開發人員可能手上沒更多工作，也無法承接更多的新工作，導致看板在 Implement 步驟呈現阻塞的狀態。
在這個例子中，我們在 Implement 步驟下設置了 Track，當在 Doing 下的工作項目進入了等待狀態，通常是只要等待個三天五天，我們會主動把這個工作項目移動到 Track 下面。只要是在 Track 中面的工作項目不需要計算進 WIP。
放在 Track 下的另一個目的是，這些工作項目依舊在我們的追蹤雷達中，每天 daily standup 時可以拿出來關心一下狀況，看看是否有變化。如果依賴性消除以後，記得移動回 Doing 下面。
有時候，如果發現這個工作項目即使放到 Track 下面，短期內也不會有進展，我們可以設計一個區域稱為「Parking Lot」(停車場)，把這些會等待很久的工作項目放進停車場中，每幾個禮拜回頭檢視這些項目的狀態。
簡單來說，暫時進入等待的工作項目放進 Track 中，密切關注；較長時間會等待的項目放進 Parking Lot 中。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
