目前因為開發人員(RD)和測試人員(QA)工作流程不同, 彼此做事方法還差很大, 因此一開始時將雙方的工作, 以不同的工作流程來表示:
1. RD 工作流程
Backlog: 需要處理的事情(例如: 需求分析, 設計, 編碼)
Do: 處理這項工作
Check: 檢查這項工作是否做好, 例如 code review, design review, spec review等等
Done: 處理完畢
起初這個工作流程的重點, 是要確定RD 做完之後有進行review 的工作, 以提升產出的品質.
2. QA 工作流程
Backlog
Scope Review
Design Review
Code Review
Test Case Creation
Test Case Review
Test Case Execution
Verification
Done
在執行一段時間之後, 我們發現了一些問題:
1. RD 和 QA 不同步
RD 已經開始處理很多工作, 可是QA 並沒有處理到相對應的地方. 例如有些設計已經review過了. 可是QA 還沒對這個 feature進行 scope review, design review 等等. 可能是 QA 沒有空進行, 也可能是 RD 並沒有通知 QA 來參加.
2. 工作和需求的關聯性不明確, 且便利貼太多
對於每個需求, RD 會把它展開成task, 貼在task board上面. QA 對每個需求只有一張便利貼, 隨著移到不同step, 代表進行到不同工作. 因此 RD 會對每個需求貼了很多工作, 這將導致在工作版上, 很難知道這個功能到底處理得如何了, 或者很難知道哪些工作是跟哪個需求有關.
心得
1. 視覺化的看板, 可以讓你很快看到變化的趨勢. 不過你要有夠大的板子
2. 很多task 會增加管理難度. 不管你是放在task board 或是project file內. 也許可以用以下方法減輕其症狀
a. 屬於某個需求的功能就在同一個 row. 但是 task 數量而是很大.
b. 利用流程的 step 來代表不同階段的工作, 而不是功能拆成一堆不同階段的工作. 不過每個需求的工作拆解需要大致相同, 否則就無法使用.
c. 2 tier task board: 用上層的task board 表示概略的流程步驟, 下層的 task board 來存放工作細項.
3. 如果多個工作流程之間有關連性, 目前似乎還無法有好的解法去同步其關聯性. 這部分還需要進一步研究
4. 在專案初期, 工作流程頻繁變動修改是很正常. 所以放到 tool 似乎不是重點, 而是要能快速調整.
留言列表
