2009-12-22 作者：張逸 來源：博客園
本文主要是介紹Scrum中實現(xiàn)敏捷建模，希望通過本文能讓大家對Scrum有更深刻的了解，能完美的實現(xiàn)敏捷開發(fā)。
1. Scrum敏捷框架
1.1 Scrum概述
Scrum是一種敏捷過程，它使用迭代和增量方式管理和控制復(fù)雜的軟件與產(chǎn)品開發(fā)。Scrum的 開發(fā)流程非常簡單。首先，Product Owner根據(jù)客戶的需求編寫Product Backlog，然后召開計劃會議，評估各項功能的相對工作量，并確定Sprint的愿景和目標，生成Sprint Backlog。然后，在Sprint（即迭代）的開發(fā)過程中，召開每日會議，Scrum Master通過它了解開發(fā)的進展以及出現(xiàn)的問題，檢查團隊成員的工作與進度。迭代結(jié)束后，團隊會召開評審會議，向項目關(guān)系人展示可運行的增量版本，并檢 查是否達到了Sprint的目標。評審會議之后的回顧會議則會總結(jié)以往的實踐經(jīng)驗，以提高團隊生產(chǎn)力。
Scrum的核心在于迭代。團隊首先瀏覽開發(fā)需求，考慮可用技術(shù)，并對自身技術(shù)及能力做出評估。 然后共同確定構(gòu)建功能的方案，并每日調(diào)整方法，以應(yīng)對新的復(fù)雜問題、困難和出乎意料的情況。團隊找出并選擇最佳方案去完成任務(wù)。此創(chuàng)造性過程便是 Scrum生產(chǎn)力的核心[1]。Scrum的所有實踐就是圍繞著一個迭代和增量的過程開展的。
1.2 Scrum的不足
與XP（eXtreme Programming，極限編程）不同，Scrum并沒有提供核心的價值觀與指導原則，也缺乏具體的實踐方法，例如結(jié)隊編程、測試驅(qū)動開發(fā)。Scrum 僅僅規(guī)定了實施的基本流程與檢查表，它是一個開放的管理框架，重心在于項目管理，而不是指導團隊成員如何進行開發(fā)。這既是Scrum的優(yōu)點，因為它很靈 活，能夠適應(yīng)大多數(shù)場景，也可以兼容并包地引入其他方法學所提倡的實踐；同時也是Scrum存在的固有缺陷，使得它難以被實踐。如果沒有一位優(yōu)秀的 Scrum Master，而團隊成員又缺乏自我組織和管理的能力，就會讓開發(fā)過程變得一團糟，團隊成員將會無所適從。
在開發(fā)實踐方面，Scrum可以借鑒XP提倡的結(jié)隊編程以及測試驅(qū)動開發(fā)實現(xiàn)編碼，通過重構(gòu)對編碼進行調(diào)整以適應(yīng)需求的變化。但是，Scrum在建模方面卻是一片空白。例如，Scrum對于如何創(chuàng)建Product Backlog，如何建立架構(gòu)模型，以及如何在編碼之前進行必要的模型設(shè)計，都沒有給出具體的解決方案。缺乏正確的建模活動，就可能會對Scrum開發(fā)過程造成阻礙，影響團隊達成Sprint的目標。
2. 敏捷建模與Scrum的契合
敏捷建模（Agile Modeling）是一個基于實踐的建模方法，包括一系列以特定原則和價值為導向的，可被軟件專業(yè)人員應(yīng)用到日常工作中的實際做法[2]。敏捷建模有效地 將建模敏捷化，利用敏捷方法的思想對傳統(tǒng)的建模理念進行了重新梳理，使其更加適用于敏捷開發(fā)。敏捷建模描述了一種建模的風格。當它應(yīng)用于敏捷的環(huán)境中時， 能夠提高開發(fā)的質(zhì)量和速度，同時避免過度簡化和不切實際的期望。
敏捷建?？梢詮浹aScrum在建模方面的不足。如果說Scrum是一個對開發(fā)過程的所有活動進行 了規(guī)定的基本框架，則敏捷建模由于其對建模活動的核心關(guān)注，極大地豐富和增強了Scrum的軟件過程。建模在所有的軟件開發(fā)中都是不可缺少的一個重要環(huán) 節(jié)。傳統(tǒng)的建?；顒?，常常會重視對文檔與工具的使用，要求創(chuàng)建的模型涵蓋軟件開發(fā)過程的方方面面。這種重量級的建模活動與敏捷開發(fā)方法在核心思想上是相悖 的。敏捷方法需要敏捷的建模，Scrum自然也不例外。
敏捷建模定義了一組與輕量級的建模有關(guān)的價值觀、原則和實踐，并說明如何把它們付諸實施。本文將從敏捷建模的價值觀、核心原則和核心實踐三個方面討論敏捷建模與Scrum的契合。
2.1 敏捷建模的價值觀與Scrum的契合
敏捷建模的價值觀包括交流、簡單、反饋、勇氣和謙虛。前面四條來自于XP的價值觀，但完全可以說 是敏捷開發(fā)的價值觀。敏捷軟件開發(fā)宣言強調(diào)與客戶交流和團隊的合作。宣言對可工作軟件的重視甚于詳盡的文檔，凸現(xiàn)了簡單的價值觀。宣言對變更的重視體現(xiàn)了 反饋的重要性，以及擁抱變化的勇氣。Scrum同樣體現(xiàn)了敏捷建模的第五條原則——謙虛。Scrum將整個團隊定義為一種角色，作為一個整體負責將 Sprint Backlog轉(zhuǎn)化為可運行的產(chǎn)品。在開發(fā)過程中，團隊成員需要管理自身的工作，同時對每次迭代和整個項目共同負責。如果沒有謙虛的精神，Scrum的團 隊是無法運作的。
2.2 敏捷建模的核心原則與Scrum的契合
敏捷建模提出了十一條核心原則。Ambler認為，只有完全采納這些原則，才能真正地宣稱自己在 進行敏捷建模。Scrum雖然沒有提出具體的指導原則，但在Scrum框架和實施流程中，仍然體現(xiàn)了部分敏捷建模的核心原則。表1展現(xiàn)了在Scrum項目 中敏捷建模核心原則的適用性。
表1 在Scrum項目中敏捷建模核心原則的適用性
敏捷建模的核心原則
與Scrum的契合
軟件是你的首要目標
Scrum堅持所有的Sprint都結(jié)束于演示，其目的就是要交付可工作的軟件。
支持后續(xù)工作是你的第二目標
Scrum認為，需求列表是推動迭代的主要力量，只要項目有資金，迭代就不會停止。項目的后續(xù)工作屬于需求列表的內(nèi)容。
輕裝前進
Scrum的最終產(chǎn)出物除了可工作的軟件外，只包括Product Backlog和Sprint Backlog。
主張簡單
Scrum主張在一開始就要保持設(shè)計盡可能簡單。
包容變化
Scrum要求Product Owner根據(jù)不斷變化的商業(yè)環(huán)境對產(chǎn)品作出調(diào)整。
遞增的變化
Scrum屬于增量式開發(fā)，要求團隊在每個Sprint周期內(nèi)完成一部分產(chǎn)品功能增量。
有目的地建模
與建模相關(guān)的原則，Scrum并未要求
多種模型20
與建模相關(guān)的原則，Scrum并未要求
你需要一個技術(shù)知識工具箱
團隊的基本要求。
高質(zhì)量的工作
Scrum要求開發(fā)過程具有可視性，提倡對最后結(jié)果會產(chǎn)生影響的各個方面必須是清晰可見的，同時要求頻繁的檢查，以及對不合格的內(nèi)容進行調(diào)整。
快速反饋
Scrum每日會議、評審會議與回顧會議反映了這一原則。
2.3 敏捷建模的核心實踐與Scrum的契合
敏捷建模的精華在于它的實踐，但敏捷建模的實踐是在價值觀和原則指引下體現(xiàn)的。它的核心實踐分為 四類，即迭代和增量建模、團隊協(xié)作、簡單性和驗證。實際上，敏捷建模的實踐并沒有超出敏捷開發(fā)的范圍之外，只不過它的關(guān)注對象被界定為建模活動而已。因 此，敏捷建模的實踐完全可以應(yīng)用在Scrum的開發(fā)過程中。
迭代和增量建模實踐與Scrum完全吻合，因為Scrum本身就是一種迭代和增量開發(fā)。既然建模 活動貫穿整個項目開發(fā)周期，因而建模采用迭代與增量的方式自然順理成章。Scrum定義了團隊角色，從而突出了團隊成員的協(xié)作，成員作為一個整體參與到軟 件開發(fā)過程中。在Scrum中，每個成員都可能是建模人員，例如Product Owner對需求進行建模，對用戶界面進行建模，團隊成員對設(shè)計進行建模。簡單性實踐要求建模人員使用最簡單的工具，創(chuàng)建簡單的內(nèi)容，簡單地描述模型。歸 根結(jié)底，模型只需要傳達它應(yīng)該展現(xiàn)的內(nèi)容，不管是需求分析，還是架構(gòu)設(shè)計，都應(yīng)該盡可能地保持簡單，既不需要考慮格式，也不需要考慮完整，甚至可以丟棄那 些已經(jīng)實現(xiàn)了的模型。Scrum大量使用了白板、索引卡、即時貼等簡單工具，創(chuàng)建的模型非常簡單，甚至是臨時的。Scrum同樣重視對產(chǎn)品的驗證，避免出 現(xiàn)錯誤或與需求產(chǎn)生偏差。
3. 貫穿Scrum敏捷過程的敏捷建模
3.1 Scrum軟件生命周期
Scrum并沒有明確劃分項目開發(fā)過程的階段，而是將幾種會議（計劃會議、評審會議和回顧會議） 定義為軟件開發(fā)的里程碑。如果借用軟件生命周期的概念，我們可以將Scrum劃分為初始階段、計劃階段、沖刺階段與發(fā)布階段。初始階段的活動主要包括組建 團隊、準備資源和編寫Product Backlog。計劃階段包括了Sprint的兩次計劃會議。沖刺階段即一個完整的Sprint迭代，周期通常不超過六個星期。發(fā)布階段包括評審會議與回 顧會議。此階段結(jié)束后，將發(fā)布一個達到Sprint目標的增量版本。至于產(chǎn)品的維護，則屬于Product Backlog的一部分，列入每次迭代的范圍。
3.2 初始階段的敏捷建模
Product Backlog的編寫與建?；顒酉⑾⑾嚓P(guān)。Product Backlog是Scrum的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。它里面包含 的是客戶想要的東西，并用客戶的術(shù)語加以描述[3]。編寫Product Backlog就是對需求進行建模。根據(jù)敏捷建模“主張簡單”的原則，我們在描述Backlog的條目時，通常借鑒XP對用戶故事的描述方式，而不是采用 用例驅(qū)動的模式。可以使用Excel工具來創(chuàng)建一個Backlog表。敏捷建模認為“內(nèi)容比形式更重要”，在表示Backlog時，我們甚至可以使用即時 貼，將其展示在白板上，使每個人都能直接看到需求模型。
編寫Product Backlog時，項目的利益相關(guān)人必須積極參與，和Product Owner一起確定Backlog的條目以及優(yōu)先級。Product Backlog應(yīng)該能夠“包容變化”，Product Owner通過與項目關(guān)系人的討論，可以增加新的功能，或者根據(jù)新的需求變化對其進行修改。根據(jù)敏捷建模的“多種模型”核心原則，我們也可以在Product Backlog基礎(chǔ)上，使用用例模型或用戶界面模型，幫助說明Backlog的業(yè)務(wù)流程，促進開發(fā)人員對需求的理解。
3.3 計劃階段的敏捷建模
計劃階段僅僅包括兩次計劃會議，每次計劃會議大約持續(xù)四個小時。第一個計劃會議主要確定Sprint的目標以及Sprint Backlog。第二個計劃會議則需要確定Sprint Backlog中每個任務(wù)的承擔人，并根據(jù)實際情況裁減Sprint Backlog，生成最終的Sprint Backlog。
敏捷建模認為，項目關(guān)系人應(yīng)積極參與到需求建?；顒又?。Scrum負責需求建模的主要是Product Owner和客戶。在計劃會議中，Product Owner必須出席會議，以便對Backlog的需求條目進行解釋，幫助團隊理解需求。
敏捷建模的核心實踐要求“與他人一起建模”。在計劃會議中，團隊常常會對功能需求進行拆分，其目 的主要是為了更容易對工作量進行估算，但另一方面也是對需求的一種細化。一種最佳實踐是將需求條目細分為任務(wù)。任務(wù)與需求條目的區(qū)別在于，需求條目屬于可 交付的內(nèi)容，是Product Owner以及他所代表的利益相關(guān)人所關(guān)心的。而任務(wù)則不可交付，它常常代表了分析、建模、編碼、測試等實現(xiàn)需求條目的各個環(huán)節(jié)。在拆分任務(wù)期間，并不會 真正開展建?；顒樱珗F隊成員在了解到需求的具體細節(jié)時，實際上已經(jīng)開始考慮需求的實現(xiàn)。
計劃會議會對Sprint Backlog進行工作量估算。Scrum建議發(fā)揮集體的智慧。方法是利用計劃紙牌。團隊中的每個人都可以在深思熟慮之后，出示自己手里的紙牌，根據(jù)出示 紙牌的數(shù)值取平均值，就可以大致獲得該需求條目的工作量。這種方式符合敏捷建模“簡單”的價值觀。在討論Sprint Backlog的需求細節(jié)時，則可以使用索引卡。根據(jù)每個需求的重要程度與優(yōu)先級依次將索引卡張貼在墻上。索引卡屬于敏捷建模的臨時模型，在失去價值之后 可以考慮丟棄，而只保留更新后的Sprint Backlog。
3.4 沖刺階段的敏捷建模
整個沖刺階段就是一個迭代周期，即一次Sprint。在 Sprint的開始階段，我們可以根據(jù)Sprint Backlog建立一個任務(wù)列表模型，以及一個能夠直觀反映開發(fā)進度和開發(fā)效率的Burndown（燃盡）模型，并形成一個任務(wù)板。任務(wù)板要盡量簡單，只 需要保留必要的列。Scrum要求召開站立的每日會議，通常就在任務(wù)板前完成。團隊成員一邊描述昨天已經(jīng)做的和今天要做的事情，一邊移動任務(wù)板上對應(yīng)的即 時貼。每日會議結(jié)束，則任務(wù)模型也隨之更新，最后由Scrum Master負責更新Sprint Backlog和Burndown模型。
在沖刺階段引入敏捷建模非常必要，它有助于解決團隊在開發(fā)過程中遇到的需求、設(shè)計以及開發(fā)方面的 問題。一個方法是召集相關(guān)人員舉行簡短的設(shè)計會議，這在敏捷建模中稱為專門或即興建模會議。通常的流程是：首先與項目關(guān)系人探討相關(guān)的需求，可能需要創(chuàng)建 基本用戶界面模型或者討論業(yè)務(wù)規(guī)則的邏輯；隨后繼續(xù)前進討論這些需求潛在的解決方案，這時常常會畫一張白板草圖來幫助討論；再往后就是繼續(xù)前進編碼并測試 這個解決方案[4]。
Scrum團隊沒有設(shè)計人員、建模人員和編碼人員之間的區(qū)別，它是自組織、自管理的團隊。團隊的每一個成員都具有項目中所有方面的參與權(quán)力，不存在單一的團隊成員對系統(tǒng)架構(gòu)、需求或者測試負責的情況[5]。這正是敏捷建模“有效團隊協(xié)作的實踐”的運用。
在沖刺階段，通過引入敏捷建模，我們可以在開發(fā)過程中創(chuàng)建架構(gòu)模型、類結(jié)構(gòu)模型和測試用例模型等內(nèi)容。根據(jù)項目的實際情況，我們可以選擇使用UML建模工 具，或直接利用簡單的白板工具創(chuàng)建架構(gòu)模型，利用CRC卡展現(xiàn)類的結(jié)構(gòu)模型。我們還可以借助一些需求模型以及用戶界面模型，深入對需求的理解。
3.5 發(fā)布階段的敏捷建模
Scrum評審會議實際上就是一次增量產(chǎn)品的演示和發(fā)布。在進行Sprint演示時，需要確保清 晰闡述了Sprint目標，并讓演示關(guān)注于業(yè)務(wù)層次，而不要考慮技術(shù)細節(jié)。如果我們在沖刺階段嚴格地遵循了持續(xù)集成原則，就可以在每次Sprint之后發(fā) 布一個增量版本，供用戶使用。這實際上是“快速反饋”和“包容變化”核心原則的體現(xiàn)。通過每次迭代發(fā)布的版本，可以及時獲得客戶的反饋，驗證實現(xiàn)是否與需 求相符。如果出現(xiàn)偏差，或者客戶提出新的建議和變化，就可以將其列入到下次Sprint的范圍和目標中。
回顧會議在Scrum中是一項特殊的活動。審視和適應(yīng)的能力是Scrum的基礎(chǔ)，這也是開展回顧 會議的目的。在回顧會議期間，項目團隊會分析Sprint中的成功經(jīng)驗和遇到的障礙。Scrum回顧會議不會涉及建模活動，但它對于敏捷建模而言卻具有促 進作用，因為我們可以在回顧會議中總結(jié)敏捷建模應(yīng)用的得與失。例如我們可以討論建?；顒邮欠襁^于復(fù)雜，是否需要引入其它的建模工具，哪些模型屬于臨時模型 或契約模型。簡而言之，在回顧會議中，我們可以檢查團隊的建?；顒邮欠癖畴x了敏捷建模的價值觀、原則和實踐。
4. 結(jié)束語
在Scrum項目中，建?；顒尤匀粚儆诒夭豢缮俚囊粋€環(huán)節(jié)，但卻是很多Scrum實踐容易忽視或 輕視的一部分。Scrum敏捷框架的不足主要體現(xiàn)于此。如果將敏捷建模的價值觀、原則與實踐應(yīng)用到Scrum的整個開發(fā)過程中，將有利于規(guī)范Scrum的 建?；顒印６叩年P(guān)系是框架與細節(jié)的有機契合。Scrum提供了一個基礎(chǔ)的框架，對敏捷開發(fā)過程中的所有活動進行了規(guī)定，而敏捷建模的重點則是全部軟件過 程的一部分，因而需要與另一個完整的過程結(jié)合，以增強這些過程。敏捷建模是Scrum的有效補充，在Scrum中實施敏捷建模，能夠提高Scrum的可操 作性，并在建模活動方面給與指導與規(guī)范。敏捷建模幫助Scrum團隊找到建模的最佳點，保證我們既進行了足夠的建模，以保證有效地研究和記錄系統(tǒng)，但又沒 有過多地建模以致變成減慢項目進展的負擔。
參考文獻
[1] Ken Schwaber. Agile Project Management with Scrum[M]. 上海：世界圖書出版公司，2007：6.
[2] 王毅嘉，張為群. 一種基于UML和敏捷建模的JEMM方法研究[J]. 西南師范大學學報（自然科學版），2005，30（3）：426.
[3] Henrik Kniberg. Scrum and XP from the Trenches[M/OL].C4Media,2008, http://infoq.com/minibooks/scrum-xp-from-the-trenches
[4] Scott W Ambler. 敏捷建?！獦O限編程和統(tǒng)一過程的有效實踐[M]. 張嘉路，朱鵬，程賓,譯. 北京：機械工業(yè)出版社，2003：120.
[5] Robert C Martin. 敏捷軟件開發(fā)——原則、模式與實踐[M]. 鄧輝,譯.北京：清華大學出版社，2003：7.
