Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
我們為什麼要使用索引卡?
大部分的sprint規劃會議, 會花很多時間在討論產品backlog中故事的細節. 要去評估它們, 排定優先順序, 釐清它們, 以及進一步分解它們等等.
那我們是怎麼做這些事情呢?
好的, 基本上, 有些團隊是利用投影機, 把excel中的backlog投影在牆上, 然後有一個人(通常是產品負責人或是Scrum master)操作鍵盤, 咭哩咕嚕講解每個故事, 並要求大家進行討論. 當團隊和產品負責人討論過優先順序和故事細節後, 拿著鍵盤的這個人會直接在excel更新討論後的結果
聽起來不錯吧? 好的, 事實上不是這樣的, 大多只是在高談闊論. 更糟的是, 團隊不會注意到在會議結束之前, 他們都只是在高談闊論, 可能連所有故事都沒有看完過一遍.
一個比較有效果的作法, 是去建立一些索引卡, 把他們放到牆壁上(或是一張大桌子上)
和使用電腦或是投影機比較起來, 這個比較好的使用者互動方式, 因為
# 大家必須站起來並四處走動 => 讓大家可以較長時間的保持清醒, 並會留意會議的進行
# 每個人會感覺到有參與感 (而不是只有拿著鍵盤的那個人)
# 有多個故事可以同時被編輯
# 要重新規劃優先順序變得比較容易 - 只要移動索引卡就可以
# 會議結束後, 索引卡可以被拿出會議室, 被放到牆壁上的任務版上 (可參考後面第六章 "我們怎麼撰寫sprint backlog")
你可以手寫索引卡(像我們一樣); 或是利用一些簡單的腳本, 從產品backlog中, 直接來產生可被印出的索引卡.
附註 - 這個腳本在我的blog中可以拿到: http://blog.crisp.se/henrikkniberg.
重要事項: 在sprint規劃會議結束後, 我們的Scrum master會手動更新excel上的產品backlog, 以反映故事索引卡中的任何變化. 是的, 這確實帶給管理者一些麻煩, 但是我們考量在使用索引卡後, 所帶來sprint規劃會議的效率提升, 這樣的做法是完全可以接受的.
這裡有個地方要注意: "重要性"這個欄位. 它和excel中的產品backlog所記錄的重要性是一樣的. 把它放到卡片上, 可以方便我們根據重要性來排序.(一般我們把較重要的項目放在左邊, 比較不重要的放在右邊) 不過, 一旦卡片被放到牆壁上, 我們可以忽略它的重要性評分, 只要注意他在牆壁上在左在右的位置, 來指出它相關的重要性. 如果產品負責人交換某兩個項目的位置, 先不要去更新 excel上的資料, 只要在會議後去更新就可以.
如果把一個故事拆解成更小的任務(task), 那將會更容易評估時間了(也更容易準確).
用索引卡來處理既方便又容易, 你可以把團隊拆成兩個人一組, 讓他們同時拆解各一個故事
實際上, 我們在每個故事下面貼上一張便利貼, 每張便利貼表示故事中的一個任務.
我們不會把拆解出來的任務, 更新到Excel中的產品backlog. 理由有兩個
# 拆解出來的任務
# 產品負責人不需要去知道這種程度的細節
# 任務的拆解通常是比較反覆無常, 也就是說, 在sprint的過程中, 它經常會改變, 會不斷調整, 所以若要保持和excel內的產品backlog同步, 將是一件非常麻煩的事.
拆解出來的任務可以和故事索引卡貼在一起, 在sprint backlog中直接被使用. (參見後面第六章"我們怎麼撰寫sprint backlog")
做完的定義
這一點是非常重要的, 產品負責人和團隊必須同意, 要對"做完"有一致的定義. 是所有程式碼被check-in就算故事做完了嗎? 或是要被放到測試環境, 並被整合測試的團隊驗證過, 才叫做做完嗎? 有可能我們使用這樣的定義: "隨時可以上線", 但有時候我們可能這樣說: "已經部署到測試的機器上, 準備好要做驗收測試"
在最開始的時候, 我們曾使用詳細的的檢查清單. 但現在我們則會說: "如果測試人員說可以了, 那這個故事就是做完了" 然後就由測試人員去確保, 產品負責人所想要的事情, 已經被團隊充分理解, 並且此項目已經"完成"到, 足夠通過大家以認可的做完定義.
我們慢慢瞭解到, 並非所有故事能用相同方法來對待. "查詢用戶表單"和"操作手冊"這兩個故事處理方式就差異很大. 後者, "做完"的定義可能只是被運作團隊接受就可以. 所以有時候用一些常識就可以確認了, 不必用到正式的檢查清單.
如果你經常對"做完"的定義感到困惑(就像我們一開始一樣), 你或許應該在每個故事上, 增加一個的欄位: "做完的定義"
留言列表
