敏捷式軟體開發 (Agile Software Development)模型–SCRUM

(轉)敏捷式軟體開發 (Agile Software Development)模型--SCRUM 一 什麼是Scrum?

Scrum (英式橄欖球爭球隊) 軟體開發模型是敏捷開發的一種，在最近的一兩年內逐漸流行起來。

Scrum的基本假設是：

開發軟體就像開發新產品，無法一開始就能定義軟體產品最終的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功。Scrum 將軟體Team Dev比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，確保每天、每個階段都朝向目標有明確的推進。

Scrum 開發流程通常以 30 天(或者更短的一段時間)為一個階段，由客戶提供新產品的需求規格開始，Team Dev與客戶於每一個階段開始時挑選該完成的規格部分，Team Dev必須儘力於 30 天后交付成果，團隊每天用 15 分鐘開會檢查每個成員的進度與計劃，瞭解所遭遇的困難並設法排除。

二 Scrum較傳統開發模型的優點

Scrum模型的一個顯著特點就是響應變化，它能夠儘快地響應變化。下面的圖片使用傳統的軟體開發模型(瀑布模型、螺旋模型或迭代模型)。隨著系統因素（內部和外部因素）的複雜度增加，項目成功的可能性就迅速降低。

是Scrum模型和傳統模型的對比：
       

三 Scrum模型

一)  有關Scrum的幾個名詞

backlog: 可以預知的所有任務， 包括功能性的和非功能性的所有任務。

sprint:一次跌代開發的時間周期，一般最多以30天為一個周期.在這段時間內，Team Dev需要完成一個制定的backlog,並且最終成果是一個增量的，可以交付的產品。

sprint backlog:一個sprint周期內所需要完成的任務。

scrumMaster: 負責監督整個Scrum進程，修訂計劃的一個團隊成員。

time-box: 一個用於開會時間段。比如每個daily scrum meeting的time-box為15分鐘。

sprint planning meeting: 在啟動每個sprint前召開。一般為一天時間（8小時）。該會議需要制定的任務是：產品Owner和團隊成員將backlog分解成小的功能模組,  決定在即將進行的sprint裡需要完成多少小功能模組，確定好這個Product Backlog的任務優先順序。另外，該會議還需詳細地討論如何能夠按照需求完成這些小功能模組。制定的這些模組的工作量以小時計算。

Daily Scrum meeting：Team Dev成員召開，一般為15分鐘。每個開發成員需要向ScrumMaster彙報三個項目：今天完成了什嗎？　是否遇到了障礙？　即將要做什嗎？通過該會議，團隊成員可以相互瞭解項目進度。

Sprint review meeting：在每個Sprint結束後，這個Team將這個Sprint的工作成果示範給Product Owner和其他相關的人員。一般該會議為４小時。

Sprint retrospective meeting：對剛結束的Sprint進行總結。會議的參與人員為團隊開發的內部人員。一般該會議為３小時。

二）實施Scrum的過程簡單介紹

1) 將整個產品的backlog分解成Sprint Backlog,這個Sprint Backlog是按照目前的人力物力條件可以完成的。
2) 召開sprint planning meeting，劃分，確定這個Sprint內需要完成的任務，標註任務的優先順序並分配給每個成員。注意這裡的任務是以小時計算的，並不是按人天計算。
3) 進入sprint開發週期，在這個周期內，每天需要召開Daily Scrum meeting。
4) 整個sprint周期結束，召開Sprint review meeting，將成果示範給Product Owner.
5) 團隊成員最後召開Sprint retrospective meeting，總結問題和經驗。
6) 這樣周而復始，按照同樣的步驟進行下一次Sprint.

整個過程如所示：

敏捷開發中常見的九大誤解

敏捷不是一個過程，是一類過程的統稱，它們有一個共性，就是符合敏捷價值觀，遵循敏捷的原則。

敏捷的價值觀如下：

個體和互動 勝過 過程和工具

可以工作的軟體 勝過 面面俱到的文檔

客戶合作 勝過 合約談判

響應變化 勝過 遵循計劃

由價值觀引出的12條敏捷原則：

1、我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。
2、即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
3、經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
4、在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
5、圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
6、在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
7、工作的軟體是首要的進度度量標準。
8、敏捷過程提倡可持續的開發速度。責任人、開發人員和使用者應該能夠保持一個長期的、恒定的開發速度。
9、不斷地關注優秀的技能和好的設計會增強敏捷能力。
10、簡單——使未完成的工作最大化的藝術——是根本的。
11、最好的構架、需求和設計出自於自組織的團隊。
12、每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

建立敏捷同盟17位大師所創立的敏捷方法包括：極限編程，Scrum，特徵驅動開發，動態系統開發方法，自適應軟體開發，水晶方法，實用編程方法。這些方法統稱為敏捷方法。

其實每個人都可以從敏捷宣言和原則出發，明確問題，找出一些解決方案，形成自己的過程。我覺得國內的軟體環境這麼複雜，程式員的自主精神又這麼強，敏捷方法應該是在中國首先提出才對，只是國人都有唯標準唯規範至上的心理定式，即使找出好辦法，也覺得不規範，沒有深入形成理論，無法提升高度，始終是跟著鬼子屁股後面走，我想這也是國外軟體行業不成熟的表現之一吧！

二、敏捷僅僅是一個軟體過程

如果僅僅從軟體過程的角度去認識敏捷實施敏捷，效果不會太好。敏捷相對以前的軟體工程最大的革新之處在於把人的作用提高到了過程至上，正如敏捷宣言的第一條“個體和互動勝過過程和工具”所說的。

涉及到人的問題，就已經不再是過程所能覆蓋的了，就到了企業管理的層面上了，包括企業的價值觀和文化。這也是敏捷在國內實施的最大障礙：

1、把客戶當作夥伴而不是對手，從客戶角度出發去想問題，充分的跟客戶溝通，而不是出了問題推諉責任。目標是讓軟體實現客戶的價值，而不是收錢就完事兒。
2、把人的能動性調動起來，給動力而不是給壓力。
3、要實用而不是要規範。讓開發人員理解並實施，體驗到敏捷的好處，而不是盲目機械地實施規範。

沒有絕對的權威，每個人都有可取之處。

三、迭代就是敏捷，UP屬于敏捷

看到這麼多人都把UP歸入敏捷，我都開始懷疑是不是自己搞錯了。但是在我的印象中：

UP是重型的過程，雖然引入了迭代，但是其原則和價值觀與敏捷是不同的。敏捷注重的是反饋，迭代周期盡量的短，重在客戶的參與，通過客戶的參與，擷取持續的反饋，不斷調整使整個項目走在正確的方向上。同時也給客戶一個感受和思考的機會，因為對於大多數客戶而言，目標是明確的（不排除有些客戶目標也不明確），但是具體怎麼做，開始時是沒有想法的，只有看到具體的東西的時候，才知道“噢，原來可以這樣，那我想把這裡調整一下”。

四、敏捷是徹底革命的

敏捷，特別是XP，讓人有耳目一新的感覺，覺得以前的所有軟體工程理論，設計方法都可以拋棄掉了，推翻一切，從頭再來。抱著這種想法實施敏捷，那就錯了，敏捷不是“石頭裡蹦出個孫大聖”，以前的軟體過程中也有敏捷的影子，只是沒有像敏捷一樣上升到價值觀和原則的高度，比如快速原型法。敏捷是在對已有的軟體過程方法的改進，拋棄的是傳統軟體工程低效的外表，以往的軟體過程中很多技巧都是很實用的。實施敏捷應該以現有的軟體過程為基礎，從敏捷宣言和原則出發，利用敏捷的方法來改善過程。

五、敏捷是反文檔的

文檔只是為了達成目標的一種手段，如果這種手段是低效的，那就換一種手段。可是完全拋棄了文檔，怎樣解決溝通的問題？難道你想每次溝通都完全用手比劃，用嘴說，跟不同的人重複表格述同樣的想法，那樣更是低效的。

應該清楚文檔的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價（特別是更新同步文檔的代價）。

因此，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。

文檔不是目的，有效溝通才是目的。

六、為了敏捷而敏捷

“嗯，敏捷這麼好，我們也敏捷吧”，可能很多人會有這種想法。忘了以前是在哪兒看的大師採訪錄：

Q：“我們現有的過程很好，不知道怎麼用敏捷改進？”

A：“既然很好，那就不要用敏捷”。

做什麼事情都要有明確目標的，敏捷雖好，得看你需不需要，能不能解決你現在頭疼的問題，如果不是，那就不要給自己找麻煩了。

七、敏捷是CMM的反義詞

在一些討論中，很多人把CMM作為敏捷的反義詞，我覺得這不是很合適。CMM只是一種衡量軟體成熟度等級的標準，並非過程，和敏捷不是一類概念。如果要給敏捷找一個反義詞，我覺得傳統的瀑布式開發應該更合適一些。

並且，我認為，如果CMM還能繼續流行下去的話，應該會有公司可以用敏捷改善的過程通過CMM認證。

八、敏捷是自由的，無約束的

敏捷強調的是自組織團隊，發揮人的能動性，以動力代替壓力，讓人有絕對自由的錯覺。但是應該清楚，凡是都是要講究一個平衡，人也是兩面的，消極的一面和積極的一面同時並存，絕對的自由會放縱人消極的一面。敏捷並非是絕對自由，無約束的。作為管理者，有一個職責，就是引導團隊成員用自己積極的一面去壓制消極的一面，不能放任團隊中出現搭便車的現象，否則將打擊整個團隊計程車氣。如果實在無效，那就只能將其排除出團隊了，這個懲罰夠有約束力吧？

九、重做就是重構

重做不等於重構，很多場合這兩個概念是混淆的。但是在敏捷中，重構的一個特徵是必須可控的。當對系統結構進行大的調整時，如果沒有測試驅動輔助的話，那麼可控性就會很差，這不能叫做重構。