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

 

IC591757  

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

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

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()