陳良才 胡章元 夏 波

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

引言

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

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

1 Scrum框架介紹

1.1 Scrum歷史

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

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

1.2 Scrum框架介紹

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

Scrum框架包括3個(gè)角色、3個(gè)工件、5個(gè)活動(dòng)、5個(gè)價(jià)值，如圖1所示。

圖1 Scrum框架圖

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

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

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

2 Scrum在軟件項(xiàng)目中的實(shí)踐

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4 三個(gè)工件的作用

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

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

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

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

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

2.5 五個(gè)活動(dòng)在項(xiàng)目中的應(yīng)用

五個(gè)活動(dòng)是指產(chǎn)品列表梳理會(huì)議、沖刺計(jì)劃會(huì)議、每日站會(huì)、沖刺評(píng)審會(huì)議、沖刺回顧會(huì)議。

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

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

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

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

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

3 Scrum實(shí)踐中應(yīng)避免的問(wèn)題

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

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

另外，SM角色，在國(guó)內(nèi)很多的公司是無(wú)法得到認(rèn)同的，因?yàn)樗炔婚_發(fā)也不測(cè)試，對(duì)產(chǎn)品沒有直接貢獻(xiàn)，因此很多國(guó)內(nèi)公司不設(shè)置這個(gè)角色，或者這個(gè)角色存在的時(shí)間很短。這樣就會(huì)落入自組織陷阱。

經(jīng)常有人認(rèn)為，自組織團(tuán)隊(duì)不需要任何管理。這個(gè)觀點(diǎn)是有問(wèn)題的。新團(tuán)隊(duì)需要由敏捷教練進(jìn)行適當(dāng)?shù)墓芾?，非命令式的引?dǎo)項(xiàng)目團(tuán)隊(duì)建成自組織團(tuán)隊(duì)。對(duì)于更加成熟的團(tuán)隊(duì)來(lái)說(shuō)，敏捷教練主要關(guān)注于確保團(tuán)隊(duì)能夠持續(xù)保持自組織。

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

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

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

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

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

4 結(jié)語(yǔ)

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

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

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