之前提到公司內 QA 團隊在執行 Scrum 的困難, 因此打算開始做些修改執行的方式, 試著採用看板的方法.
首先, 針對要處理的事情, 我們歸納出有以下幾類
(1) 功能測試
a. 一般常見的功能測試工作. 這裡是針對新版本所要新增的功能
b. 我們目前的處理流程如下:
Analysis -> TCC (Test Case Creation) -> TCR (Test Case Review) -> TCE (Test Case Execution) -> Verification -> done
(2) 非功能性測試項目
a. QA 有些大型的測試工作, 像是效能測試, HA 驗證. 這些需要詳細規畫, 並且以小型專案方式處理
b. 我們目前的處理流程如下:
Plan -> Review -> Execution -> Done
(3) 自動化開發工作
a. QA 會需要進行自動化測試, 或是開發大型 benchmark 系統. 這時候便像是在開發小型系統
b. 我們目前的處理流程如下:
Analysis -> Design -> Coding -> testing -> Production -> done
(4) 臨時交辦事項
a. 有些事情並不需要詳細計畫, 只需要及時處理, 或者有處理即可. 便可歸到此類.
b. 我們目前的處理流程如下:
To Do -> In Prog -> Done:
目前還無法判對這四類型, 是否有辦法應付所有的工作. 需要一段時候才能確證. 但是就先把手頭上能想到的先列出來, 並且保留原先執行的狀況, 並不刻意改進工作流程.
進行方式
1. 由經理或是 team lead 先把所有工作項目放到 backlog queue, 並且記錄以下資訊
- 工作的 priority
- 工作的 ID
- submit date
- 工作的名稱
- owner
- 適用哪一類型的工作流程
2. Team member 從 backlog 中拿出工作來執行, 放到某個工作流程的第一個欄位, 並且填入開始工作日期到工作的便利貼上
3. 隨著處理狀況, 將工作的便利貼在流程中的欄位移動
4. 當工作移到 done 欄位, 填入完成日期到便利貼上面.
對於 team member 來說, 並沒有特別麻煩. 他們只需要從 backlog queue拿工作來處理, 並且填下開始工作日期和工作完成日期.
對於經理和 team lead, 他們有了這些資訊和便可以查看工作狀態, 並且計算 lead time 和 cycle time, 並且觀察一陣子後, 並可以開始限定 WIP 以及每種流程工作量的比例.
希望這樣的修改, 可以讓我們對於專案的狀況, 能夠掌握度更高.
全站熱搜
留言列表
