摘要： 該文首先介紹了傳統(tǒng)的軟件開發(fā)模型及其缺點(diǎn)，接著引入了敏捷開發(fā)的基本思想和SCRUM的敏捷開發(fā)方法，然后基于多年的大型軟件開發(fā)經(jīng)驗(yàn)和項(xiàng)目管理經(jīng)驗(yàn)，提出基于SCRUM的大型軟件開發(fā)模型，吸取傳統(tǒng)開發(fā)模型中的優(yōu)點(diǎn)，給出詳細(xì)的軟件開發(fā)流程。

關(guān)鍵詞： 敏捷開發(fā)；SCRUM；軟件開發(fā)模型

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2013）13-3043-04

1 傳統(tǒng)軟件開發(fā)模型

傳統(tǒng)的軟件開發(fā)模型有瀑布模型，V模型，增量模型，迭代模型，螺旋模型，快速原型模型等。其中瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，1970年Royce提出，直到80年代早期，它一直是唯一被廣泛使用的軟件開發(fā)模型。瀑布模型的核心思想是將軟件的生命周期分成可行性分析與計(jì)劃、需求分析、軟件設(shè)計(jì)、編碼、測(cè)試及運(yùn)營(yíng)維護(hù)等六個(gè)階段，每個(gè)階段按照線性方式進(jìn)行，當(dāng)前階段接受上一階段的工作結(jié)果，實(shí)施完成所需的工作內(nèi)容。當(dāng)前階段的結(jié)果需要驗(yàn)證，驗(yàn)證通過后，該結(jié)果作為下一階段的輸入，否則返回修改。此模型有很多變體，例如V模型等，但其典型性是只有當(dāng)當(dāng)前階段的文檔獲得認(rèn)可才可以進(jìn)入下一個(gè)階段。例如，在開發(fā)初期制定詳細(xì)的計(jì)劃，在計(jì)劃中最終產(chǎn)品己被仔細(xì)研究，并且擬定規(guī)模說明，將一切詳細(xì)資料都記錄在案，通過驗(yàn)證后需求分析才算結(jié)束，然后進(jìn)入下一階段，也就是設(shè)計(jì)階段。傳統(tǒng)開發(fā)模型的主要缺點(diǎn)有：

1） 其突出缺點(diǎn)是適應(yīng)不了一直變化的客戶需求。現(xiàn)實(shí)中的項(xiàng)目在進(jìn)行時(shí)，客戶會(huì)不停的修改需求或者增加需求，導(dǎo)致項(xiàng)目開發(fā)滯留在需求分析階段，無法有效地進(jìn)入下一階段，最終導(dǎo)致產(chǎn)品被延期。

2） 傳統(tǒng)開發(fā)模型的線性過程過于理想化，早期的錯(cuò)誤可能要等到開發(fā)后期才發(fā)現(xiàn)，例如設(shè)計(jì)階段發(fā)現(xiàn)需求的錯(cuò)誤，測(cè)試階段發(fā)現(xiàn)需求或者設(shè)計(jì)的錯(cuò)誤等，特別是開發(fā)后期才發(fā)現(xiàn)需求的錯(cuò)誤，會(huì)帶來非常嚴(yán)重的后果。

3） 客戶在產(chǎn)品計(jì)劃階段提出需求后，直到產(chǎn)品Alpha/Beta測(cè)試才能見到產(chǎn)品，發(fā)現(xiàn)與預(yù)期的相差甚遠(yuǎn)，提出大量的改進(jìn)需求，最終導(dǎo)致產(chǎn)品不成功或者被延期。

4） 傳統(tǒng)開發(fā)模型的可行性分析與計(jì)劃階段要求明確需求，從而制定產(chǎn)品的計(jì)劃與進(jìn)度表，同時(shí)明確產(chǎn)品的成本及預(yù)算。但對(duì)于需求經(jīng)常變化的項(xiàng)目，該階段的成果沒有任何意義，最終導(dǎo)致項(xiàng)目進(jìn)度、成本等不可控。

2 SCRUM敏捷開發(fā)方法

敏捷開發(fā)是一種開發(fā)方法學(xué)，可以應(yīng)對(duì)客戶快速變更的需求。它強(qiáng)調(diào)以人為核心，采用迭代的方式，循序漸進(jìn)地開發(fā)軟件。敏捷開發(fā)方法強(qiáng)調(diào)以人為本，專注于交付對(duì)客戶有價(jià)值的軟件。在高度協(xié)作的開發(fā)環(huán)境中，綜合使用迭代式和增量式開發(fā)方法，使用反饋來進(jìn)行思考、反省與總結(jié)，不斷地實(shí)現(xiàn)自我完善，從而達(dá)到軟件的完美交付。

Scrum是被廣泛使用的敏捷開發(fā)方法之一。Scrum是在十多年前由Ken chwaber 和Jeff Sutherland博士共同提出的，現(xiàn)在此方式已被眾多大中小型企業(yè)使用，其中包括摩托羅拉、谷歌、雅虎、微軟、華為、思科、SAP、GE等。Scrum是一個(gè)敏捷開發(fā)框架，是一個(gè)增量的、迭代的開發(fā)過程。在這個(gè)框架中，整個(gè)開發(fā)周期被分成若干個(gè)小的迭代周期，每個(gè)小的迭代周期稱為一個(gè)Sprint，一般最多以30天為一個(gè)周期。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品或項(xiàng)目的需求，Backlog定義產(chǎn)品的所有任務(wù)，包括功能性和非功能性的任務(wù)。在定義Sprint時(shí)，Scrum開發(fā)團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最有價(jià)值的需求進(jìn)行開發(fā)。Sprint中挑選的需求經(jīng)過Sprint計(jì)劃會(huì)議上的分析、討論和估算得到一個(gè)Sprint的任務(wù)列表，我們稱它為Sprint Backlog。在每個(gè)迭代結(jié)束時(shí)，Scrum團(tuán)隊(duì)將產(chǎn)生可交付的產(chǎn)品增量。

Scrum定義的主要角色有：

1）產(chǎn)品負(fù)責(zé)人（Product Owner）：該角色負(fù)責(zé)產(chǎn)品的遠(yuǎn)景規(guī)劃，平衡利益相關(guān)者（stakeholder）的利益，確定不同的產(chǎn)品需求和優(yōu)先級(jí)等。它是開發(fā)團(tuán)隊(duì)與客戶或最終用戶之間的聯(lián)絡(luò)點(diǎn)。

2）利益相關(guān)者/客戶（Stakeholder）：該角色與產(chǎn)品之間有直接或間接的利益關(guān)系，通常是客戶或最終用戶代表。他們負(fù)責(zé)收集產(chǎn)品需求，審查項(xiàng)目成果等。

3）Scrum負(fù)責(zé)人（Scrum Master）：該角色負(fù)責(zé)指導(dǎo)開發(fā)團(tuán)隊(duì)進(jìn)行Scrum開發(fā)與實(shí)踐。它也是開發(fā)團(tuán)隊(duì)與產(chǎn)品擁有者之間交流的聯(lián)絡(luò)點(diǎn)。

4）團(tuán)隊(duì)成員（Team Member）：即項(xiàng)目開發(fā)人員。

Scrum定義的標(biāo)準(zhǔn)流程如下：

1） 根據(jù)客戶需求，定義產(chǎn)品功能列表Backlog以及每個(gè)功能的優(yōu)先級(jí)。

2）召開Sprint計(jì)劃會(huì)議，確立下一個(gè)Sprint的目標(biāo)，劃分并確定這個(gè)Sprint內(nèi)需要完成的任務(wù)，標(biāo)注任務(wù)的優(yōu)先級(jí)并分配給每個(gè)成員。

3） 進(jìn)入Sprint開發(fā)周期，在這個(gè)周期內(nèi)，每天需要召開Scrum會(huì)議。

4） Sprint周期結(jié)束時(shí)，召開Sprint成果評(píng)審會(huì)議，將成果演示給產(chǎn)品負(fù)責(zé)人或者利益相關(guān)者。

5） 團(tuán)隊(duì)成員最后召開Sprint回顧會(huì)議，總結(jié)問題和經(jīng)驗(yàn)。

6） 這樣周而復(fù)始，按照同樣的步驟進(jìn)行下一次Sprint，直到產(chǎn)品交付。

我們將在下一章節(jié)詳細(xì)介紹大型項(xiàng)目中SCRUM的角色定義、軟件開發(fā)模型及具體的開發(fā)流程。

3 基于Scrum的大型軟件開發(fā)模型

3.1 角色定義

基于SCRUM的大型軟件開發(fā)模型中的角色、文檔及產(chǎn)品的對(duì)應(yīng)關(guān)系如圖1所示，具體角色有：

1）產(chǎn)品經(jīng)理，擔(dān)任產(chǎn)品負(fù)責(zé)人的角色，由開發(fā)方承擔(dān)，作為客戶和開發(fā)團(tuán)隊(duì)的聯(lián)絡(luò)點(diǎn)。理解客戶的需求及關(guān)注點(diǎn)，創(chuàng)建和維護(hù)產(chǎn)品的需求清單Backlog，并按照客戶要求的優(yōu)先級(jí)進(jìn)行排序，使得最重要的功能優(yōu)先實(shí)現(xiàn)。產(chǎn)品經(jīng)理還需要對(duì)每個(gè)Sprint的結(jié)果進(jìn)行評(píng)審和審批，并交付給客戶?？蛻舴答伒囊庖妼?shí)時(shí)傳達(dá)給開發(fā)團(tuán)隊(duì)，并調(diào)整下個(gè)Sprint的Backlog。

2）客戶：負(fù)責(zé)收集編寫產(chǎn)品需求，審查項(xiàng)目成果等。他們通過產(chǎn)品經(jīng)理來設(shè)定產(chǎn)品的期望，傳達(dá)產(chǎn)品的需求，設(shè)置產(chǎn)品功能的優(yōu)先級(jí)。

3）項(xiàng)目經(jīng)理，擔(dān)任Scrum負(fù)責(zé)人的角色，負(fù)責(zé)指導(dǎo)開發(fā)團(tuán)隊(duì)進(jìn)行Scrum的開發(fā)與實(shí)踐。項(xiàng)目經(jīng)理的主要職責(zé)有：

①根據(jù)每一個(gè)Sprint的目標(biāo)，從產(chǎn)品Backlog中選擇優(yōu)先級(jí)最高的需求進(jìn)行細(xì)化，制定Sprint的Backlog；

②召開Sprint計(jì)劃會(huì)議、Sprint交付產(chǎn)品的評(píng)審會(huì)和客戶反饋之后的回顧會(huì)，并根據(jù)客戶反饋調(diào)整下一個(gè)Sprint；

③協(xié)助消除項(xiàng)目中的障礙，維護(hù)障礙列表，確保Sprint的交付；

④敦促項(xiàng)目中依賴的解決，維護(hù)依賴列表；

⑤控制項(xiàng)目的風(fēng)險(xiǎn)，維護(hù)風(fēng)險(xiǎn)列表；

⑥培訓(xùn)團(tuán)隊(duì)，提高生產(chǎn)力，確保SRUM流程的執(zhí)行；

⑦評(píng)價(jià)項(xiàng)目過程的有效性、加強(qiáng)執(zhí)行，確保一切工作按照既定的規(guī)范來運(yùn)行，規(guī)劃并進(jìn)行必要的改進(jìn)。

4） 項(xiàng)目開發(fā)組：產(chǎn)品交付要依靠團(tuán)隊(duì)的努力，團(tuán)隊(duì)的職能是交叉的，包含所有角色：開發(fā)人員、測(cè)試人員、系統(tǒng)環(huán)境支撐人員、文檔編寫、界面設(shè)計(jì)等人員。SCRUM團(tuán)隊(duì)是自我組織、自我管理的，團(tuán)隊(duì)中的角色是不分等級(jí)、不固定職能的，例如開發(fā)人員也可以做測(cè)試。

3.2 基于SCRUM的大型軟件開發(fā)模型

為了提高開發(fā)的效率，并提高產(chǎn)品的質(zhì)量，基于SCRUM的大型軟件開發(fā)模型綜合了傳統(tǒng)瀑布模型、V模型等開發(fā)的優(yōu)點(diǎn)，在SCRUM開發(fā)流程中加了新的環(huán)節(jié)，并對(duì)某些流程進(jìn)行約束。圖2為基于SCRUM的大型軟件開發(fā)模型示意圖。

SCRUM中每個(gè)Sprint周期的開發(fā)不是無序的。Sprint中每一個(gè)任務(wù)的需求是明確的，建議使用瀑布模型、V模型或快速原型等進(jìn)行開發(fā)。根據(jù)功能的大小及難易程度選擇合適的開發(fā)模型。關(guān)鍵模塊或者技術(shù)難點(diǎn)，可以使用快速原型開發(fā)模型。較大的任務(wù)可以使用V模型，測(cè)試人員可以從需求分析階段就開始參與。較小的模塊可以使用瀑布模型，測(cè)試的工作等編碼完成后才開始。這里的瀑布模型與V模型的開發(fā)流程，尤其是文檔的處理，要比傳統(tǒng)的開發(fā)模型簡(jiǎn)化了很多，詳細(xì)開發(fā)流程見下一章節(jié)。

在傳統(tǒng)軟件開發(fā)模型中，大型的軟件在功能測(cè)試和系統(tǒng)測(cè)試后，產(chǎn)品要交付給客戶進(jìn)行Alpha測(cè)試和Beta測(cè)試，Alpha測(cè)試用于模擬環(huán)境下的測(cè)試，有時(shí)候需要開發(fā)者在場(chǎng)。Beta測(cè)試用于在真實(shí)環(huán)境下的測(cè)試。Alpha測(cè)試和Beta測(cè)試后，客戶反饋測(cè)試結(jié)果給開發(fā)團(tuán)隊(duì)，開發(fā)團(tuán)隊(duì)進(jìn)行問題的修復(fù)或者功能的改進(jìn)。Alpha測(cè)試和Beta測(cè)試對(duì)產(chǎn)品的質(zhì)量至關(guān)重要，我們將Alpha測(cè)試環(huán)節(jié)和Beta測(cè)試環(huán)節(jié)加入到SCRUM的開發(fā)流程中，作為最終產(chǎn)品交付前的最后兩個(gè)Sprint。

3.3 開發(fā)流程

3.3.1 產(chǎn)品 Backlog的定義

產(chǎn)品Backlog是產(chǎn)品的需求列表，列出需要產(chǎn)品的所有功能及優(yōu)先級(jí)。產(chǎn)品Backlog是客戶與產(chǎn)品經(jīng)理共同制定的?？蛻敉ㄟ^產(chǎn)品需求規(guī)范、平臺(tái)規(guī)范等文檔的形式或者郵件、會(huì)議等溝通方式提出需求，產(chǎn)品經(jīng)理作為客戶和開發(fā)團(tuán)隊(duì)的聯(lián)絡(luò)點(diǎn)，理解客戶的需求，并進(jìn)行梳理，與客戶共同制定產(chǎn)品Backlog，包括：

1）新的操作系統(tǒng)、新的平臺(tái)等，如Android平臺(tái)

2）功能方面的需求，功能點(diǎn)

3）非功能方面的需求， 如性能要求

4）問題的修復(fù)與功能的改進(jìn)，如前面產(chǎn)品出現(xiàn)的問題

5）每一個(gè)功能的優(yōu)先級(jí)，優(yōu)先級(jí)反映客戶的需求及關(guān)注點(diǎn)

3.3.2 Sprint Backlog的定義

3.3.2 Sprint的開發(fā)

Sprint Backlog被確定后，項(xiàng)目經(jīng)理給每一個(gè)功能點(diǎn)指定開發(fā)者。項(xiàng)目開發(fā)者對(duì)每個(gè)功能點(diǎn)可以使用瀑布模型、V模型或者快速原型開發(fā)模型進(jìn)行開發(fā)。如果使用V模型進(jìn)行開發(fā)，開發(fā)者可以定義需求文檔、設(shè)計(jì)文檔等，測(cè)試人員也可以定義測(cè)試需求文檔和測(cè)試用例設(shè)計(jì)文檔。這些文檔和傳統(tǒng)的瀑布模型的文檔不一樣，傳統(tǒng)的瀑布模型、V模型中，文檔編寫好后，需要經(jīng)過嚴(yán)格的審閱，審閱修改完成后，一般不能再修改，即使后期要修改，需要嚴(yán)格的流程。Sprint周期一般較短，2周到1個(gè)月左右，要完成V模型的開發(fā)，需要快捷的流程及工具的支持。開發(fā)人員定義的需求文檔，側(cè)重于需求功能的描述及對(duì)應(yīng)的驗(yàn)證規(guī)范，設(shè)計(jì)文檔側(cè)重于體系結(jié)構(gòu)及外部接口等，而且這些文檔在后期的Sprint中可以更新的，需要根據(jù)客戶的反饋，增加需求內(nèi)容或者更新需求，所以版本的控制非常重要。為了保證在該Sprint周期完成的功能復(fù)合規(guī)定的質(zhì)量標(biāo)準(zhǔn)，每一個(gè)Sprint周期測(cè)試人員都要參與。測(cè)試人員根據(jù)開發(fā)人員的需求與驗(yàn)證規(guī)范，定義測(cè)試用例。功能開發(fā)完成后，測(cè)試人員負(fù)責(zé)功能的測(cè)試。

3.3.3 Sprint的成果交付與反饋

3.3.4 Alpha測(cè)試與Beta測(cè)

產(chǎn)品所有功能完成，交付版本給客戶后，客戶進(jìn)行Alpha測(cè)試。由于產(chǎn)品開發(fā)的整個(gè)過程中，客戶都見到產(chǎn)品，Alpha測(cè)試的反饋中，客戶需求的變更非常少，更多的實(shí)際應(yīng)用環(huán)境下問題的發(fā)現(xiàn)。Alpha測(cè)試的反饋，作為一個(gè)新的Sprint，該Sprint的Backlog列出所有的反饋問題，團(tuán)隊(duì)開發(fā)的主要工作是問題的修復(fù)。修復(fù)完成后，將產(chǎn)品交付客戶進(jìn)行Beta測(cè)試。Beta測(cè)試的反饋同樣作為下一個(gè)Sprint的內(nèi)容，該Sprint完成后交予客戶進(jìn)行驗(yàn)收，驗(yàn)收通過后，產(chǎn)品進(jìn)行發(fā)布。Alpha測(cè)試與Beta測(cè)試的兩個(gè)Sprint，需要在產(chǎn)品定義階段進(jìn)行定義，客戶也可以根據(jù)需要選擇其中的一個(gè)或者全部。

4 小結(jié)

傳統(tǒng)開發(fā)模型不能適應(yīng)經(jīng)常變化的客戶需求，而且客戶在Alpha和Beta測(cè)試時(shí)才能看到產(chǎn)品，如果產(chǎn)品與用戶的預(yù)期相差甚遠(yuǎn)，再提出需求更改已經(jīng)太晚。而在SCRUM模型中，每一個(gè)Sprint都產(chǎn)生可交付的產(chǎn)品，客戶可以見到產(chǎn)品，及時(shí)校正自己的需求。對(duì)于需求不太明確或者經(jīng)常變更的項(xiàng)目，SCRUM的優(yōu)勢(shì)更為明顯，越來越多的企業(yè)使用SCRUM來開發(fā)軟件項(xiàng)目。對(duì)于需求明確的項(xiàng)目，傳統(tǒng)開發(fā)模型有質(zhì)量控制的優(yōu)勢(shì)。該文提出的基于SCRUM的大型軟件開發(fā)模型，吸取了傳統(tǒng)開發(fā)模型的優(yōu)點(diǎn)，并在開發(fā)流程中綜合使用瀑布模型、快速原型、V模型等，提高了產(chǎn)品開發(fā)的效率和質(zhì)量。

參考文獻(xiàn)：

[1] Pete Deemer， Gabrielle Benefield，使用Scrum的Agile（敏捷）項(xiàng)目管理介紹， v1.04[Z].

[2] The official SCRUM rule book[EB/OL].http：//www.scrum.org/.

[3] Mike Cohn.Succeeding with Agile：Software Development Using Scrum[Z].