第七章 定義什麼叫做做完” 

摘錄至
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. 

當我們訂完做完的定義後
, 讓團隊合作的程度增加. 因為之前成員只著重在他們自己的工作, 並沒有考慮到整體的情況. 現在為了要滿足這些做完的定義, 他們必須要一起合作, 才能真的快速交付品質良好的功能.

 

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(4) 人氣()