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

1. Scrum敏捷框架

1.1 Scrum概述

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

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

1.2 Scrum的不足

與XP（eXtreme Programming，極限編程）不同，Scrum并沒有提供核心的價(jià)值觀與指導(dǎo)原則，也缺乏具體的實(shí)踐方法，例如結(jié)隊(duì)編程、測試驅(qū)動(dòng)開發(fā)。Scrum僅僅規(guī)定了實(shí)施的基本流程與檢查表，它是一個(gè)開放的管理框架，重心在于項(xiàng)目管理，而不是指導(dǎo)團(tuán)隊(duì)成員如何進(jìn)行開發(fā)。這既是Scrum的優(yōu)點(diǎn)，因?yàn)樗莒`活，能夠適應(yīng)大多數(shù)場景，也可以兼容并包地引入其他方法學(xué)所提倡的實(shí)踐；同時(shí)也是Scrum存在的固有缺陷，使得它難以被實(shí)踐。如果沒有一位優(yōu)秀的Scrum Master，而團(tuán)隊(duì)成員又缺乏自我組織和管理的能力，就會(huì)讓開發(fā)過程變得一團(tuán)糟，團(tuán)隊(duì)成員將會(huì)無所適從。

在開發(fā)實(shí)踐方面，Scrum可以借鑒XP提倡的結(jié)隊(duì)編程以及測試驅(qū)動(dòng)開發(fā)實(shí)現(xiàn)編碼，通過重構(gòu)對編碼進(jìn)行調(diào)整以適應(yīng)需求的變化。但是，Scrum在建模方面卻是一片空白。例如，Scrum對于如何創(chuàng)建Product Backlog，如何建立架構(gòu)模型，以及如何在編碼之前進(jìn)行必要的模型設(shè)計(jì)，都沒有給出具體的解決方案。缺乏正確的建?；顒?dòng)，就可能會(huì)對Scrum開發(fā)過程造成阻礙，影響團(tuán)隊(duì)達(dá)成Sprint的目標(biāo)。

2. 敏捷建模與Scrum的契合

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

敏捷建模可以彌補(bǔ)Scrum在建模方面的不足。如果說Scrum是一個(gè)對開發(fā)過程的所有活動(dòng)進(jìn)行了規(guī)定的基本框架，則敏捷建模由于其對建?；顒?dòng)的核心關(guān)注，極大地豐富和增強(qiáng)了Scrum的軟件過程。建模在所有的軟件開發(fā)中都是不可缺少的一個(gè)重要環(huán)節(jié)。傳統(tǒng)的建?；顒?dòng)，常常會(huì)重視對文檔與工具的使用，要求創(chuàng)建的模型涵蓋軟件開發(fā)過程的方方面面。這種重量級的建?；顒?dòng)與敏捷開發(fā)方法在核心思想上是相悖的。敏捷方法需要敏捷的建模，Scrum自然也不例外。

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

2.1 敏捷建模的價(jià)值觀與Scrum的契合

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

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

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

表1  在Scrum項(xiàng)目中敏捷建模核心原則的適用性

2.3 敏捷建模的核心實(shí)踐與Scrum的契合

敏捷建模的精華在于它的實(shí)踐，但敏捷建模的實(shí)踐是在價(jià)值觀和原則指引下體現(xiàn)的。它的核心實(shí)踐分為四類，即迭代和增量建模、團(tuán)隊(duì)協(xié)作、簡單性和驗(yàn)證。實(shí)際上，敏捷建模的實(shí)踐并沒有超出敏捷開發(fā)的范圍之外，只不過它的關(guān)注對象被界定為建?；顒?dòng)而已。因此，敏捷建模的實(shí)踐完全可以應(yīng)用在Scrum的開發(fā)過程中。

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

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

3.1 Scrum軟件生命周期

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

3.2 初始階段的敏捷建模

Product Backlog的編寫與建?；顒?dòng)息息相關(guān)。Product Backlog是Scrum的核心，也是一切的起源。從根本上說，它就是一個(gè)需求、或故事、或特性等組成的列表，按照重要性的級別進(jìn)行了排序。它里面包含的是客戶想要的東西，并用客戶的術(shù)語加以描述[3]。編寫Product Backlog就是對需求進(jìn)行建模。根據(jù)敏捷建?！爸鲝埡唵巍钡脑瓌t，我們在描述Backlog的條目時(shí)，通常借鑒XP對用戶故事的描述方式，而不是采用用例驅(qū)動(dòng)的模式。可以使用Excel工具來創(chuàng)建一個(gè)Backlog表。敏捷建模認(rèn)為“內(nèi)容比形式更重要”，在表示Backlog時(shí)，我們甚至可以使用即時(shí)貼，將其展示在白板上，使每個(gè)人都能直接看到需求模型。
編寫Product Backlog時(shí)，項(xiàng)目的利益相關(guān)人必須積極參與，和Product Owner一起確定Backlog的條目以及優(yōu)先級。Product Backlog應(yīng)該能夠“包容變化”，Product Owner通過與項(xiàng)目關(guān)系人的討論，可以增加新的功能，或者根據(jù)新的需求變化對其進(jìn)行修改。根據(jù)敏捷建模的“多種模型”核心原則，我們也可以在Product Backlog基礎(chǔ)上，使用用例模型或用戶界面模型，幫助說明Backlog的業(yè)務(wù)流程，促進(jìn)開發(fā)人員對需求的理解。

3.3 計(jì)劃階段的敏捷建模

計(jì)劃階段僅僅包括兩次計(jì)劃會(huì)議，每次計(jì)劃會(huì)議大約持續(xù)四個(gè)小時(shí)。第一個(gè)計(jì)劃會(huì)議主要確定Sprint的目標(biāo)以及Sprint Backlog。第二個(gè)計(jì)劃會(huì)議則需要確定Sprint Backlog中每個(gè)任務(wù)的承擔(dān)人，并根據(jù)實(shí)際情況裁減Sprint Backlog，生成最終的Sprint Backlog。
敏捷建模認(rèn)為，項(xiàng)目關(guān)系人應(yīng)積極參與到需求建?；顒?dòng)中。Scrum負(fù)責(zé)需求建模的主要是Product Owner和客戶。在計(jì)劃會(huì)議中，Product Owner必須出席會(huì)議，以便對Backlog的需求條目進(jìn)行解釋，幫助團(tuán)隊(duì)理解需求。

敏捷建模的核心實(shí)踐要求“與他人一起建?！薄Ｔ谟?jì)劃會(huì)議中，團(tuán)隊(duì)常常會(huì)對功能需求進(jìn)行拆分，其目的主要是為了更容易對工作量進(jìn)行估算，但另一方面也是對需求的一種細(xì)化。一種最佳實(shí)踐是將需求條目細(xì)分為任務(wù)。任務(wù)與需求條目的區(qū)別在于，需求條目屬于可交付的內(nèi)容，是Product Owner以及他所代表的利益相關(guān)人所關(guān)心的。而任務(wù)則不可交付，它常常代表了分析、建模、編碼、測試等實(shí)現(xiàn)需求條目的各個(gè)環(huán)節(jié)。在拆分任務(wù)期間，并不會(huì)真正開展建?；顒?dòng)，但團(tuán)隊(duì)成員在了解到需求的具體細(xì)節(jié)時(shí)，實(shí)際上已經(jīng)開始考慮需求的實(shí)現(xiàn)。

計(jì)劃會(huì)議會(huì)對Sprint Backlog進(jìn)行工作量估算。Scrum建議發(fā)揮集體的智慧。方法是利用計(jì)劃紙牌。團(tuán)隊(duì)中的每個(gè)人都可以在深思熟慮之后，出示自己手里的紙牌，根據(jù)出示紙牌的數(shù)值取平均值，就可以大致獲得該需求條目的工作量。這種方式符合敏捷建?！昂唵巍钡膬r(jià)值觀。在討論Sprint Backlog的需求細(xì)節(jié)時(shí)，則可以使用索引卡。根據(jù)每個(gè)需求的重要程度與優(yōu)先級依次將索引卡張貼在墻上。索引卡屬于敏捷建模的臨時(shí)模型，在失去價(jià)值之后可以考慮丟棄，而只保留更新后的Sprint Backlog。

3.4 沖刺階段的敏捷建模

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

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

Scrum團(tuán)隊(duì)沒有設(shè)計(jì)人員、建模人員和編碼人員之間的區(qū)別，它是自組織、自管理的團(tuán)隊(duì)。團(tuán)隊(duì)的每一個(gè)成員都具有項(xiàng)目中所有方面的參與權(quán)力，不存在單一的團(tuán)隊(duì)成員對系統(tǒng)架構(gòu)、需求或者測試負(fù)責(zé)的情況[5]。這正是敏捷建?！坝行F(tuán)隊(duì)協(xié)作的實(shí)踐”的運(yùn)用。
在沖刺階段，通過引入敏捷建模，我們可以在開發(fā)過程中創(chuàng)建架構(gòu)模型、類結(jié)構(gòu)模型和測試用例模型等內(nèi)容。根據(jù)項(xiàng)目的實(shí)際情況，我們可以選擇使用UML建模工具，或直接利用簡單的白板工具創(chuàng)建架構(gòu)模型，利用CRC卡展現(xiàn)類的結(jié)構(gòu)模型。我們還可以借助一些需求模型以及用戶界面模型，深入對需求的理解。

3.5 發(fā)布階段的敏捷建模

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

回顧會(huì)議在Scrum中是一項(xiàng)特殊的活動(dòng)。審視和適應(yīng)的能力是Scrum的基礎(chǔ)，這也是開展回顧會(huì)議的目的。在回顧會(huì)議期間，項(xiàng)目團(tuán)隊(duì)會(huì)分析Sprint中的成功經(jīng)驗(yàn)和遇到的障礙。Scrum回顧會(huì)議不會(huì)涉及建?；顒?dòng)，但它對于敏捷建模而言卻具有促進(jìn)作用，因?yàn)槲覀兛梢栽诨仡檿?huì)議中總結(jié)敏捷建模應(yīng)用的得與失。例如我們可以討論建模活動(dòng)是否過于復(fù)雜，是否需要引入其它的建模工具，哪些模型屬于臨時(shí)模型或契約模型。簡而言之，在回顧會(huì)議中，我們可以檢查團(tuán)隊(duì)的建模活動(dòng)是否背離了敏捷建模的價(jià)值觀、原則和實(shí)踐。

4. 結(jié)束語

在Scrum項(xiàng)目中，建模活動(dòng)仍然屬于必不可少的一個(gè)環(huán)節(jié)，但卻是很多Scrum實(shí)踐容易忽視或輕視的一部分。Scrum敏捷框架的不足主要體現(xiàn)于此。如果將敏捷建模的價(jià)值觀、原則與實(shí)踐應(yīng)用到Scrum的整個(gè)開發(fā)過程中，將有利于規(guī)范Scrum的建模活動(dòng)。二者的關(guān)系是框架與細(xì)節(jié)的有機(jī)契合。Scrum提供了一個(gè)基礎(chǔ)的框架，對敏捷開發(fā)過程中的所有活動(dòng)進(jìn)行了規(guī)定，而敏捷建模的重點(diǎn)則是全部軟件過程的一部分，因而需要與另一個(gè)完整的過程結(jié)合，以增強(qiáng)這些過程。敏捷建模是Scrum的有效補(bǔ)充，在Scrum中實(shí)施敏捷建模，能夠提高Scrum的可操作性，并在建?；顒?dòng)方面給與指導(dǎo)與規(guī)范。敏捷建模幫助Scrum團(tuán)隊(duì)找到建模的最佳點(diǎn)，保證我們既進(jìn)行了足夠的建模，以保證有效地研究和記錄系統(tǒng)，但又沒有過多地建模以致變成減慢項(xiàng)目進(jìn)展的負(fù)擔(dān)。

原文標(biāo)題：在Scrum中實(shí)施敏捷建模

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