從理論上看, 這個方法真是妙得緊:

微軟 MSDN 也有類似的流程介紹，看起來真是太容易了: Scrum

第一步: 找出完成產品需要做的事情 – Product Backlog, Backlog 翻譯成“積壓的工作”, “待解決的問題”, “產品訂單”都可以。

產品負責人主導大家對於這個Backlog 進行 增/刪/改 的工作。每一項的時間估計的單位為 “天”.

第二步: 決定當前的衝刺需要解決的事情 – Sprint Backlog.

任務被進一步細化了，被分解為以小時為單位。如果一個任務的估計時間太長 (例如 超過16個小時)，那麼它就應該被進一步分解。 衝刺訂單上的任務不會被分派，而是由團隊成員簽名認領他們喜愛的任務。 團隊成員能主導任務的估計和分配, 他們的能動性得到較大的發揮。

第三步: 衝刺 (Sprint). 在衝刺階段, 外部人士不能直接打擾團隊成員。 一切對交流只能通過SCRUM MASTER 來完成。 這一措施較好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改變都留待衝刺結束後再討論。

衝刺期間, 每天要開一個每日例會 (SCRUM Meeting), 團隊成員大多站著開會, 所以又稱每日立會. 大家依次報告:

我昨天做了啥

我今天要做啥

我碰到了哪些問題

每日立會強迫每個人向同伴報告進度, 迫使大家把問題擺在明面上。同時啟動每日構建, 讓大家每天都能看到一個逐漸完善的版本。

用簡明的圖表展現整個專案的進度, 這個圖最好放在大家工作的環境中, 或者每天傳達給各個成員:

圖表可以是燃盡圖 Burn Down Chart (想象我們把一堆 Backlog 的木頭給燒光)。

也可以是簡單的看板圖 Kanban: （把一堆任務從最初的 “待定”推動到“工作中”等各個狀態, 直至“完成”）

這裡有幾個 現代軟體工程 學生小組的 daily scrum 的過程:

2010 年學生，2011年學生專案，2012年學生專案

衝刺階段是時間驅動的 (time-boxed), 時間一到，就結束。這個特點看似不起眼, 其實它有效地給各種延期的想法斷了後路，很高明。

第四步: 得到軟體的一個增量版本，然後在此基礎上又進一步計劃增量的新功能和改進。

美妙的理論在實踐中都會碰到這樣那樣的問題, 下面是一些例子:

第一步:

各個需求和任務之間是有種種複雜的依賴關係的，除了優先順序之外, 我們還要考慮相互的依賴關係。怎樣在計劃中表現依賴關係呢?

第二步:

如果團隊成員對某個任務不感興趣, 都不認領這個任務怎麼辦?

有些成員的認領的任務很多, 有些成員認領的任務很少, 忙閒不均, 怎麼辦?

第三步:

每日例會 (SCRUM Meeting)看起來很爽:

我昨天做了啥

我今天要做啥

我碰到了哪些問題

爽了之後, 也許會流於形式。 我們想象一幫狗熊開Scrum 會議的時候, 大家的發言是:

我昨天掰棒子

我今天繼續掰棒子

我沒碰到困難

這樣的會議有用麼? 也許昨天掰的棒子沒處理, 今天就掰另一個棒子去了, 明天又來一個新棒子…

一群狗熊級的程式設計師會這麼說:

我昨天寫程式碼

我今天繼續寫

我沒碰到困難

每天這麼寫程式碼, 我們離完衝刺的終點線到底是更近了, 還是更遠了? 如果流於形式, 無論多麼敏捷的Scrum 每日立會也會被忽悠, 請看學生們的一個忽悠例子.

一個改進是, 定義好任務究竟是什麼? 任務的完成 (done) 到底意味著什麼? 每個人的任務必須是明確定義的, 狗熊們不能籠統地說, 我在掰棒子, 而是要說明標號為123 的棒子現在是什麼狀態, 你做好之後交給誰了。

另一個改進是, 要在每一個任務中記載我們完成這個任務還需要多少時間。已經花了多少時間雖然重要, 但是不是關鍵 (那是沉沒成本)，關鍵是要看我們離最後目標有多遠。 就像某部門展覽“反腐成果”， 給群眾看 “已經抓出來N 個腐敗分子”固然解恨, 但關鍵還是 ”還剩多少在臺上“，這個問題不說明, 再抓20個, 30個都不解決問題。

衝刺到一半的時候, 產品負責人突然發現要做馬上重要的改動! 或者某個大佬要看某個不在計劃中的功能的演示, 怎麼辦? 這種情況非常考驗 SCRUM MASTER. 如果一個運動員在跑一百米衝刺, 但是跑到一半的時候，領導突然想看一百一十米欄的比賽, 前面馬上會擺起欄架, 大家要準備8步上欄! 怎麼辦?

一個有正常頭腦的運動員和教練員會說: 去你的， 要改主意, 也要等到老子衝刺完了再說啊!

關於每日立會 - 如果團隊成員不在同一個地方, 怎麼開會呢? 我聽到一些敏捷的專家說, 一個團隊的成員必須面對面開會, 才有效果。

Ken Schwaber 說: I also recommended eliminating all of the development artifacts – like design documents… Scrum relies on high-bandwidth, face-to-face communication and teamwork; cubicles and unneeded artifacts promote isolation and misunderstandings. [Agile Project Management With Scrum, Page 103]

如果專案的所有人都坐在一起, 連工位的矮牆都沒有, 那的確很爽, 但是在很多公司中那是不可能的，有些團隊成員甚至在不同的時區工作，怎麼辦? 他們就不能敏捷了?這時候我們的確需要文件和其它輔助手段來溝通。

燃盡圖, 有些燃盡圖只是列出了任務的數目, 這種圖無法展現專案的拖延, 一個任務有大有小, 它們在圖表中都是一個點, 一個16小時的任務需要3 天完成, 一個2小時的任務處於種種原因也花了3天時間, 他們在圖表中的表現是一樣的。 在實踐中, 我個人認為以時間為度量的燃盡圖更有效果.

下面是一個實際專案的燃盡圖, 有三個每天跟蹤的時間值:

實際剩餘時間/remaining hour: 每個團隊成員所有任務的 remaining hour 的總和

預估剩餘時間/projected remaining hour: 根據每個人每天的理論進度推算的剩餘時間

實際花費時間/completed hour:

註解1: sprint 從8/22 到 9/28, 中間9/15 - 9/18 整個團隊外出開整個部門的年會。

註解2: 開始預計所有工作量為340 小時， 每個工作日能減少 (burn) 17 小時。

註解3: 開發人員有 5.5 名, 絕大多數第一次接觸正式商業專案和 SCRUM的團隊開發模式。 最終完成的工作量為524 小時, 是預計的 1.5 倍。（這暴露了什麼問題呢?）

註解4: 有 0.5 名UX 設計人員, 0.5 名PM, 和 2 名測試人員。

註解5: sprint 結束後, 各個任務宣告完成, 並且沒有P1 (最嚴重的) bug，但是P2 及以下的bug 有80 多個, 加上前一個版本遺留下來的70個bug, 總共還有150 個bug 要解決, 才能釋出。

註解6: sprint 結束後, 有兩個原來的設計發現很有問題, 團隊決定在sprint 結束之後進行重新設計，或者叫 Design Change Request (DCR)。

第三步半:

做過專案的人都知道, 當你說“任務都完成了”的時候, 那只是說, 開發人員認為該寫的程式碼都寫完了, 還有很多事情沒做完. 例如寫一個Windows 客戶端的功能， 顯示一個新聞圖片加上和與它相匹配的文字 (假設這些圖片/文字都可以從網際網路上拿到) , 做完之後, 還有下面的事情:

驗證這個功能顯示在WinXP, vista, win7, win2008 server R2, win2012 server 都顯示正確。 (開發人員表示自己的機器是win2008 server, UI 看起來不錯, 其它平臺想必也不錯!)

驗證這個功能的顯示佈局和字型在100% 到150% 的DPI 上都顯示正確, 在各種色彩配置中都顯示正確。

驗證文字無論是中文, 英文, 阿拉伯文都能正確顯示 (聯合國五種工作語言我們得支援吧? )

驗證程式效能上沒有問題

驗證程式在長期使用, 沒有記憶體和資源洩露

驗證這個功能和其它功能有較好的整合

誰來做這第三步半呢? 程式設計師寫完功能的時候, 我們感覺好像專案完成了 80%, 殊不知後面的20% 往往要花費80% 的時間, Sprint/Scrum 沒有明確表明到底 何人/何時/何種優先順序 來完成這個20% 的任務。

長期任務: 軟體專案中常常有一些比較艱難和底層的任務, 完成這些任務需要超過sprint 所計劃的時間, 這時候我們怎麼安排呢? 在我的經驗中, 這些任務往往在短週期的迭代中得不到應有的重視, 一直拖著。

軟體團隊中還有一個重要的角色 - 測試。 測試人員在一個衝刺中怎麼工作呢? 有敏捷專家建議測試人員可以擔負起 Product Owner 的部分責任，同時掌握 Acceptance Test 流程, 對產品的最終質量負責。 但是測試人員的開發技術能力在團隊中並不佔優 (在有些中國公司中甚至是最弱的一環)，他們在大家都要 “燒光”所有任務的壓力下，能擔當起 Product Owner 這一責任麼?

這一篇部落格講了 第三步半要做什麼事情, 它的流程圖可以作為Scrum/Sprint 的補充:

從CC 到釋出

第四步:

得到了一個增量的軟體釋出, 當然好, 但是誰來驗證這個增量滿足了事先的計劃呢? 如果程式設計師們在衝刺的過程中發現了新問題, 改進了原來的計劃, 這是好事呢還是壞事?

每一次衝刺結束後, 大家要放鬆一下, 總結上一次的經驗教訓，爭取下一次做得更好。 這個部落格記錄了微軟學術搜尋專案組 10 次衝刺的過程。

軟體開發流程有好多種, 我們怎麼衡量一個開發流程是否對當前的專案/團隊合適？ 我覺得Scrum/Sprint 能成功實施的關鍵在於 ScrumMaster。我聽到有些團隊也實施Scrum, 但是他們隨機挑一個成員來做 ScrumMaster, 好像 ScrumMaster就是招呼大家開開會, 記錄每個人的進度而已。這種方法失敗的可能性很大。 一個好的ScrumMaster 能在兩種語境 (描述軟體專案的商業語境，描述實現細節的技術語境) 自如地翻譯和切換，事實上是一個強有力的PM，如果團隊還要求她做全職的開發工作，這樣的人就更難找了。

Scrum 很特別麼?

我個人認為它和質量控制理論的模型， 例如 經典的戴明環 PDCA Plan-Do-Check-Act/Adjust 沒什麼太大區別. 正如 Ken Schwaber 在描述Scrum 的核心特點的時候說:

在迭代開始時, 團隊審視擺在他們面前的任務，選擇他們認為可以在迭代期間完成的那些 (Plan)。然後團隊獨立地盡最大努力完成這些任務 （Do）。在迭代結束時, 團隊給利益關係人展示他們的成果 （Check），並對開發流程進行調整 （Act/Adjust）.

在 6西格瑪理論中 ( Six Sigma) ，我們也可以看到相似的流程, 只不過它變成了 “Define, Measure, Analyze, Improve, Control” (DMAIC). 此模型不強調迭代的重要性。

Scrum 和 漸進交付的流程 (Evolutionary Delivery) 也很相似:

Scrum 的團隊

Scrum對團隊的要求很簡單：self-managing， self-organizing， cross-functional， 但是這很難做到。軟體專案的團隊各式各樣 (各種團隊型別的介紹)， 假設一個團隊做得還不錯，現在要變成 Scrum 流程, 那團隊要做下麼的改變:

Self-managing: 以前領導佈置了任務，我們實現就可以了，現在要自己挑選任務；每次sprint 結束之後，還要總結不足，提出改進，並且自己要實施這些改進。“自我管理”不等於“沒有管理”。
Self-organizing: 以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對專案負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。
cross-functional: 以前spec 由PM 來寫, test 由測試人員來做, 現在每個人都全面負責，自己搞定spec, 和別人溝通, 同時自己搞定測試。
如果你的團隊很弱, 那麼強行把Scrum （或者其它高階方法）套在上面也沒有用, 也許還會適得其反，往往需要多次Sprint 才能讓Scrum 走上正軌。換句話說, 如果你的團隊已經是這麼厲害 （self-managing, self-organizing, cross-functional）的一幫人, 那麼用不用Scrum 都能寫好軟體!

經驗:

這裡有一些實踐者的經驗教訓:

ScrumMaster 不是一個官，而是一個沒有行政權力的溝通者，就像微軟的PM 那樣。她同時還要在團隊中做具體的工作。直接把原來的 “經理”變成 ScrumMaster 大多行不通。
在一些公司中，不少專案需要很多暗箱操作和政治角力才能搞定, Scrum 會把這些矛盾都擺到明處。這有好處，也有風險。
在複雜的專案裡，要讓一線團隊成員做決定。
創業公司的團隊其實經常是執行在 Scrum 的模式中 (只不過大家太忙，沒功夫論證到底多麼Scrum)。
在Scrum 計劃階段的估計不是一個“合同”, 領導們不要把它當成一個合同。估計總是不準的。 堅持短期的Sprint，即使不準的估計也不會有大的損害。
不要和管理層談 “流程”, 他們只關心 “結果”。
在大型團隊，複雜專案中，Scrum 並沒有非常完美的答案，Scrum 的創始人也承認這一點。 (我曾看到30多人擠在會議室裡搞 Daily Scrum，一嘆! )
總結:

Sprint/Scrum 對專案的眾多需求採取分而治之的辦法, 能讓相關人員集中精力, 在一定期限內解決部分問題。

它強調短時間的迭代 (iteration)， 在多次迭代中不斷總結, 改進團隊的流程和產品功能。

它明確地指出不同人在一個專案中的投入和責任的不同 (豬和雞), 並堅持讓全身心投入的“豬”來主導專案。

它通過 daily scrum, ScrumMaster 等方法和角色，鼓勵團隊內部交流並優化團隊和其他人員的交流方式。

它對團隊成員提出了很高的要求, self-managing， self-organizing， cross-functional。 一般人不能馬上做到這一點。

它不是 “銀彈”，不能解決軟體開發的所有問題，至於具體專案進度如何跟蹤, 如何管理測試工作， 如何管理複雜專案, 還要靠戰鬥在一線的團隊成員見招拆招，想出合適的辦法。

Scrum工具：leangoo 國內專注于敏捷團隊協作的免費、視覺化、輕量級工具 leangoo.com