基于Scrum框架的軟件項目管理

陳良才 胡章元 夏 波

江蘇省郵電規(guī)劃設(shè)計院有限責(zé)任公司，江蘇 南京 210019

引言

傳統(tǒng)開發(fā)模型不能適應(yīng)快速變化的客戶需求，而且客戶在前期無法看到產(chǎn)品，只有到后期UAT測試或系統(tǒng)上線時才能看到。如果產(chǎn)品與用戶的預(yù)期相差甚遠(yuǎn)，再提出更改已經(jīng)太晚，提出需求變更的時間越晚，成本會成倍增加，而敏捷方法剛好可以解決這個痛點。價值驅(qū)動和擁抱變化是敏捷的本質(zhì)。在最流行的Scrum敏捷框架中，每一個Sprint都產(chǎn)生可交付的產(chǎn)品增量，客戶可以見到產(chǎn)品，及時校正自己的需求。Scrum這種短迭代持續(xù)高效交付產(chǎn)品增量的開發(fā)方法，受到越來越多的企業(yè)，特別是互聯(lián)網(wǎng)企業(yè)的青睞。

Scrum框架是目前全球最流行與最有效的敏捷項目管理理念與方法。本文就 Scrum框架內(nèi)容和實踐方法，以及實踐中需要注意的問題進(jìn)行了簡單闡述。

1 Scrum框架介紹

1.1 Scrum歷史

Scrum的雛形是由日本的Takeuchi和Nonaka兩位教授在1986年提出來的，并且用于制造業(yè)新產(chǎn)品的研發(fā)過程中。1993年，Jeff Sutherland讀到了這兩位教授新的產(chǎn)品開發(fā)方法Rugby（橄欖球）的文章。他受到啟發(fā)，結(jié)合自己多年的經(jīng)驗，與Easel公司的John Scumniotales和Jeff McKenna一起開發(fā)了一套方法，取名為Scrum（橄欖球術(shù)語，爭球的意思），并且首次將這種方法應(yīng)用于軟件開發(fā)。1995年，在奧斯汀舉辦的面向?qū)ο蠹夹g(shù) OOPSLA高峰會議上，Sutherland和Schwaber第一次向世人介紹了Scrum。

2001年2月，17位敏捷先行者起草《敏捷宣言》，成立敏捷聯(lián)盟。那時 Scrum只是眾多敏捷方法的其中一個。經(jīng)過這些年的發(fā)展，現(xiàn)在Scrum成為最流行、最有效的敏捷框架，幾乎成為敏捷的代名詞。

1.2 Scrum框架介紹

Scrum 是一個用于開發(fā)和維持復(fù)雜產(chǎn)品的框架，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成。一個短的迭代周期稱為一個Sprint或一個沖刺，每個Sprint的建議長度是2～4周（互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint）。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求。產(chǎn)品 Backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事 User Story。Scrum團(tuán)隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團(tuán)隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進(jìn)行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint Backlog。在每個迭代結(jié)束時，Scrum團(tuán)隊將遞交潛在可交付的產(chǎn)品增量。

Scrum框架包括3個角色、3個工件、5個活動、5個價值，如圖1所示。

圖1 Scrum框架圖

1.3 敏捷方法在國內(nèi)外的應(yīng)用現(xiàn)狀

根據(jù)Scrum聯(lián)盟最新發(fā)布的《2016年Scrum狀態(tài)報告》，Scrum聯(lián)盟調(diào)查了來自76個國家的2000多名受訪者，涉及15種不同行業(yè)人士。其中89%的受訪者表示正在使用Scrum框架進(jìn)行項目開發(fā)，而在2015年的調(diào)查中，這一比例只有82%。經(jīng)過一年的發(fā)展，Scrum受到了更多項目管理者和開發(fā)者的青睞。另外，43%的受訪者使用Kanban方法，23%的受訪者使用傳統(tǒng)的瀑布模型與敏捷混合方式。應(yīng)用 Scrum的項目總體成功率由2015年的62%提高到68%。

在我國，新興的互聯(lián)網(wǎng)公司和外資跨國企業(yè)應(yīng)用Scrum或其它敏捷框架方法較為廣泛，而傳統(tǒng)軟件企業(yè)使用瀑布、RUP等傳統(tǒng)方式較多。隨著更多企業(yè)認(rèn)識到了傳統(tǒng)開發(fā)方法的弊病，新的敏捷方法可以解決這些痛點后，將會有越來越多的國內(nèi)企業(yè)把目光投向敏捷方法，投向Scrum。

2 Scrum在軟件項目中的實踐

Scrum框架包括5個價值觀、3個角色、3個工件、5個活動。框架本身非常簡單，但往往能把簡單的事做好。一直做好，就非常不容易。正如亞洲首位ACSM認(rèn)證講師Vernon 所言：“Scrum is simple，but it's not easy。”

2.1 認(rèn)同敏捷宣言的價值觀

在敏捷宣言中有 4句話道出了敏捷方法的價值取向：個體與互動重于流程和工具，工作的軟件重于詳盡的文檔，客戶合作重于合同談判，響應(yīng)變化重于遵循計劃。這就是敏捷與傳統(tǒng)瀑布模型的價值觀的不同之處。在傳統(tǒng)的瀑布模型中，都是計劃驅(qū)動和文檔驅(qū)動，每個階段以文檔或代碼通過評審為結(jié)束，前面的階段無法看到可用的軟件，而從頭至尾的周期比較長。當(dāng)看到軟件時，可能若干個月以前的需求已經(jīng)變化了，或者軟件與當(dāng)初的需求出現(xiàn)偏差。這時返工的成本非常高，給項目帶來不確定的風(fēng)險非常大。

在傳統(tǒng)的瀑布模型中，最害怕需求變更，越到項目后期，需求變更難度越大，變更成本也會成倍增加。在敏捷方法中，最強(qiáng)調(diào)的就是要擁抱變化、適應(yīng)變化、將變化的成本和風(fēng)險降到最低。

2.2 認(rèn)同Scrum價值觀

作為 Scrum框架的實踐者，我們首先需要理解和認(rèn)同Scrum所追求的5個價值，即承諾、專注、開放、尊重、勇氣。這些價值觀是 Scrum框架的基石。就好比建造高樓大廈的地基，雖然不屬于建筑的組成部分，但它對保證建筑物的堅固耐久具有非常重要的作用。不理解或者不認(rèn)同這些價值觀，后續(xù)的各項活動也就不會深入理解其中的目的或者價值，會做得越來越形式化，變得有形而無神。

“承諾”是PO和開發(fā)團(tuán)隊相互給予對方的，在過程中通過緊密“合作”來促進(jìn)承諾的達(dá)成。團(tuán)隊基于團(tuán)隊的平均速率“誠實”地向 PO承諾下一個 Sprint目標(biāo)，PO在過程中充分“信任”團(tuán)隊可以交付高質(zhì)量產(chǎn)品增量，并且承諾不會干擾團(tuán)隊。

Scrum團(tuán)隊是樂觀積極、配合默契的自組織團(tuán)隊，團(tuán)隊不需要領(lǐng)導(dǎo)，彼此互相尊重、互相協(xié)作，為達(dá)成自己的承諾全身心投入。Scrum團(tuán)隊是開放的團(tuán)隊，各種資源計劃信息都是共享的、透明的，確保每個人接受到的信息是一致的，而不是殘缺的，這樣有利于團(tuán)隊對項目的統(tǒng)一理解。

2.3 三個角色在項目中的應(yīng)用

Scrum中三個角色分別是 PO（產(chǎn)品負(fù)責(zé)人）、SM（Scrum Master）、開發(fā)團(tuán)隊。首先需要明確的是SM并不是領(lǐng)導(dǎo)，SM是通過自己的個人影響力來領(lǐng)導(dǎo)團(tuán)隊，在團(tuán)隊中承擔(dān)培訓(xùn)、引導(dǎo)、輔導(dǎo)、啟發(fā)、協(xié)調(diào)等作用，最多算“服務(wù)式領(lǐng)導(dǎo)”。SM要避免通過權(quán)力來命令或者控制，否則違反了Scrum基本價值觀。實際情況下，很多SM是由原來瀑布模型中的項目經(jīng)理轉(zhuǎn)型而來的，很容易出現(xiàn)命令式的指揮團(tuán)隊。這點在轉(zhuǎn)型過程中難以避免，需要不斷深入理解Scrum價值才能做好這個角色。

SM在項目中負(fù)責(zé)監(jiān)督整個Scrum項目進(jìn)程，調(diào)整項目計劃；確保開發(fā)團(tuán)隊成員的能力能夠勝任產(chǎn)品的開發(fā)；促進(jìn)團(tuán)隊中不同角色的成員間充分交流和溝通，并負(fù)責(zé)為項目的進(jìn)行掃清障礙；保證開發(fā)團(tuán)隊不受外力的干擾和阻擾；掌握產(chǎn)品開發(fā)進(jìn)度，參與每日Scrum會議、Sprint計劃會議和 Sprint評審會議。

PO這個角色，類似于產(chǎn)品經(jīng)理，一般由精通業(yè)務(wù)和市場的人員擔(dān)任。PO需要確定產(chǎn)品的功能和完成時間，并對產(chǎn)品的收益負(fù)責(zé)，要根據(jù)市場需求確定產(chǎn)品功能的優(yōu)先級，并且有權(quán)決定接受或否決各個Sprint的工作成果。

而開發(fā)團(tuán)隊是由一群跨職能、自組織，認(rèn)同敏捷價值觀和 Scrum價值觀的人員組成的。人數(shù)盡量控制在5～9人，遵循“兩個披薩”原則，即團(tuán)隊的人數(shù)不應(yīng)多到讓兩個披薩不夠吃。人數(shù)越多，溝通成本越高，效率越低。對于人數(shù)眾多的大中型項目，可以采取多個Scrum團(tuán)隊分工協(xié)作的方式。

2.4 三個工件的作用

三個工件分別是產(chǎn)品列表Product Backlog、沖刺列表Sprint Backlog、潛在可交付的產(chǎn)品增量。

產(chǎn)品列表是由PO管理、不斷演進(jìn)的一個動態(tài)需求列表，其中每一個條目就是一個用戶故事User Story，包括功能性需求、非功能性需求、技術(shù)改進(jìn)點、待解決的問題等，并且每個條目要符合DEEP原則，即詳略得當(dāng)?shù)摹⒂楷F(xiàn)的、估算過的、排序過的。

沖刺列表是從產(chǎn)品列表中選擇數(shù)量適當(dāng)?shù)摹⒆钣袃r值、優(yōu)先級最高的User Story組成的。原則上，在一個沖刺期間不允許改變范圍內(nèi)的目標(biāo)，但是，有時候無法完全遵從這個原則。通常，我們在各個團(tuán)隊中采取的做法是：PO首先闡明變更的必要性，一切基于價值評估來說話，團(tuán)隊認(rèn)可價值后再與團(tuán)隊協(xié)商是否采用“需求置換”，或者團(tuán)隊接受這個沖刺加班完成。無論是什么結(jié)果，PO都不能威脅團(tuán)隊必須要做。

在早期的Scrum框架中，燃盡圖是工件之一；但是當(dāng)圖形燃到0點時，并不意味著可以交付出有價值的產(chǎn)品，所以“潛在可交付的產(chǎn)品增量”替代其成為Scrum工件。“潛在可交付”并不意味著構(gòu)建出的東西必須實際交付。交付是PO的業(yè)務(wù)決策，基于發(fā)布計劃來確定。

那么，燃盡圖是不是就不再重要，可以不再關(guān)注呢？答案是否定的。個人認(rèn)為，燃盡圖在沖刺過程中是需要團(tuán)隊成員共同關(guān)注的。無論是手繪還是通過工具來展示，都是沖刺過程中可視化進(jìn)度的表達(dá)方式，能幫助團(tuán)隊判斷沖刺目標(biāo)是否可達(dá)成的風(fēng)險概率。

2.5 五個活動在項目中的應(yīng)用

五個活動是指產(chǎn)品列表梳理會議、沖刺計劃會議、每日站會、沖刺評審會議、沖刺回顧會議。

產(chǎn)品列表梳理會議是 Scrum中非常重要的，而且很容易被忽略的一個會議。說它重要，是因為 Scrum開始之前就需要有準(zhǔn)備就緒的輸入。這個輸入就來自于產(chǎn)品列表梳理會議的結(jié)果，即初始的產(chǎn)品列表。只有產(chǎn)品列表準(zhǔn)備好了，才可以進(jìn)入迭代。另外，梳理會議是由PO發(fā)起或負(fù)責(zé)，可以召集開發(fā)團(tuán)隊參與，也可以只有相關(guān)的開發(fā)團(tuán)隊成員或相關(guān)的利益干系人參與。在此會議中和會議外，可以對產(chǎn)品列表進(jìn)行更新維護(hù)，維護(hù)好的產(chǎn)品列表應(yīng)是符合DEEP原則的。

沖刺計劃會議是每個沖刺第一天，團(tuán)隊要在計劃會議中確定本沖刺中需要完成的產(chǎn)品列表的哪些內(nèi)容，并且討論如何實現(xiàn)這些內(nèi)容。開發(fā)團(tuán)隊可以就實現(xiàn)的細(xì)節(jié)問題，向PO提問。根據(jù)明細(xì)的信息，估算完成這些工作所需的工作量。最后團(tuán)隊基于這些估計，承諾實現(xiàn)全部或部分內(nèi)容。此會議時長一般為Sprint周數(shù)*2小時。

每日站會的主要目的是推進(jìn)項目進(jìn)度，明確項目目標(biāo)，并促使團(tuán)隊齊心協(xié)力朝共同目標(biāo)邁進(jìn)。SM要確保這個會議每天準(zhǔn)時開始，采用站立方式，并且在15分鐘內(nèi)結(jié)束。每個成員都需要回答3個問題：自上次站會以來，完成了哪些工作？至下次站會之前，將完成哪些工作？工作中碰到哪些問題或障礙？在這個站會上，不要求解決提出來的問題。這些問題需要會后單獨溝通或組織會議溝通解決。會議應(yīng)在每天同一時間同一地點準(zhǔn)時開始和結(jié)束。這種一貫性可幫助團(tuán)隊確立一個模式。此外，團(tuán)隊還可以在開會的地方布置一個看板，把任務(wù)計劃、燃盡圖等貼在看板上，并且隨時更新。

沖刺評審會議是在沖刺結(jié)束前給PO演示并接受評價的會議，并根據(jù)反饋結(jié)果，提出新的產(chǎn)品列表。這個會議主要是檢驗沖刺的成果，檢查是否完成沖刺計劃的目標(biāo)。在可能的情況下，邀請用戶參與測試流程，并得到用戶對產(chǎn)品的認(rèn)可。此會議時長一般為Sprint周數(shù)*1小時。

沖刺回顧會議的目的是促進(jìn)Scrum團(tuán)隊在后續(xù)的沖刺中做得更好。在每次沖刺結(jié)束后，對前一個沖刺中的人、關(guān)系、過程和工具進(jìn)行檢視，找出做得好的方面和需要改進(jìn)的方面，并一同制定改進(jìn)Scrum團(tuán)隊工作方式的計劃。此會議時長一般為Sprint周數(shù)*1小時[1]。

3 Scrum實踐中應(yīng)避免的問題

3.1 SM角色定位不清或不設(shè)置

SM敏捷教練不是項目領(lǐng)導(dǎo)，但很多從傳統(tǒng)開發(fā)模式轉(zhuǎn)型過來的團(tuán)隊，一般由項目經(jīng)理擔(dān)任這一角色，經(jīng)常會用領(lǐng)導(dǎo)者和決策者的姿態(tài)與開發(fā)團(tuán)隊交流，經(jīng)常會把這個角色的職責(zé)弄得混亂不堪。設(shè)立這個角色的初衷是，他作為一個教練或引導(dǎo)者，設(shè)立在項目和客戶之間的角色，不參與團(tuán)隊的實際工作；反而，他會協(xié)助產(chǎn)品負(fù)責(zé)人，輔導(dǎo)團(tuán)隊，確保項目團(tuán)隊遵循Scrum流程。SM只負(fù)責(zé)Scrum流程能夠正確、持續(xù)的實施，發(fā)揮出它的最大效用。

另外，SM角色，在國內(nèi)很多的公司是無法得到認(rèn)同的，因為他既不開發(fā)也不測試，對產(chǎn)品沒有直接貢獻(xiàn)，因此很多國內(nèi)公司不設(shè)置這個角色，或者這個角色存在的時間很短。這樣就會落入自組織陷阱。

經(jīng)常有人認(rèn)為，自組織團(tuán)隊不需要任何管理。這個觀點是有問題的。新團(tuán)隊需要由敏捷教練進(jìn)行適當(dāng)?shù)墓芾恚敲钍降囊龑?dǎo)項目團(tuán)隊建成自組織團(tuán)隊。對于更加成熟的團(tuán)隊來說，敏捷教練主要關(guān)注于確保團(tuán)隊能夠持續(xù)保持自組織。

3.2 缺少架構(gòu)設(shè)計

忽視架構(gòu)設(shè)計是 Scrum在中國難于落地的一個原因。在Sprint開始前，會有一個產(chǎn)品列表梳理會議。這個會議是目標(biāo)承諾會，與架構(gòu)設(shè)計無關(guān)。在每個Sprint開始的計劃會議上，有兩個主題——澄清需求和設(shè)計。但時間太短，往往無法承載架構(gòu)設(shè)計。在一些大量應(yīng)用現(xiàn)成框架的產(chǎn)品開發(fā)過程中，或在一個產(chǎn)品的維護(hù)階段，還可能成功。但是，對于大型復(fù)雜產(chǎn)品開發(fā)而言，不進(jìn)行架構(gòu)設(shè)計，結(jié)果基本上是災(zāi)難性的。

目前，我國的現(xiàn)實情況基本上是詳細(xì)設(shè)計的多，架構(gòu)設(shè)計太少，而Scrum更助長了這種輕視設(shè)計的風(fēng)氣。當(dāng)然，強(qiáng)調(diào)架構(gòu)設(shè)計并不一定意味要寫很厚的架構(gòu)設(shè)計文檔，或者進(jìn)行復(fù)雜的UML建模，如何進(jìn)行架構(gòu)設(shè)計，做到什么程度，應(yīng)由團(tuán)隊自己決定。現(xiàn)在很多敏捷專家都建議在實踐敏捷方法中，增加架構(gòu)設(shè)計會議。

3.3 不可持續(xù)的工作方式

Scrum 團(tuán)隊必須對在一次 Sprint 中可以完成哪些任務(wù)、誰可以在正常的一個Sprint內(nèi)完成這些任務(wù)做出決定。敏捷最重要的目的，是通過持續(xù)不斷地交付有價值的產(chǎn)品增量使客戶滿意。有些人總是試圖在Sprint中塞進(jìn)更多的任務(wù)，這些任務(wù)超出了Scrum團(tuán)隊在額定時間內(nèi)所能完成的工作量。這就會導(dǎo)致團(tuán)隊疲于應(yīng)付，可能會擠占其他活動的時間，而造成自組織的下降。另外，過多的加班會打亂團(tuán)隊的節(jié)奏，容易造成效率低下、質(zhì)量下降、人員的耗盡以及職員的跳槽等。不能持續(xù)穩(wěn)定地交付有價值的產(chǎn)品增量，這已經(jīng)背離了敏捷的價值觀。

4 結(jié)語

Scrum框架非常簡單，但要把簡單的事持續(xù)做好，并不容易，需要整個組織認(rèn)清 Scrum能給組織帶來什么價值，也需要組織、領(lǐng)導(dǎo)以及團(tuán)隊都能認(rèn)同 Scrum價值觀，避免出現(xiàn)“照貓畫虎”。

我們在實際應(yīng)用 Scrum框架進(jìn)行軟件開發(fā)時，應(yīng)該認(rèn)同敏捷宣言中的價值觀，認(rèn)同 Scrum的價值觀，在項目開發(fā)中實踐Scrum，并且不斷探索更好的開發(fā)方式，這樣軟件開發(fā)才能夠真正地敏捷起來。

[1]鞏菁菁.基于 Scrum的敏捷框架在軟件企業(yè)中的應(yīng)用研究[D].大連：大連海事大學(xué)，2011.