在我目前的想法中, Kanban 最主要拿來處理這兩件事情
1. flow 流暢度: 我要確定功能能盡快做完. 如果無法流動很快就會有問題
2. 避免多工: 希望員工不要同時處理很多事情, 最好能一次處理一件事情, 趕快做完後, 在做下一件
這次目標是在處理維護或是概念性驗證的工作. 一開始的時候, 我們是採用 Scrum 的格式來處理這些工作, 並且用 CFD 紀錄的工作的執行時間.
To Do -> In Prog -> Done
在執行了兩周後我們發現了以下問題:
1. 很多工作在 In prog 停很久, 可是我們不清楚發生了甚麼事情
2. 大家手頭上常處理多個工作
- 深入追蹤後, 是目前手頭上能做的事已經結束, 接下來要等其他人回應, 所以才換做另一個工作
3. 沒有規劃到的工作 (noise task)
- 有些工作是其他人請求幫忙, 可能來自相同團隊的同事, 有些可能來自別的國家或區域的支援工程師(support engineer). 這時候是否要記錄到看板中呢?
討論過後, 我們採取以下修正
1. 更詳細的工作流程
submit -> analyze -> request info -> RD fixing -> Doc review -> pack fixing -> verification -> done
submit: 提交新的或是概念性驗證維護工作
Analyze: 測試人員需要分析或呈現這個問題
request info: 通常是要跟支援工程師要更多的資訊, 以方便進一步處理
RD fixing: 等待開發人員修復
Doc review: 等待文件技術人員檢視發佈文件是否正確
pack fixing: 測試人員把這個修復打包起來,
verification: 測試人員驗證最後解法是否可行
這樣我們就可以知道這個 case 處理到那理, 並且是在等誰處理. 如果因為別人在處理, 他便可以接著另外的工作.
對於問題 1 和 2, 我們就可以收集到更清楚的資訊, 繼續觀察兩個禮拜, 或許能有更好的解法出現
2. 紀錄 noise task
現在我們對於這一類的工作, 並沒有太多的資訊, 不清楚是那些種類, 會有怎樣的處理流程. 因此會先要求大家把這類的事情記錄到kanban 中, 之後再做判斷
但是如果全部都要記錄, 那將會是很大的 effort. 因此會處理超過一天的工作, 我們才記錄到看板上面
留言列表
