Scrum 這個名詞我高一的時候就聽過, 不過當時的用法是在打橄欖球. 為了發揚 "建橄" 的精神, 學長 "無差別" 地鼓吹瘦弱的我們上場拼搏, 聽到 "scrum" 就知道要爭球啦! 喔, 扯遠了, 這次我講的 scrum 是另外一套東西, 它指的是一種軟體開發的流程, 以及管理的方法. 我們先跳過名詞的定義, 直接看看怎麼開工.
既然是一個 project, 當然要先 kick off. 此時計畫的負責人是 PO (project owner) 或是 PM (product manager). PM 負責聽取客戶或是老闆的產品概念 (或稱之為 vision), 然號把產品的性質搞清楚, 寫成需求清單 (requirement list) 或者稱之為 product backlog. 接著由工程團隊的 project manager (或者稱之為 scrum master) 來帶領團隊.
Scrum Master 把 product backlog 裡面的 use case (或者稱之為 story) 整理為 sprint backlog (衝刺清單). 為何已經有了 product backlog 還需要有 sprint backlog 呢? 因為 sprint backlog 是以 sprint 為單位來執行的. 一個 sprint 可能是一週兩週三週或四週之類的 (OS: 如果寫成 "若一週若二週若三週若四週", 感覺像是在抄襲 "阿彌陀經"), 每個 sprint 自成一個單元, 每個單元都會檢討, 而不是來個期中報告, 和一個期末報告就結案了那麼簡單.
Sprint 要做什麼呢? 當然還是完成那些 story, 只不過我們需要把 story 再細分成 task, 每個 task 可能包括寫測試程式, 寫 UI, 設計 data structure 等等. 既然已經以 sprint 為單位了, sprint 就會有自己的 sprint planning meeting. 並且把這些待執行的 story 依據重要程度來執行. Sprint 結束的時候, 難免會需要檢討, 此時也會有一個 sprint review meeting. 既然要 meeting 就要有 agenda, 開完會要有報告, 因此 sprint review agenda 和 sprint summary report 就是少不了的文件.
嗯, 講到這裡不就是把大事切小, 小事切無? 類似 waterfall 的開發理念都是老套了, RUP (Rational Unified Process) 曾領一代風騷, scrum 有什麼特別了不起的呢? 關於這個問題, 由於我只是在今天回家後匆匆翻了 50 頁書, 所以很難完整回答, 就先順便補充一下實務上的特色吧!
1. 雙回饋系統: 除了 review meeting, 還有自省會議 (retrospective meeting). 後面這個會的用意專門討論開發流程如何善. 具有自我監督與改善的意義. 否則方法錯了, 再拼也沒有用.
2. 每日站立會議 (daily scrum): 這是更微型的小會議, 只關心昨天做了什麼? 今天要做什麼? 有沒有遇到什麼問題? 因為目標微型化了, 所以每次改動也不致影響深遠, 很快就可以換個手段, 甚至調整短程目標.
3. 永遠可執行的軟體: sprint 結束時, 馬上就產生一份潛在可發佈的軟體, 並且可以 demo. 如果每個團隊都能保持軟體持續健康長大, 這樣聽起來挺不錯的.
[註1] 以上參考 "笑談軟體工程 – 敏捷開發法的逆襲" page 1~52.
[註2] http://en.wikipedia.org/wiki/Scrum_(development)
Cash Chou's Blog 