什么是敏捷開發方法？什么是SCRUM？

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

那么，敏捷這個詞到底由何而來呢？在九十世紀中期，涌現了一批軟件行業的激進人士，他們反對那些以過程為本的重型軟件開發方法（例如：傳統的瀑布開發方 法）。在2001年，17位軟件業界的專家們齊聚一堂，討論正在興起的輕量級開發方法（Lightweight methods）。專家們給這類輕量級的方法學起了一個新的名字叫做敏捷，并發布了敏捷開發者宣言。

敏捷方法強調以人為本，專注于交付對客戶有價值的軟件。在高度協作的開環境中，使用迭代式的方式進行增量開發，經常使用反饋進行思考、反省和總結，不停的進行自我調整和完善。

敏捷開發方法是這些輕量級方法的總稱，它旗下有很多具體的開發過程和方法。主要的有：極限編程（XP）、特征驅動軟件開發（FDD）、SCRUM開發方法 等等。SCRUM開發方法是由Jeff Sutherland在1993年創立，Jeff也是制定敏捷宣言的17位專家之一。SCRUM借用了橄欖球運動中的術語——一個團隊拿球向前沖。

嚴格的說，SCRUM是遵循敏捷方法的一個軟件開發框架。在SCRUM框架中，融入敏捷開發的精神和思想，就被稱作SCRUM開發方法。SCRUM是一個 什么樣的開發框架呢？簡單說，它由三個角色（Role），三種會議（Ceremonie），三項工件（Artifact）組成。

• 角色（Role）：產品主管（Procuct Owner），他負責項目的商業價值；SCRUM師傅（ScrumMaster），他負責團隊的運轉和生產；以及自組織的團隊。
• 會議（Ceremonie）：迭代計劃會議，每日晨會（daily scrum meetings），迭代回顧會議。
• 工件（Artifact）：用來排列任務的優先級和跟蹤任務。待開發任務列表（product backlog），迭代任務列表（the sprint backlog），進度圖（burndown chart）

在敏捷剛出現的時候，極限編程（XP）一直是主流。但是，在敏捷方法開始在全世界流行的今天，為什么最紅火的卻是SCRUM？這是因為SCRUM更容易普 及和推廣。其實極限編程包容了SCRUM方法。我們從工程學的角度，可以把軟件開發分成兩部分：過程（分解任務，排列優先級和迭代計劃）和代碼實現（高質 量的代碼和自動化的代碼保障體系）。其中最難的就是代碼，最有直接商業價值的是過程。SCRUM則回避了最難的部分，加強和創新了最能直接體現商業價值的 過程部分。

這就是SCRUM！

失敗案例分析

我們這里借用SCRUM實施調查中的兩個詞“成功”和“失敗”。其實，我們很難定義成功和失敗。在實施調查中，失敗可以理解為使用SCRUM不當，沒有到 達預先的期望，直至最后團隊放棄了SCRUM。成功是意味著大家還在繼續使用SCRUM，從某種程度上說，就是SCRUM達到了團隊的預先期望，至少是可 以接受的期望。

我們先看第一失敗案例：某知名大型互聯網公司，被采訪者是一個叫David的工程師。

他是這樣總結失敗的原因：

“有些高層錯誤理解了Scrum和Agile，導致歪曲了某些東西，使得Agile變得形式化”

他們在項目中嘗試使用了SCRUM中的一個實踐：每日SCRUM會議。下面是David描述不了解SCRUM的項目經理，如何使用這個實踐的：

“項目經理發現這個東西挺好，就單獨把Daily Scrum拿來進行推廣；結果，這個經理并不理解什么是Scrum，他把Daily Scrum變成了Daily Report：每個員工都要在早上固定時間開Daily Scrum，然后把當天的任務告訴給他，讓他來決定工作是不是飽滿。而其他Scrum的精華部分都沒有推廣。”

有的網友分析，得出結論說失敗是因為“這家大型互聯網公司的制度和文化的問題”。當然，失敗肯定是跟這有關系，但我覺得還沒有直接上升到整個公司的制度和文化。

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

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

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

每日晨會，目的有二點：

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

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

第二個失敗案例是一個離岸開發的某創業型公司。雖然團隊比較特殊（離岸開發團隊），但這個失敗案例卻非常典型和普遍。

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

和第一個案例相比，這個案例的團隊是真真的在推行SCRUM。從表明看，大家也是在按照SCRUM框架的方式工作：有相應劃分的角色，有具體的分解任務，有會議，也有迭代（Sprint）。那又怎么會失敗呢？

顯然，他們是在照搬照套了SCRUM的框架。他們是兩個離岸的開發團隊，因為地點、時區和語言的差異，很容易就會導致溝通和交流不暢，這時候再生硬的引入SCRUM，無異是火上澆油。

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

1. 每日晨會
?????
“其 實大家都知道溝通進度的重要性，但我們雙方7、8個小時時差，那邊一上班這邊就快收拾東西走人了，就這樣還要講自己今天要做些啥，遇到啥困難，一點意思都 沒有。很快Stand-up Meeting就成了形式。后來，我們又間歇性地在自己團隊內部做Standup，但最后還是因為不能帶給我們太大價值，流于形式，就放棄了。”

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

一、 會議的時間不好。中國團隊快下班了，準備收拾回家。通過我們的實踐，發現站立會議最佳的時間是早上。比如：9點上班，會議時間可以定在9：30。早上到公 司之后，大家收個郵件，處理一下個人的事務。到點了，按時的舉行晨會，然后全身心的投入到一天的工作中。這樣，很自然，開發節奏很暢快。

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

三、 這是最重要最重要的一點：團隊的文化氛圍。說具體一點，晨會不是每天的工作報告，更不是項目經理進行工作檢查，甚至考核。項目經理有責任營造一個安全 （Safe）的會議氛圍，讓每個人都樂意說出真正發生的事情，就算是昨天遇到技術問題，沒有任何的工作成果，也能得到諒解，而不是膽顫心驚。比如：我們在 每天早上做站立會議的時候，可以端杯飲料，很輕松的圍成一圈，說說笑笑，然后會議結束，就開始一天的工作。

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

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

我們從上面的描述可以再次看出，大家是在對SCRUM有抵觸的。如果，到現在，推廣者到還不能讓大家理解、認可和接受SCRUM方法。那么，引入SCRUM，也絕不可能獲得成功，甚至會直接拖垮整個項目。

敏捷方法，需要有一個英明的領導（也許就是Scrum Master），以身作則，帶領著團隊向前沖鋒，大家齊心協力，以項目的成功作為最高奮斗目標。只有這樣，才能發揮敏捷方法的威力，只有這樣項目才可能獲得成功。

再回到迭代開發，它能給我們帶來什么樣的好處呢？

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

二、如何知道團隊在一個迭代可以完成多少任務呢？顯然，迭代只有兩周的時間，相對的計劃會很準確，而且前面一個迭代的工作量，是這個迭代最好的參照。如果是第一個迭代，根據團隊的經驗做好一個合理的2周計劃應該不難。

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

敏捷的團隊就是用這種迭代的方式，增量的進行工作。小步前進，不停的思考、反省和總結，不停的進行自我調整和完善。讓自己一步一步的變得優秀，走向卓越。

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

成功案例分析

到此，也許你會吸取上面兩個失敗案例的教訓，也認同文中的分析，覺得敏捷很實用、很有價值；也許此時，你卻在緊縮雙眉，因為敏捷的思想和精神，讓你覺得有點理想化，不切實際。

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

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

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

他們的具體做法如下：

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

無獨有偶，這些成功案例的團隊，就是通過這樣的方式進行一步一步推進，把SCRUM成功的引入到了各自的項目中。其中三個成功實施SCRUM的公司，無疑是瓔珞天色的團隊最能深入敏捷的精髓。

小結

敏捷就是一個團隊持續不斷的自我改進過程，直到那些優秀的品質成為大家的一種職業習慣——一個自組織的團隊。敏捷沒有終點，我們一直在路上。

轉載于:https://www.cnblogs.com/xh831213/archive/2008/05/20/1203455.html

總結

以上是生活随笔為你收集整理的SCRUM 敏捷开发 基础及失败成功案例分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。