本文主要是介紹Scrum中實現敏捷建模，希望通過本文能讓大家對Scrum有更深刻的了解，能完美的實現敏捷開發。

1. Scrum敏捷框架

1.1 Scrum概述

Scrum是一種敏捷過程，它使用迭代和增量方式管理和控制復雜的軟件與產品開發。Scrum的開發流程非常簡單。首先，Product Owner根據客戶的需求編寫Product Backlog，然后召開計劃會議，評估各項功能的相對工作量，并確定Sprint的愿景和目標，生成Sprint Backlog。然后，在Sprint（即迭代）的開發過程中，召開每日會議，Scrum Master通過它了解開發的進展以及出現的問題，檢查團隊成員的工作與進度。迭代結束后，團隊會召開評審會議，向項目關系人展示可運行的增量版本，并檢查是否達到了Sprint的目標。評審會議之后的回顧會議則會總結以往的實踐經驗，以提高團隊生產力。

Scrum的核心在于迭代。團隊首先瀏覽開發需求，考慮可用技術，并對自身技術及能力做出評估。然后共同確定構建功能的方案，并每日調整方法，以應對新的復雜問題、困難和出乎意料的情況。團隊找出并選擇最佳方案去完成任務。此創造性過程便是Scrum生產力的核心[1]。Scrum的所有實踐就是圍繞著一個迭代和增量的過程開展的。

1.2 Scrum的不足

與XP（eXtreme Programming，極限編程）不同，Scrum并沒有提供核心的價值觀與指導原則，也缺乏具體的實踐方法，例如結隊編程、測試驅動開發。Scrum僅僅規定了實施的基本流程與檢查表，它是一個開放的管理框架，重心在于項目管理，而不是指導團隊成員如何進行開發。這既是Scrum的優點，因為它很靈活，能夠適應大多數場景，也可以兼容并包地引入其他方法學所提倡的實踐；同時也是Scrum存在的固有缺陷，使得它難以被實踐。如果沒有一位優秀的Scrum Master，而團隊成員又缺乏自我組織和管理的能力，就會讓開發過程變得一團糟，團隊成員將會無所適從。

在開發實踐方面，Scrum可以借鑒XP提倡的結隊編程以及測試驅動開發實現編碼，通過重構對編碼進行調整以適應需求的變化。但是，Scrum在建模方面卻是一片空白。例如，Scrum對于如何創建Product Backlog，如何建立架構模型，以及如何在編碼之前進行必要的模型設計，都沒有給出具體的解決方案。缺乏正確的建模活動，就可能會對Scrum開發過程造成阻礙，影響團隊達成Sprint的目標。

2. 敏捷建模與Scrum的契合

敏捷建模（Agile Modeling）是一個基于實踐的建模方法，包括一系列以特定原則和價值為導向的，可被軟件專業人員應用到日常工作中的實際做法[2]。敏捷建模有效地將建模敏捷化，利用敏捷方法的思想對傳統的建模理念進行了重新梳理，使其更加適用于敏捷開發。敏捷建模描述了一種建模的風格。當它應用于敏捷的環境中時，能夠提高開發的質量和速度，同時避免過度簡化和不切實際的期望。

敏捷建模可以彌補Scrum在建模方面的不足。如果說Scrum是一個對開發過程的所有活動進行了規定的基本框架，則敏捷建模由于其對建模活動的核心關注，極大地豐富和增強了Scrum的軟件過程。建模在所有的軟件開發中都是不可缺少的一個重要環節。傳統的建模活動，常常會重視對文檔與工具的使用，要求創建的模型涵蓋軟件開發過程的方方面面。這種重量級的建模活動與敏捷開發方法在核心思想上是相悖的。敏捷方法需要敏捷的建模，Scrum自然也不例外。

敏捷建模定義了一組與輕量級的建模有關的價值觀、原則和實踐，并說明如何把它們付諸實施。本文將從敏捷建模的價值觀、核心原則和核心實踐三個方面討論敏捷建模與Scrum的契合。

2.1 敏捷建模的價值觀與Scrum的契合

敏捷建模的價值觀包括交流、簡單、反饋、勇氣和謙虛。前面四條來自于XP的價值觀，但完全可以說是敏捷開發的價值觀。敏捷軟件開發宣言強調與客戶交流和團隊的合作。宣言對可工作軟件的重視甚于詳盡的文檔，凸現了簡單的價值觀。宣言對變更的重視體現了反饋的重要性，以及擁抱變化的勇氣。Scrum同樣體現了敏捷建模的第五條原則——謙虛。Scrum將整個團隊定義為一種角色，作為一個整體負責將Sprint Backlog轉化為可運行的產品。在開發過程中，團隊成員需要管理自身的工作，同時對每次迭代和整個項目共同負責。如果沒有謙虛的精神，Scrum的團隊是無法運作的。

2.2 敏捷建模的核心原則與Scrum的契合

敏捷建模提出了十一條核心原則。Ambler認為，只有完全采納這些原則，才能真正地宣稱自己在進行敏捷建模。Scrum雖然沒有提出具體的指導原則，但在Scrum框架和實施流程中，仍然體現了部分敏捷建模的核心原則。表1展現了在Scrum項目中敏捷建模核心原則的適用性。

表1  在Scrum項目中敏捷建模核心原則的適用性

2.3 敏捷建模的核心實踐與Scrum的契合

敏捷建模的精華在于它的實踐，但敏捷建模的實踐是在價值觀和原則指引下體現的。它的核心實踐分為四類，即迭代和增量建模、團隊協作、簡單性和驗證。實際上，敏捷建模的實踐并沒有超出敏捷開發的范圍之外，只不過它的關注對象被界定為建模活動而已。因此，敏捷建模的實踐完全可以應用在Scrum的開發過程中。

迭代和增量建模實踐與Scrum完全吻合，因為Scrum本身就是一種迭代和增量開發。既然建模活動貫穿整個項目開發周期，因而建模采用迭代與增量的方式自然順理成章。Scrum定義了團隊角色，從而突出了團隊成員的協作，成員作為一個整體參與到軟件開發過程中。在Scrum中，每個成員都可能是建模人員，例如Product Owner對需求進行建模，對用戶界面進行建模，團隊成員對設計進行建模。簡單性實踐要求建模人員使用最簡單的工具，創建簡單的內容，簡單地描述模型。歸根結底，模型只需要傳達它應該展現的內容，不管是需求分析，還是架構設計，都應該盡可能地保持簡單，既不需要考慮格式，也不需要考慮完整，甚至可以丟棄那些已經實現了的模型。Scrum大量使用了白板、索引卡、即時貼等簡單工具，創建的模型非常簡單，甚至是臨時的。Scrum同樣重視對產品的驗證，避免出現錯誤或與需求產生偏差。

3. 貫穿Scrum敏捷過程的敏捷建模

3.1 Scrum軟件生命周期

Scrum并沒有明確劃分項目開發過程的階段，而是將幾種會議（計劃會議、評審會議和回顧會議）定義為軟件開發的里程碑。如果借用軟件生命周期的概念，我們可以將Scrum劃分為初始階段、計劃階段、沖刺階段與發布階段。初始階段的活動主要包括組建團隊、準備資源和編寫Product Backlog。計劃階段包括了Sprint的兩次計劃會議。沖刺階段即一個完整的Sprint迭代，周期通常不超過六個星期。發布階段包括評審會議與回顧會議。此階段結束后，將發布一個達到Sprint目標的增量版本。至于產品的維護，則屬于Product Backlog的一部分，列入每次迭代的范圍。

3.2 初始階段的敏捷建模

Product Backlog的編寫與建模活動息息相關。Product Backlog是Scrum的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。它里面包含的是客戶想要的東西，并用客戶的術語加以描述[3]。編寫Product Backlog就是對需求進行建模。根據敏捷建模“主張簡單”的原則，我們在描述Backlog的條目時，通常借鑒XP對用戶故事的描述方式，而不是采用用例驅動的模式。可以使用Excel工具來創建一個Backlog表。敏捷建模認為“內容比形式更重要”，在表示Backlog時，我們甚至可以使用即時貼，將其展示在白板上，使每個人都能直接看到需求模型。
編寫Product Backlog時，項目的利益相關人必須積極參與，和Product Owner一起確定Backlog的條目以及優先級。Product Backlog應該能夠“包容變化”，Product Owner通過與項目關系人的討論，可以增加新的功能，或者根據新的需求變化對其進行修改。根據敏捷建模的“多種模型”核心原則，我們也可以在Product Backlog基礎上，使用用例模型或用戶界面模型，幫助說明Backlog的業務流程，促進開發人員對需求的理解。

3.3 計劃階段的敏捷建模

計劃階段僅僅包括兩次計劃會議，每次計劃會議大約持續四個小時。第一個計劃會議主要確定Sprint的目標以及Sprint Backlog。第二個計劃會議則需要確定Sprint Backlog中每個任務的承擔人，并根據實際情況裁減Sprint Backlog，生成最終的Sprint Backlog。
敏捷建模認為，項目關系人應積極參與到需求建模活動中。Scrum負責需求建模的主要是Product Owner和客戶。在計劃會議中，Product Owner必須出席會議，以便對Backlog的需求條目進行解釋，幫助團隊理解需求。

敏捷建模的核心實踐要求“與他人一起建模”。在計劃會議中，團隊常常會對功能需求進行拆分，其目的主要是為了更容易對工作量進行估算，但另一方面也是對需求的一種細化。一種最佳實踐是將需求條目細分為任務。任務與需求條目的區別在于，需求條目屬于可交付的內容，是Product Owner以及他所代表的利益相關人所關心的。而任務則不可交付，它常常代表了分析、建模、編碼、測試等實現需求條目的各個環節。在拆分任務期間，并不會真正開展建模活動，但團隊成員在了解到需求的具體細節時，實際上已經開始考慮需求的實現。

計劃會議會對Sprint Backlog進行工作量估算。Scrum建議發揮集體的智慧。方法是利用計劃紙牌。團隊中的每個人都可以在深思熟慮之后，出示自己手里的紙牌，根據出示紙牌的數值取平均值，就可以大致獲得該需求條目的工作量。這種方式符合敏捷建模“簡單”的價值觀。在討論Sprint Backlog的需求細節時，則可以使用索引卡。根據每個需求的重要程度與優先級依次將索引卡張貼在墻上。索引卡屬于敏捷建模的臨時模型，在失去價值之后可以考慮丟棄，而只保留更新后的Sprint Backlog。

3.4 沖刺階段的敏捷建模

整個沖刺階段就是一個迭代周期，即一次Sprint。在 Sprint的開始階段，我們可以根據Sprint Backlog建立一個任務列表模型，以及一個能夠直觀反映開發進度和開發效率的Burndown（燃盡）模型，并形成一個任務板。任務板要盡量簡單，只需要保留必要的列。Scrum要求召開站立的每日會議，通常就在任務板前完成。團隊成員一邊描述昨天已經做的和今天要做的事情，一邊移動任務板上對應的即時貼。每日會議結束，則任務模型也隨之更新，最后由Scrum Master負責更新Sprint Backlog和Burndown模型。

在沖刺階段引入敏捷建模非常必要，它有助于解決團隊在開發過程中遇到的需求、設計以及開發方面的問題。一個方法是召集相關人員舉行簡短的設計會議，這在敏捷建模中稱為專門或即興建模會議。通常的流程是：首先與項目關系人探討相關的需求，可能需要創建基本用戶界面模型或者討論業務規則的邏輯；隨后繼續前進討論這些需求潛在的解決方案，這時常常會畫一張白板草圖來幫助討論；再往后就是繼續前進編碼并測試這個解決方案[4]。

Scrum團隊沒有設計人員、建模人員和編碼人員之間的區別，它是自組織、自管理的團隊。團隊的每一個成員都具有項目中所有方面的參與權力，不存在單一的團隊成員對系統架構、需求或者測試負責的情況[5]。這正是敏捷建模“有效團隊協作的實踐”的運用。
在沖刺階段，通過引入敏捷建模，我們可以在開發過程中創建架構模型、類結構模型和測試用例模型等內容。根據項目的實際情況，我們可以選擇使用UML建模工具，或直接利用簡單的白板工具創建架構模型，利用CRC卡展現類的結構模型。我們還可以借助一些需求模型以及用戶界面模型，深入對需求的理解。

3.5 發布階段的敏捷建模

Scrum評審會議實際上就是一次增量產品的演示和發布。在進行Sprint演示時，需要確保清晰闡述了Sprint目標，并讓演示關注于業務層次，而不要考慮技術細節。如果我們在沖刺階段嚴格地遵循了持續集成原則，就可以在每次Sprint之后發布一個增量版本，供用戶使用。這實際上是“快速反饋”和“包容變化”核心原則的體現。通過每次迭代發布的版本，可以及時獲得客戶的反饋，驗證實現是否與需求相符。如果出現偏差，或者客戶提出新的建議和變化，就可以將其列入到下次Sprint的范圍和目標中。

回顧會議在Scrum中是一項特殊的活動。審視和適應的能力是Scrum的基礎，這也是開展回顧會議的目的。在回顧會議期間，項目團隊會分析Sprint中的成功經驗和遇到的障礙。Scrum回顧會議不會涉及建模活動，但它對于敏捷建模而言卻具有促進作用，因為我們可以在回顧會議中總結敏捷建模應用的得與失。例如我們可以討論建模活動是否過于復雜，是否需要引入其它的建模工具，哪些模型屬于臨時模型或契約模型。簡而言之，在回顧會議中，我們可以檢查團隊的建模活動是否背離了敏捷建模的價值觀、原則和實踐。

4. 結束語

在Scrum項目中，建模活動仍然屬于必不可少的一個環節，但卻是很多Scrum實踐容易忽視或輕視的一部分。Scrum敏捷框架的不足主要體現于此。如果將敏捷建模的價值觀、原則與實踐應用到Scrum的整個開發過程中，將有利于規范Scrum的建模活動。二者的關系是框架與細節的有機契合。Scrum提供了一個基礎的框架，對敏捷開發過程中的所有活動進行了規定，而敏捷建模的重點則是全部軟件過程的一部分，因而需要與另一個完整的過程結合，以增強這些過程。敏捷建模是Scrum的有效補充，在Scrum中實施敏捷建模，能夠提高Scrum的可操作性，并在建模活動方面給與指導與規范。敏捷建模幫助Scrum團隊找到建模的最佳點，保證我們既進行了足夠的建模，以保證有效地研究和記錄系統，但又沒有過多地建模以致變成減慢項目進展的負擔。

原文標題：在Scrum中實施敏捷建模

鏈接：http://www.cnblogs.com/wayfarer/archive/2009/11/11/1601360.html