?

? ? 什么是敏捷開發(fā)方法？什么是SCRUM？

????
??? 有人在這個(gè)字面上下功夫，說敏捷就是反應(yīng)要靈敏，動(dòng)作要快捷；有人還在字面上進(jìn)行延伸，說敏捷就是又好又快，或者就是多快好省；有人說敏捷就是光寫代碼不寫文檔；有人覺得敏捷就是沒有制度，管理松散的工作方式；有人覺得只要敏捷了，就代表高軟件交付水平。

??? 那么，敏捷這個(gè)詞到底由何而來呢？在九十世紀(jì)中期，涌現(xiàn)了一批軟件行業(yè)的激進(jìn)人士，他們反對(duì)那些以過程為本的重型軟件開發(fā)方法（例如：傳統(tǒng)的瀑布開發(fā)方 法）。在2001年，17位軟件業(yè)界的專家們齊聚一堂，討論正在興起的輕量級(jí)開發(fā)方法（Lightweight methods）。專家們給這類輕量級(jí)的方法學(xué)起了一個(gè)新的名字叫做敏捷，并發(fā)布了敏捷開發(fā)者宣言。
????
??? 敏捷方法強(qiáng)調(diào)以人為本，專注于交付對(duì)客戶有價(jià)值的軟件。在高度協(xié)作的開環(huán)境中，使用迭代式的方式進(jìn)行增量開發(fā)，經(jīng)常使用反饋進(jìn)行思考、反省和總結(jié)，不停的進(jìn)行自我調(diào)整和完善。

??? 敏捷開發(fā)方法是這些輕量級(jí)方法的總稱，它旗下有很多具體的開發(fā)過程和方法。主要的有：極限編程（XP）、特征驅(qū)動(dòng)軟件開發(fā)（FDD）、SCRUM開發(fā)方法 等等。SCRUM開發(fā)方法是由Jeff Sutherland在1993年創(chuàng)立，Jeff也是制定敏捷宣言的17位專家之一。SCRUM借用了橄欖球運(yùn)動(dòng)中的術(shù)語——一個(gè)團(tuán)隊(duì)拿球向前沖。

??? 嚴(yán)格的說，SCRUM是遵循敏捷方法的一個(gè)軟件開發(fā)框架。在SCRUM框架中，融入敏捷開發(fā)的精神和思想，就被稱作SCRUM開發(fā)方法。SCRUM是一個(gè) 什么樣的開發(fā)框架呢？簡(jiǎn)單說，它由三個(gè)角色（Role），三種會(huì)議（Ceremonie），三項(xiàng)工件（Artifact）組成。

??? 角色（Role）：產(chǎn)品主管（Procuct Owner），他負(fù)責(zé)項(xiàng)目的商業(yè)價(jià)值；SCRUM師傅（ScrumMaster），他負(fù)責(zé)團(tuán)隊(duì)的運(yùn)轉(zhuǎn)和生產(chǎn)；以及自組織的團(tuán)隊(duì)。?
??? 會(huì)議（Ceremonie）：迭代計(jì)劃會(huì)議，每日晨會(huì)（daily scrum meetings），迭代回顧會(huì)議。?
??? 工件（Artifact）：用來排列任務(wù)的優(yōu)先級(jí)和跟蹤任務(wù)。待開發(fā)任務(wù)列表（product backlog），迭代任務(wù)列表（the sprint backlog），進(jìn)度圖（burndown chart）

??? 在敏捷剛出現(xiàn)的時(shí)候，極限編程（XP）一直是主流。但是，在敏捷方法開始在全世界流行的今天，為什么最紅火的卻是SCRUM？這是因?yàn)镾CRUM更容易普 及和推廣。其實(shí)極限編程包容了SCRUM方法。我們從工程學(xué)的角度，可以把軟件開發(fā)分成兩部分：過程（分解任務(wù)，排列優(yōu)先級(jí)和迭代計(jì)劃）和代碼實(shí)現(xiàn)（高質(zhì) 量的代碼和自動(dòng)化的代碼保障體系）。其中最難的就是代碼，最有直接商業(yè)價(jià)值的是過程。SCRUM則回避了最難的部分，加強(qiáng)和創(chuàng)新了最能直接體現(xiàn)商業(yè)價(jià)值的 過程部分。

??? 這就是SCRUM！

??? 失敗案例分析

??? 我們這里借用SCRUM實(shí)施調(diào)查中的兩個(gè)詞“成功”和“失敗”。其實(shí)，我們很難定義成功和失敗。在實(shí)施調(diào)查中，失敗可以理解為使用SCRUM不當(dāng)，沒有到 達(dá)預(yù)先的期望，直至最后團(tuán)隊(duì)放棄了SCRUM。成功是意味著大家還在繼續(xù)使用SCRUM，從某種程度上說，就是SCRUM達(dá)到了團(tuán)隊(duì)的預(yù)先期望，至少是可 以接受的期望。

??? 我們先看第一失敗案例：某知名大型互聯(lián)網(wǎng)公司，被采訪者是一個(gè)叫David的工程師。

??? 他是這樣總結(jié)失敗的原因：

??? “有些高層錯(cuò)誤理解了Scrum和Agile，導(dǎo)致歪曲了某些東西，使得Agile變得形式化”

??? 他們?cè)陧?xiàng)目中嘗試使用了SCRUM中的一個(gè)實(shí)踐：每日SCRUM會(huì)議。下面是David描述不了解SCRUM的項(xiàng)目經(jīng)理，如何使用這個(gè)實(shí)踐的：

??? “項(xiàng)目經(jīng)理發(fā)現(xiàn)這個(gè)東西挺好，就單獨(dú)把Daily Scrum拿來進(jìn)行推廣；結(jié)果，這個(gè)經(jīng)理并不理解什么是Scrum，他把Daily Scrum變成了Daily Report：每個(gè)員工都要在早上固定時(shí)間開Daily Scrum，然后把當(dāng)天的任務(wù)告訴給他，讓他來決定工作是不是飽滿。而其他Scrum的精華部分都沒有推廣。”

??? 有的網(wǎng)友分析，得出結(jié)論說失敗是因?yàn)椤斑@家大型互聯(lián)網(wǎng)公司的制度和文化的問題”。當(dāng)然，失敗肯定是跟這有關(guān)系，但我覺得還沒有直接上升到整個(gè)公司的制度和文化。

??? 了解SCRUM的人，都會(huì)很清楚。他們對(duì)SCRUM的應(yīng)用很初級(jí)，也只用了一個(gè)SCRUM中提到的晨會(huì)（其實(shí)，在其它很多的軟件開發(fā)方法中都有這個(gè)實(shí) 踐）。我們可以看出，他們的問題就是：項(xiàng)目經(jīng)理根本不知道什么是SCRUM。也許連自己在開發(fā)中遇到了主要問題是什么都還不清楚？就四處尋藥，甚至就給自 己下了一個(gè)處方。

??? 我們就以每日晨會(huì)為例，在SCRUM中，明顯的提到，在會(huì)議中每個(gè)人只可以說三件事情：

??? 1. 我昨天做了什么
??? 2. 我今天準(zhǔn)備做什么
??? 3. 我在工作中遇到了什么障礙。

??? 每日晨會(huì)，目的有二點(diǎn)：

??? 1. 加強(qiáng)團(tuán)隊(duì)交流和信息共享。互相了解彼此都在做什么工作，完成了什么任務(wù)。這樣，每日的信息傳遞，可以讓每個(gè)人可以更多的了解整個(gè)項(xiàng)目的業(yè)務(wù)和技術(shù)狀況。并 且如果在工作中遇到障礙或問題，也可以在這時(shí)候提出來，請(qǐng)求大家的幫助（其實(shí)，一般在敏捷團(tuán)隊(duì)中，遇到問題，都會(huì)當(dāng)場(chǎng)就提出來，或直接去找相關(guān)的同事，問 他們有沒有處理過類似的問題，或者有沒有一些建議）。
??? 2. 促使每個(gè)人在早上做好一天的工作計(jì)劃。這樣，每個(gè)人一天的工作就會(huì)有明確具體的目標(biāo)。這會(huì)直接提高一天的工作效率。

??? 所以，上面的這個(gè)失敗項(xiàng)目根本談不上是在使用SCRUM。連基本的SCRUM框架還沒有弄明白，就更談不上敏捷的精神和思想了。

??? 第二個(gè)失敗案例是一個(gè)離岸開發(fā)的某創(chuàng)業(yè)型公司。雖然團(tuán)隊(duì)比較特殊（離岸開發(fā)團(tuán)隊(duì)），但這個(gè)失敗案例卻非常典型和普遍。

??? “某一天，國外的PM突然發(fā)來幾個(gè)鏈接，一看講的是一個(gè)聞所未聞的詞，就是Scrum了。好像就給了一兩天的時(shí)間去看Scrum的介紹文檔，然后就開Stand-up Meeting（站立會(huì)議）。”

??? 和第一個(gè)案例相比，這個(gè)案例的團(tuán)隊(duì)是真真的在推行SCRUM。從表明看，大家也是在按照SCRUM框架的方式工作：有相應(yīng)劃分的角色，有具體的分解任務(wù)，有會(huì)議，也有迭代（Sprint）。那又怎么會(huì)失敗呢？

??? 顯然，他們是在照搬照套了SCRUM的框架。他們是兩個(gè)離岸的開發(fā)團(tuán)隊(duì)，因?yàn)榈攸c(diǎn)、時(shí)區(qū)和語言的差異，很容易就會(huì)導(dǎo)致溝通和交流不暢，這時(shí)候再生硬的引入SCRUM，無異是火上澆油。

??? 下面我們來看看他們是如何使用SCRUM。

??? 1. 每日晨會(huì)
??????
??? “其實(shí)大家都知道溝通進(jìn)度的重要性，但我們雙方7、8個(gè)小時(shí)時(shí)差，那邊一上班這邊就快收拾東西走人了，就這樣還要講自己今天要做些啥，遇到啥困難，一點(diǎn)意思都 沒有。很快Stand-up Meeting就成了形式。后來，我們又間歇性地在自己團(tuán)隊(duì)內(nèi)部做Standup，但最后還是因?yàn)椴荒軒Ыo我們太大價(jià)值，流于形式，就放棄了。”

??? 其實(shí)，在敏捷的實(shí)踐中，每日晨會(huì)是最容易做，也是最有效果的實(shí)踐之一。那為什么最后會(huì)流于形式，而放棄了呢？

??? 一、 會(huì)議的時(shí)間不好。中國團(tuán)隊(duì)快下班了，準(zhǔn)備收拾回家。通過我們的實(shí)踐，發(fā)現(xiàn)站立會(huì)議最佳的時(shí)間是早上。比如：9點(diǎn)上班，會(huì)議時(shí)間可以定在9：30。早上到公 司之后，大家收個(gè)郵件，處理一下個(gè)人的事務(wù)。到點(diǎn)了，按時(shí)的舉行晨會(huì)，然后全身心的投入到一天的工作中。這樣，很自然，開發(fā)節(jié)奏很暢快。

??? 二、從上面的描述，明顯可以看出來。大家對(duì)它是有抵觸心理。或許是在抵觸會(huì)議，或許是在抵觸SCRUM，或許本來就已經(jīng)上火，只是借此宣泄。

??? 三、 這是最重要最重要的一點(diǎn)：團(tuán)隊(duì)的文化氛圍。說具體一點(diǎn)，晨會(huì)不是每天的工作報(bào)告，更不是項(xiàng)目經(jīng)理進(jìn)行工作檢查，甚至考核。項(xiàng)目經(jīng)理有責(zé)任營造一個(gè)安全 （Safe）的會(huì)議氛圍，讓每個(gè)人都樂意說出真正發(fā)生的事情，就算是昨天遇到技術(shù)問題，沒有任何的工作成果，也能得到諒解，而不是膽顫心驚。比如：我們?cè)?每天早上做站立會(huì)議的時(shí)候，可以端杯飲料，很輕松的圍成一圈，說說笑笑，然后會(huì)議結(jié)束，就開始一天的工作。

??? 2. 迭代任務(wù)
?????
??? “在第一次使用ScrumWorks的時(shí)候，好歹Product Owner還能來設(shè)置優(yōu)先級(jí)，我們估算時(shí)間，最后決定哪些故事放到下一個(gè)Sprint里面。到后來就只要是人，就能往Scrumworks上扔任務(wù)，也不 知道哪些重要哪些不重要，我們自己開發(fā)人員看著辦，最后剩下幾百個(gè)小時(shí)完不成再扔到下一個(gè)Sprint里面去”

??? 顯然，大家的迭代過程很隨意，松松散散，沒有任何的約束。有的網(wǎng)友說這是公司制度的問題。那無疑是在“頭痛醫(yī)頭，腳痛醫(yī)腳”。如果，這時(shí)還拿制度說事，明顯 是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，沒有規(guī)章制度。其實(shí)不然，它有很多的準(zhǔn)則，要求每個(gè)人能夠自覺遵守，養(yǎng)成工作習(xí)慣，成為一種職業(yè)素 質(zhì)，最終目標(biāo)是要形成一個(gè)自組織的團(tuán)隊(duì)。例如，誰可以往Scrumworks上扔任務(wù)？這明顯是產(chǎn)品主管的職責(zé)。就算是開發(fā)人員想往上扔任務(wù)，也應(yīng)該和產(chǎn) 品主管以及整個(gè)團(tuán)隊(duì)討論，明確任務(wù)的價(jià)值和優(yōu)先級(jí)之后，再?zèng)Q定是否可以把任務(wù)放到當(dāng)前的Scrumworks上。這是最的基本要求，這是每個(gè)團(tuán)隊(duì)成員默認(rèn) 遵守的原則，甚至可以認(rèn)為這是一個(gè)開發(fā)者最起碼的職業(yè)素質(zhì)要求。

??? 我們從上面的描述可以再次看出，大家是在對(duì)SCRUM有抵觸的。如果，到現(xiàn)在，推廣者到還不能讓大家理解、認(rèn)可和接受SCRUM方法。那么，引入SCRUM，也絕不可能獲得成功，甚至?xí)苯油峡逭麄€(gè)項(xiàng)目。

??? 敏捷方法，需要有一個(gè)英明的領(lǐng)導(dǎo)（也許就是Scrum Master），以身作則，帶領(lǐng)著團(tuán)隊(duì)向前沖鋒，大家齊心協(xié)力，以項(xiàng)目的成功作為最高奮斗目標(biāo)。只有這樣，才能發(fā)揮敏捷方法的威力，只有這樣項(xiàng)目才可能獲得成功。

??? 再回到迭×××發(fā)，它能給我們帶來什么樣的好處呢？

??? 一、 明確的短期目標(biāo)。如果讓一個(gè)團(tuán)隊(duì)做半年的詳細(xì)工作計(jì)劃，一定非常困難，但如果是2周，那就完全不一樣。假設(shè)，客戶有100個(gè)東西要做，但團(tuán)隊(duì)在一個(gè)迭代 （一般是2周左右）中，只能完成20個(gè)東西。那么就明確的告訴客戶，一個(gè)迭代的時(shí)間，我們只可以完成20個(gè)東西，那么我們先開發(fā)其中20個(gè)最有價(jià)值的東西 好嗎？

??? 二、如何知道團(tuán)隊(duì)在一個(gè)迭代可以完成多少任務(wù)呢？顯然，迭代只有兩周的時(shí)間，相對(duì)的計(jì)劃會(huì)很準(zhǔn)確，而且前面一個(gè)迭代的工作量，是這個(gè)迭代最好的參照。如果是第一個(gè)迭代，根據(jù)團(tuán)隊(duì)的經(jīng)驗(yàn)做好一個(gè)合理的2周計(jì)劃應(yīng)該不難。

??? 三、迭代結(jié)束之后，給客戶演示工作成果，及早獲得用戶反饋。同時(shí)團(tuán)隊(duì)在一個(gè)迭代結(jié)束之后，也會(huì)對(duì)整個(gè)開發(fā)的狀況進(jìn)行思考和反省，舉行一個(gè)回顧會(huì)議，客觀的討論前一段時(shí)間的工作，哪些地方做的好，哪些地方做得不夠好，對(duì)不好的地方，要能討論出具體可行的解決辦法。

??? 敏捷的團(tuán)隊(duì)就是用這種迭代的方式，增量的進(jìn)行工作。小步前進(jìn)，不停的思考、反省和總結(jié)，不停的進(jìn)行自我調(diào)整和完善。讓自己一步一步的變得優(yōu)秀，走向卓越。

??? 總而言之，如果只是學(xué)了SCRUM的形，卻沒有敏捷的意，沒有掌握敏捷的思想和精神，那么再怎么使用SCRUM，仍然只是在東施效顰。

??? 成功案例分析

??? 到此，也許你會(huì)吸取上面兩個(gè)失敗案例的教訓(xùn)，也認(rèn)同文中的分析，覺得敏捷很實(shí)用、很有價(jià)值；也許此時(shí)，你卻在緊縮雙眉，因?yàn)槊艚莸乃枷牒途?#xff0c;讓你覺得有點(diǎn)理想化，不切實(shí)際。

??? 是的，思想和精神只可意會(huì)不可言傳。這些只可以在每天的工作和問題中去領(lǐng)悟、體會(huì)和沉淀。在學(xué)習(xí)敏捷方法的時(shí)候，我們 應(yīng)該盡可能多和深入的學(xué)習(xí)，并融會(huì)貫通。在具體工作的時(shí)候，我們先要忘掉學(xué)到的條條框框。首先分析自己的上下文環(huán)境，找出最主要的矛盾，然后根據(jù)團(tuán)隊(duì)狀 況，通過學(xué)到的經(jīng)驗(yàn)和方法將這些問題進(jìn)行平衡和解決。

??? 下面我們看一下瓔珞天色是如何在項(xiàng)目引入SCRUM的。他們路線是這樣：

??? “我們不是采用純粹的Scrum，而是將Agile中的很多理念，包括XP的部分做法，然后結(jié)合現(xiàn)有的開發(fā)環(huán)境與要求，用Scrum的回顧不斷地做改進(jìn)， 從而趟出自己的一條路。如果這個(gè)Sprint我們回顧時(shí)覺得自己代碼Review（審查）做的不好，下個(gè)Sprint就會(huì)引入新的代碼Review機(jī)制。 這個(gè)Sprint覺得重復(fù)性的bug較多，下個(gè)Sprint就會(huì)引入缺陷預(yù)防機(jī)制。我們是自底向上，先做小范圍試點(diǎn)，再全面推廣，中間對(duì)過程進(jìn)行不斷改進(jìn)”

??? 他們的具體做法如下：

??? “其實(shí)我們一開始并沒有把Scrum這個(gè)說法拿出來。就是首先和業(yè)務(wù)一起商量什么時(shí)候上線，商量出來的結(jié)果是每個(gè)月定期上線。于是就有了一月一個(gè)項(xiàng)目的進(jìn) 度（我們是線上服務(wù)，沒有版本的概念，有一堆需求過來，對(duì)技術(shù)來說就是在這一個(gè)月以內(nèi)完成這些需求，把這一個(gè)月以內(nèi)的工作叫一個(gè)項(xiàng)目）。然后為了管理，我 們開始開晨會(huì)。然后為了改進(jìn)，我們開始開項(xiàng)目總結(jié)會(huì)，把Product review和Team retrospective放在一起，既有產(chǎn)品經(jīng)理介紹現(xiàn)狀，也有大家討論成績(jī)，不足和挑戰(zhàn)。后來總結(jié)會(huì)上覺得質(zhì)量不好，我們加入了單元測(cè)試和代碼 Review機(jī)制。至于計(jì)劃會(huì)議，一開始我們就采用的Scrum的方法。項(xiàng)目小，MS Project太難調(diào)。我們就更換了Scrum的Excel計(jì)劃表，后來又換了Xplanner。”

??? 無獨(dú)有偶，這些成功案例的團(tuán)隊(duì)，就是通過這樣的方式進(jìn)行一步一步推進(jìn)，把SCRUM成功的引入到了各自的項(xiàng)目中。其中三個(gè)成功實(shí)施SCRUM的公司，無疑是瓔珞天色的團(tuán)隊(duì)最能深入敏捷的精髓。

??? 小結(jié)

??? 敏捷就是一個(gè)團(tuán)隊(duì)持續(xù)不斷的自我改進(jìn)過程，直到那些優(yōu)秀的品質(zhì)成為大家的一種職業(yè)習(xí)慣——一個(gè)自組織的團(tuán)隊(duì)。敏捷沒有終點(diǎn)，我們一直在路上。

?

<!-- -->

轉(zhuǎn)載于:https://blog.51cto.com/lietu/1060396

總結(jié)

以上是生活随笔為你收集整理的Scrum失败/成功案例分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。