敏捷式軟體開發 (Agile Software Development)模型Scrum通俗講義

文章目錄

• 前言
• 一、什麼是敏捷開發
• 二、Scrum

前言

     之前或多或少都聽過說有關敏捷開發模型的諸多東西，包括什麼有它相關的書籍或培訓。由於公司現在所採用的是Scrum開發流程--敏捷開發的一種，所以，特此作番學習與研究，我也力求文字通俗易懂，已不致讓大家對它產生如參加會議一般的厭倦情緒。

一、什麼是敏捷開發

    敏捷式軟體開發 (Agile Software Development)又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程式員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。

    在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如反覆式開發法，關注互動溝通，減少中介過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織圖的角度看，組織圖的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：

• 組織文化必須支援談判
• 人員彼此信任
• 人少但是精幹
• 開發人員所作決定得到認可
• 環境設施滿足成員間快速溝通之需要

    最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，20、40人或者更少。大規模的敏捷式軟體開發 (Agile Software Development)尚處於積極研究的領域。

    另外的問題是項目初期的大量假定或者快速收集需求可能導致項目走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將項目目標和設計引入錯誤方向的境況。開發人員經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。雖然理論上快速互動的過程可以限制這些錯誤的發生，但前提是有效及時反饋，否則錯誤會迅速膨脹。

目前列入敏捷方法的有：

• 軟體開發節奏，Software Development Rhythms
• 敏捷資料庫技術，AD/Agile Database Techniques
• 敏捷建模，AM/Agile Modeling
• 自適應軟體開發，ASD/Adaptive Software Development
• 水晶方法，Crystal
• 特性驅動開發，FDD/Feature Driven Development
• 動態系統開發方法，DSDM/Dynamic Systems Development Method
• 精益軟體開發，Lean Software Development
• AUP（Agile Unified Process）
• Scrum（本文的主角）
• XBreed
• 極限編程，XP Extreme Programming
• 探索性測試

然後，請允許我引用鄒欣老師的一篇部落格有關敏捷的兩張圖片，如下：

問: 愛腳兒 - 敏捷到底是什麼東東? 好像有很多名詞, 縮寫和傳說…

答: 敏捷 (Agile) 是一股思潮, 它包括了好幾種軟體開發的方法論 (methodology); 這些方法論又是建立在許多業界證明行之有效最佳實務方法 (best practices) 上面的。 如所示:

    ok，開頭說了，由於目前公司採用的是Scrum開發流程，所以對Scrum作番學習和瞭解也是我的工作任務。所以，接下來，咱們來分析上述敏捷方法中的Scrum開發方法。

二、Scrum

    2.1、什麼是Scrum       

    Scrum是一個輕量級的軟體開發方法，它是一個敏捷開發架構，是一個增量的、迭代的開發過程。在這個架構中，整個開發週期包括若干個小的跌代周期，每個小的的跌代周期稱為一個Sprint，每個Sprint的建議長度2到4周。通俗的講，咱們現在制定了整個產品的開發週期，而這個開發週期是由各個小的迭代周期組成的，我們把每個小的迭代周期稱為一個個Sprint，如Sprint1，Sprint2，Sprint3（我現在手頭接觸到的手頭上的項目就是分為Sprint1~Sprint5），然後給每個Sprint2到4周的時間解決，分而治之，各個擊破。

    在Scrum中，使用產品（Product）Backlog來管理產品或項目的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。Scrum的Team Dev總是先開發的是對客戶具有較高價值的需求。在每個Sprint中，ScrumTeam Dev從產品Backlog中挑選最有價值的需求進行開發。Sprint中挑選的需求經過Sprint計劃會議上的分析、討論和估算得到一個Sprint的工作清單，我們稱它為Sprint backlog 。 
在每個迭代結束時，Scrum團隊將交付潛在可交付的產品增量。

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

  2.2、Scrum較傳統開發模型的優點

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

    
    是Scrum模型和傳統模型的對比（基本上每篇介紹Scrum都會引用的圖）：

    
   2.3、 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和其他相關的人員。一般該會議為4小時。

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

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

1. 將整個產品（Product）的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.

    整個過程如所示
    

 

  本文參考：1、維基百科；2、鄒欣的軟體工程教學部落格；3、酷勤網。完。