在Scrum中實現敏捷建模

本文主要是介紹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項目中敏捷建模核心原則的適用性

敏捷建模的核心原則	與Scrum的契合
軟件是你的首要目標	Scrum堅持所有的Sprint都結束於演示，其目的就是要交付可工作的軟件。
支持後續工作是你的第二目標	Scrum認爲，需求列表是推動迭代的主要力量，只要項目有資金，迭代就不會停止。項目的後續工作屬於需求列表的內容。
輕裝前進	Scrum的最終產出物除了可工作的軟件外，只包括Product Backlog和Sprint Backlog。
主張簡單	Scrum主張在一開始就要保持設計儘可能簡單。
包容變化	Scrum要求Product Owner根據不斷變化的商業環境對產品作出調整。
遞增的變化	Scrum屬於增量式開發，要求團隊在每個Sprint週期內完成一部分產品功能增量。
有目的地建模	與建模相關的原則，Scrum並未要求
多種模型20	與建模相關的原則，Scrum並未要求
你需要一個技術知識工具箱	團隊的基本要求。
高質量的工作	Scrum要求開發過程具有可視性，提倡對最後結果會產生影響的各個方面必須是清晰可見的，同時要求頻繁的檢查，以及對不合格的內容進行調整。
快速反饋	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團隊找到建模的最佳點，保證我們既進行了足夠的建模，以保證有效地研究和記錄系統，但又沒有過多地建模以致變成減慢項目進展的負擔。