David Ko的學習之旅

在 Scrum 中, 我們會用任務版, 將目前的工作狀態視覺化, 好讓我們可以依據其內容, 快速作出判斷和行動.

 

通常我們會包含以下欄位: 
Feature: 這個 iteration 要處理哪些功能
To Do: 這些功能拆解出哪些 task
In Prog: 目前正在處理哪些 task
Done: 哪些 task 已經處理完畢

經過一段時間的執行, 常常會發現到有以下問題
1. 大多集中在 In Prog
在 iteration 的過程中, 你會發現很多 task 都是移到 In Prog, 然後就不動停很久. 雖然每天有standup meeting 可以知道狀況, 但是有時候太多 task, 你無法清楚記得所有項目. 如果 iteration 時間到了, 移到 done 那就好. 如果還停留在 in prog, 這時候就會頭大

2. 太多便利貼任務版上面
像我們團隊, 每個 iteration 大約會做個 7 - 8 的 features, 或者更多. 然後每個 feature, 可能會拆解出 6 - 7 個工作. 這時候任務版上就大約會有 42 - 56 張便利貼. 這時候真的一整個花到不行. 所以很多人就會想要用電子看版, 因為可以進行過濾的動作. 可是用了電子看板後, 更新速度很慢, 資訊不及時, 導致電子看板失效, 進入鬼打牆的狀況....

3. 有問題的無法立即看出來
接著前面的的狀況, 這時候如果你要找哪個是 delay, 哪個是超前, 哪個是被 blocked, 這真的是大海撈針, 常常花個 5 - 10 分鐘來掃描, 這會讓 standup 進行得很慢, 或者是失去效果. 這是可以用一些小的便利貼當作 tag, 來標示某些特定的 state. 可是如果遍地都有問題時, 也容易進入鬼打牆的花花綠綠狀況.

4. 多個團隊負責一個專案
遇到這個狀況時, 大多一定用電子看版,這樣才不會互相干擾, 也可以處理讓大的問題. 這很正常. 但是將像寫程式一樣, 一個函式過胖時, 是不容易維護的, 並且需要被改變的因素增加了, 只要某個團隊想做一些變化時, 別的團隊就會受影響. 即使是電子看板也是不容易處理這樣的狀況.

不知大家還遇到哪些狀況, 那你們怎麼處理呢?