當公司內分工化精緻時, 因為不容易形成跨功能小組, 要執行 scrum 會有許多困難.
以下是 QA 團隊常遇到的scenario:
1. 無法有固定的iteration
每個user story 會展開許多 tasks, 可是很多 task 都要依靠 RD 執行的狀況, 像是test case execution 就是等 RD 實作完畢, 因此甚麼時候可以開始, 真的是無法掌握. 此外甚麼時候可以執行完也是很難說, 因為這要看程式的品質有多好, 太差的便要執行很久.
2. Task board 無法進一步反映真實狀況
因為每個 task 在"In prog" 待的時間無法確定, 自然就累積越來越多. 因此 task board上便無法反映更細節的狀況, 只知道有很多東西在進行中.
3. 很難以相同流程處理不同類型的事情
QA 除了要進行測試外, 也需要進行一些開發工作, 像是測試程式, 或是 brenchmark 系統. 有時候還有些臨時交辦的事項, 像是安裝 demo 系統, 或者幫忙找出客戶的問題等等. 不同工作可能有不同處理方式, Scrum 的"To Do", "In Prog" 和 "Done" 似乎把事情太簡化了. 會變成所有事都在In prog 內.
4. 不容易追蹤
要畫個 burndown chart, 要計算一堆task, 要花不少精力. 此外, 在 daily standup 時, 要一一看過這些 task, 也是件崩潰的事情.
所以啦, 看起來 Scrum 若是對於非開發部分, 似乎不見得那麼好用, 有需要做些調整. 當然你會問說那為什麼 QA 不跟 RD 合成一個團隊呢? 有時候組織和 mindeset 因素, 不一定是孤臣可以回天的. 改天試試看 Kanban, 是否有比較好用.
全站熱搜
留言列表
