看板初體驗 - 兩層式看板
在執行 kanban 一段時間後, 我們開始對目前工作流程做出調整. 首先第一個問題, 便是改善專案整體進度的能見度.
在我們部門因為分工的緣故, 開發人員和測試人員是屬於不同老闆所管轄. 雖然導入Scrum 已有一段時間, 但是因為組織緣故, 無法把開發人員和測試人員合成一個團隊, 一個老闆.
此外也由於人數眾多, 大約20人左右, 變成一個團隊也是大了點. 若是要變成 feature team, 也因為沒有經過好的訓練和教育, 無法強迫進行.
因此目前雖然開發人員和測試人員, 一起合作開發要交付的功能, 可是卻各自有各自的task board.
RD task board
QA task board
不過在溝通方面, 雖然測試人員有自己的 daily standup, 但是測試人員也會去參加開發人員的daily standp. 因此雙方資訊的同步還算良好.
並且我們還會有 lead level 的 daily standup, 開發人員的 lead, 測試人員的 lead, 和經理們會一起討論目前專案的進度, 以及遭遇到的問題.
但 是總覺得對於所有要交付的功能, 其進度的掌握還是有些不足. 雖然每個 lead 會描述其功能的進度和狀況, 但是講完後還是容易忘記. 因此在下一個 release 開始, 我們打算增加一個project level 的 task board. 會列出目前專案要處理的功能, 以極其目前所在地階段為何.
我們分成了以下階段
1. requirement clarification: RD, QA 和 UI designer 討論需求規格
2. design: RD 在進行 design 和 design review
3. coding: RD 在撰寫程式
4. integration: RD 之間先進行整合測試
5. testing: QA 進行全面性測試
6. verification: RD 改完defect, 交付由 QA 進行 regression
7. done: 此功能已經可以準備交付
希望我們就有兩層式看板. 開發人員和測試人員各自有它們自己的 task board. Project level 也有自己的 task board. 這樣會讓資訊更加通透, 更容易掌握專案的情況
在執行 kanban 一段時間後, 我們開始對目前工作流程做出調整. 首先第一個問題, 便是改善專案整體進度的能見度.
在我們部門因為分工的緣故, 開發人員和測試人員是屬於不同老闆所管轄. 雖然導入Scrum 已有一段時間, 但是因為組織緣故, 無法把開發人員和測試人員合成一個團隊, 一個老闆.
此外也由於人數眾多, 大約20人左右, 變成一個團隊也是大了點. 若是要變成 feature team, 也因為沒有經過好的訓練和教育, 無法強迫進行.
因此目前雖然開發人員和測試人員, 一起合作開發要交付的功能, 可是卻各自有各自的task board.
RD task board
QA task board
不過在溝通方面, 雖然測試人員有自己的 daily standup, 但是測試人員也會去參加開發人員的daily standp. 因此雙方資訊的同步還算良好.
並且我們還會有 lead level 的 daily standup, 開發人員的 lead, 測試人員的 lead, 和經理們會一起討論目前專案的進度, 以及遭遇到的問題.
但 是總覺得對於所有要交付的功能, 其進度的掌握還是有些不足. 雖然每個 lead 會描述其功能的進度和狀況, 但是講完後還是容易忘記. 因此在下一個 release 開始, 我們打算增加一個project level 的 task board. 會列出目前專案要處理的功能, 以極其目前所在地階段為何.
我們分成了以下階段
1. requirement clarification: RD, QA 和 UI designer 討論需求規格
2. design: RD 在進行 design 和 design review
3. coding: RD 在撰寫程式
4. integration: RD 之間先進行整合測試
5. testing: QA 進行全面性測試
6. verification: RD 改完defect, 交付由 QA 進行 regression
7. done: 此功能已經可以準備交付
希望我們就有兩層式看板. 開發人員和測試人員各自有它們自己的 task board. Project level 也有自己的 task board. 這樣會讓資訊更加通透, 更容易掌握專案的情況
全站熱搜
留言列表
