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 
補充一下之前看過的東西，不過也很久了，年代久遠，如果出錯就請多見諒囉
1. 透過Scrum，短時程的特性，可以快速的看到成品，如果有些方向錯誤，就可以快速修正。這優點在UI的改動上更是明顯，可以避免全部都做完了以後才發現做的跟需要的根本是兩回事。 有人或許會懷疑，需求不是應該再做之前就盡量搞清楚，然而在實際的生活中，需求其實是很難講清楚的，就算要說明清楚也會花很多的時間；有有時候客人的需求會隨著看到的成品而有所變動，這都是這種互動式開發流程的優點。
2. Scrum在每個回合中是不允許增加任何新的task，也就是即使Project manager受到壓力得去pull-in schedule的時候，也沒辦法突然把task交派下去，而中斷原本計畫的工作。這點在RD的身上可以比較清楚感受到，常常為了要解決臨時交代的任務，就得把現在正在進行的工作中斷下來，而之後又回復回來，這些resource的浪費都是在無形之間。
3. Scrum master通常不會是Project manager，因為Project manager會受到Project schedule以及上級上司的壓力，而增加更多的task，甚至臨時在scrum中途插入task；而Scrum master的腳色，則是要維持Scrum微持原本節奏繼續進行的可能性，避免類似的問題發生。
4. Daily scrum meeting取代冗長的大拜拜式的會議
其實在目前工作的經驗，還沒有看過這種開發流程，畢竟對於一個無法知道最後產品MP時間，對於主管來說還是會覺得非常的恐怖。 因此，實務上要如何解決這類Manager的問題，可能才是比較大的問題。
ps. 我是Ryan Chou from Realtek，很喜歡你的blog，所以也都有在暗暗的潛水，突然浮上水面，還請多見諒
好久不見！非常感謝您的補充, 希望以後有機會多多交流.