第七章 定義什麼叫做”做完”
摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 7 Defining Ready and Done
在白板中每個欄位的定義很重要, 尤其是對於大型專案. 如果大家越疑惑, 則付出的代價越大.
在我們的專案中, 我們會在某些欄位的最上面, 用藍色的筆寫下這個欄位做完的定義. 尤其我們特別重視”Features”(也就是”Ready for Dev”) 和”Ready for System Test” 這兩個欄位. 因為這兩個欄位, 過去通常有最多的問題.
1. Ready for Dev
它必須有下列以下東西
(1) ID: 用來識別, 以及和其他文件做關聯.
(2) 負責人: 通常是需求分析師, 對這個功能有最多的領域知識
(3) 必須對客戶有價值: 在epic切成user stories時, 要確保它們是有價值的
(4) 必須被團隊所評估: 要有個跨功能的小組(包含開發人員, 測試人員和需求分析師), 藉由playing poker的方式來評估它. 作者使用T-shirt size (大, 中, 小)的方式來進行評估. 以下是簡單的準則
小: 在沒有任何意外狀況下, 大約花一周可以到達 Ready for Acceptance Test的欄位. (所謂沒有任何意外狀況是指我們找對的人, 在沒有打擾的狀況下, 只處理這個功能)
中: 大約一至兩周才能完成.(在沒有任何意外狀況下)
大: 超過兩周才能完成, 需要進一步拆解
(5) 需要有驗收測試的標準: 我們會列出一些test scenario, 來描述系痛完成後會怎麼運作
2. Ready for System Test
開發團隊要交付一個功能給測試團隊, 通常要把想到的狀況實作完, 並且不能有重大的defect.
長久以來, System Test一直是我們的瓶頸, 其中一個主要的原因是在system test階段發現大量不必要的defect. 所謂”不必要的defect”就是應該在放到Ready for System Test之前就應該發現的問題.
因此作者在定義做完的定義時, 會以比較嚴謹的條件來訂定, 讓feature team知道品質不是只是測試團隊的事, 而是所有人的事. 但是也會給他們足夠的時間, 來確保交付feature的品質.
以下是作者他們使用的定義:
(1) Acceptance test要被自動化: 對於end to end 的功能層次的測試或是整合測試(integration test)需要被自動化. 通常我們使用Selenium來實作這樣的自動化. Specification By Example這本書是很好的參考資料.
(2) 回歸測試要通過: 之前存在的自動化測試都要通過, 以避免新功能破壞了原先的功能.
(3) 要展示功能給相關的人看過: 可以讓一些易用性問題早點被提出來.
(4) 清楚的check-in註解: 要有清楚的註解, 並且讓feature ID被標注在裡面, 以提高可追蹤性.
(5) 專屬的測試環境: 每個feature team有專屬的測試環境, 以避免開發人員說這個功能可以在我的機器上運作
(6) 合併程式到trunk: 程式碼要合併到main trunk.
當我們訂完做完的定義後, 讓團隊合作的程度增加. 因為之前成員只著重在他們自己的工作, 並沒有考慮到整體的情況. 現在為了要滿足這些做完的定義, 他們必須要一起合作, 才能真的快速交付品質良好的功能.
留言列表
