现代软件工程讲义4 Scrum/Sprint
Advanced Software Engineering, Development Process, Scrum/Sprint
?
軟件開發的流程有很多 (看 各種方法論概述), 我也寫過一篇博客 (酒后的敏捷) 談了談最近比較時髦的開發流程。 今天我們不喝酒, 正襟危坐地說說敏捷這一路 Scrum/Sprint 開發方法.
從理論上看, 這個方法真是妙得緊:
[圖片來源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]
微軟 MSDN 也有類似的流程介紹，看起來真是太容易了:?
?
?
第一步: 找出完成產品需要做的事情 – 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:
?
(Sprint 進行中)
?
(sprint 最后)
?
注解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 的補充:
?
第四步:
得到了一個增量的軟件發布, 當然好, 但是誰來驗證這個增量滿足了事先的計劃呢?? 如果程序員們在沖刺的過程中發現了新問題, 改進了原來的計劃, 這是好事呢還是壞事?
每一次沖刺結束后, 大家要放松一下, 總結上一次的經驗教訓，爭取下一次做得更好。 這個博客記錄了微軟學術搜索項目組 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) 也很相似:
圖片來源: Rapid Development (1996), Chapter 7, “Lifecycle Planning” (p. 133)
?
Scrum 的團隊
Scrum對團隊的要求很簡單：self-managing， self-organizing， cross-functional， 但是這很難做到。軟件項目的團隊各式各樣 (各種團隊類型的介紹)， 假設一個團隊做得還不錯，現在要變成 Scrum 流程, 那團隊要做下么的改變:
如果你的團隊很弱, 那么強行把Scrum （或者其它高級方法）套在上面也沒有用, 也許還會適得其反，往往需要多次Sprint 才能讓Scrum 走上正軌。換句話說, 如果你的團隊已經是這么厲害 （self-managing, self-organizing, cross-functional）的一幫人, 那么用不用Scrum 都能寫好軟件!
?
經驗:
這里有一些實踐者的經驗教訓:
總結:
Sprint/Scrum 對項目的眾多需求采取分而治之的辦法,? 能讓相關人員集中精力, 在一定期限內解決部分問題。
它強調短時間的迭代 (iteration)， 在多次迭代中不斷總結, 改進團隊的流程和產品功能。
它明確地指出不同人在一個項目中的投入和責任的不同 (豬和雞), 并堅持讓全身心投入的“豬”來主導項目。
它通過 daily scrum, ScrumMaster 等方法和角色，鼓勵團隊內部交流并優化團隊和其他人員的交流方式。
它對團隊成員提出了很高的要求, self-managing， self-organizing， cross-functional。 一般人不能馬上做到這一點。
它不是 “銀彈”，不能解決軟件開發的所有問題，至于具體項目進度如何跟蹤, 如何管理測試工作， 如何管理復雜項目, 還要靠戰斗在一線的團隊成員見招拆招，想出合適的辦法。
SCRUM?視頻: Scrum 看似容易, 門道挺多,?這里是一個視頻系列，大家可以觀賞:? http://blogs.collab.net/agile/scrum-training-series? ?
思考題:
在一個沖刺中, 團隊預計每天的進度為 30 小時。當項目完成了一半的工作量的時候, 大家發現實際的進度為15小時/天,? 問: 在余下的時間中, 團隊的進度要到多少, 才能在項目結束時讓整個項目的平均進度恢復到每天30 小時?
?
?
總結
以上是生活随笔為你收集整理的现代软件工程讲义4 Scrum/Sprint的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 大叔手记（10）：别再让面试官问你单例
- 下一篇： 突破安全狗防注入及上传的一些思路