SCRUM敏捷開發(fā)基礎(chǔ)及失敗成功案例分析

1、什么是敏捷開發(fā)方法什么是SCRUM有人在這個字面上下功夫，說敏捷就是反應(yīng)要靈敏，動作要快捷；有人還在字面上進行延伸，說敏捷就是又好又快，或者就是多快好??；有人說敏捷就是光寫代碼不寫文檔；有人覺得敏 捷就是沒有制度，管理松散的工作方式；有人覺得只要敏捷了，就代表高軟件交付水平。那么，敏捷這個詞到底由何而來呢在九十世紀(jì)中期，涌現(xiàn)了一批軟件行業(yè)的激進人士，他們反對那些以過程為本的重型軟件開發(fā)方法(例如：傳統(tǒng)的瀑布開發(fā)方法)。在2001年，17位軟件業(yè)界的專家們齊聚一堂，討論正在興起的輕量級開發(fā)方法(Lightweight methods )。專家們給這類輕量級的方法學(xué)起了一個新的名字叫做敏捷，并發(fā)布

2、了敏捷開發(fā)者宣言。敏捷方法強調(diào)以人為本，專注于交付對客戶有價值的軟件。在高度協(xié)作的開環(huán)境中，使用 迭代式的方式進行增量開發(fā)，經(jīng)常使用反饋進行思考、反省和總結(jié)，不停的進行自我調(diào)整和完 善。敏捷開發(fā)方法是這些輕量級方法的總稱，它旗下有很多具體的開發(fā)過程和方法。主要的有：極限編程(XP)、特征驅(qū)動軟件開發(fā)(FDD )、SCRUM開發(fā)方法 等等。SCRUM開發(fā) 方法是由Jeff Sutherland 在1993 年創(chuàng)立，Jeff也是制定敏捷宣言的 17位專家之一。SCRUM 借用了橄欖球運動中的術(shù)語 一個團隊拿球向前沖。嚴(yán)格的說，SCRUM是遵循敏捷方法的一個軟件開發(fā)框架。在 SCRUM框架中，融入

3、敏捷開發(fā)的精神和思想，就被稱作 SCRUM開發(fā)方法。SCRUM是一個什么樣的開發(fā)框架呢簡 單說，它由三個角色( Role ),三種會議(Ceremonie ),三項工件(Artifact )組成。角色(Role ):產(chǎn)品主管(Procuct Owner ),他負責(zé)項目的商業(yè)價值；SCRUM 師傅(ScrumMaster ),他負責(zé)團隊的運轉(zhuǎn)和生產(chǎn)；以及自組織的團隊。會議(Ceremonie ):迭代計劃會議，每日晨會( daily scrum meetings ),迭代回顧會 議。工件(Artifact )：用來排列任務(wù)的優(yōu)先級和跟蹤任務(wù)。待開發(fā)任務(wù)列表(product backlog ),迭

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

5、實施調(diào)查中的兩個詞 成功”和 失敗”。其實，我們很難定義成功和失 敗。在實施調(diào)查中，失敗可以理解為使用SCRUM不當(dāng)，沒有到 達預(yù)先的期望，直至最后團隊放棄了 SCRUM o成功是意味著大家還在繼續(xù)使用SCRUM ,從某種程度上說， 就是SCRUM 達到了團隊的預(yù)先期望，至少是可以接受的期望。我們先看第一失敗案例：某知名大型互聯(lián)網(wǎng)公司，被采訪者是一個叫David的工程師。他是這樣總結(jié)失敗的原因：宥些高層錯誤理解了Scrum 和Agile ，導(dǎo)致歪曲了某些東西，使得Agile 變得形式化”他們在項目中嘗試使用了SCRUM中的一個實踐：每日 SCRUM 會議。下面是 David 描述不了解SCRU

6、M的項目經(jīng)理，如何使用這個實踐的：項目經(jīng)理發(fā)現(xiàn)這個東西挺好，就單獨把Daily Scrum拿來進行推廣；結(jié)果，這個經(jīng)理并不理解什么是 Scrum ,他把Daily Scrum 變成了 Daily Report :每個員工都要在早上固 定時間開Daily Scrum ,然后把當(dāng)天的任務(wù)告訴給他，讓他來決定工作是不是飽滿。而其他 Scrum 的精華部分都沒有推廣。”有的網(wǎng)友分析，得出結(jié)論說失敗是因為這家大型互聯(lián)網(wǎng)公司的制度和文化的問題當(dāng)然，失敗肯定是跟這有關(guān)系，但我覺得還沒有直接上升到整個公司的制度和文化。了解SCRUM的人，都會很清楚。他們對SCRUM的應(yīng)用很初級，也只用了一個 SCRUM 中提

7、到的晨會（其實，在其它很多的軟件開發(fā)方法中都有這個實踐）。我們可以看出，他們的問題就是：項目經(jīng)理根本不知道什么是SCRUM o也許連自己在開發(fā)中遇到了主要問題是什么都 還不清楚就四處尋藥，甚至就給自己下了一個處方。我們就以每日晨會為例，在SCRUM中，明顯的提到，在會議中每個人只可以說三件事情：1 .我昨天做了什么2 .我今天準(zhǔn)備做什么3 .我在工作中遇到了什么障礙。每日晨會，目的有二點：1 .加強團隊交流和信息共享?；ハ嗔私獗舜硕荚谧鍪裁垂ぷ鳎瓿闪耸裁慈蝿?wù)。這樣，每日的信息傳遞，可以讓每個人可以更多的了解整個項目的業(yè)務(wù)和技術(shù)狀況。并且如果在工作中遇到障礙或問題，也可以在這時候提出來，請求大

8、家的幫助（其實，一般在敏捷團隊中，遇到問 題，都會當(dāng)場就提出來，或直接去找相關(guān)的同事，問他們有沒有處理過類似的問題，或者有沒有一些建議）。2 .促使每個人在早上做好一天的工作計劃。這樣，每個人一天的工作就會有明確具體的目 標(biāo)。這會直接提高一天的工作效率。所以，上面的這個失敗項目根本談不上是在使用SCRUM o連基本的SCRUM框架還沒有弄明白，就更談不上敏捷的精神和思想了。第二個失敗案例是一個離岸開發(fā)的某創(chuàng)業(yè)型公司。雖然團隊比較特殊 （離岸開發(fā)團隊）但這個失敗案例卻非常典型和普遍。'某一天，國外的PM突然發(fā)來幾個鏈接， 一看講的是一個聞所未聞的詞， 就是Scrum 了, 好像就給了一兩

9、天的時間去看 Scrum 的介紹文檔，然后就開 Stand-up Meeting（站立會議）?！焙偷谝粋€案例相比，這個案例的團隊是真真的在推行SCRUM o從表明看，大家也是在按照SCRUM框架的方式工作：有相應(yīng)劃分的角色，有具體的分解任務(wù)，有會議，也有迭代 （Sprint ）。那又怎么會失敗呢？顯然，他們是在照搬照套了SCRUM的框架。他們是兩個離岸的開發(fā)團隊，因為地點、時區(qū)和語言的差異，很容易就會導(dǎo)致溝通和交流不暢，這時候再生硬的引入SCRUM ,無異是火上澆油。F面我們來看看他們是如何使用SCRUM1 .每日晨會支實大家都知道溝通進度的重要性，但我們雙方7、8個小時時差，那邊一上班這邊就

10、快收拾東西走人了，就這樣還要講自己今天要做些啥，遇到啥困難，一點意思都沒有。很快Stand-up Meeting 就成了形式。后來，我們又間歇性地在自己團隊內(nèi)部做Standup ,但最后還是因為不能帶給我們太大價值，流于形式，就放棄了?！逼鋵崳诿艚莸膶嵺`中，每日晨會是最容易做，也是最有效果的實踐之一。那為什么最后會流于形式，而放棄了呢？一、會議的時間不好。中國團隊快下班了，準(zhǔn)備收拾回家。通過我們的實踐，發(fā)現(xiàn)站立會議最佳的時間是早上。比如：9點上班，會議時間可以定在9: 30。早上到公 司之后，大家收個郵件，處理一下個人的事務(wù)。到點了，按時的舉行晨會，然后全身心的投入到一天的工作中。這樣，很自

11、然，開發(fā)節(jié)奏很暢快。二、從上面的描述，明顯可以看出來。大家對它是有抵觸心理?；蛟S是在抵觸會議，或許是在抵觸SCRUM ,或許本來就已經(jīng)上火，只是借此宣泄。三、這是最重要最重要的一點：團隊的文化氛圍。說具體一點，晨會不是每天的工作報告，更不是項目經(jīng)理進行工作檢查，甚至考核。項目經(jīng)理有責(zé)任營造一個安全（Safe ）的會議氛圍，讓每個人都樂意說出真正發(fā)生的事情，就算是昨天遇到技術(shù)問題，沒有任何的工作成果，也能得到諒解，而不是膽顫心驚。比如：我們在每天早上做站立會議的時候，可以端杯飲料，很輕松的圍成一圈，說說笑笑，然后會議結(jié)束，就開始一天的工作。2 .迭代任務(wù)'在第一次使用 ScrumWork

12、s的時候，好歹 Product Owner還能來設(shè)置優(yōu)先級，我估算時間，最后決定哪些故事放到下一個Sprint 里面。到后來就只要是人，就能往Scrumworks 上扔任務(wù)，也不 知道哪些重要哪些不重要，我們自己開發(fā)人員看著辦，最后剩 下幾百個小時完不成再扔到下一個Sprint 里面去”顯然，大家的迭代過程很隨意，松松散散，沒有任何的約束。有的網(wǎng)友說這是公司制度的問題。無疑是在 頭痛醫(yī)頭，腳痛醫(yī)腳如果，這時還拿制度說事，明顯是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，沒有規(guī)章制度。其實不然，它有很多的準(zhǔn)則，要求每個人能夠自覺遵守，養(yǎng)成工作習(xí)慣，成為一種職業(yè)素質(zhì)，最終目標(biāo)是要形成一個自組織

13、的團隊。例如，誰可以往Scrumworks上扔任務(wù)這明顯是產(chǎn)品主管的職責(zé)。就算是開發(fā)人員想往上扔任務(wù)，也 應(yīng)該和產(chǎn)品主管以及整個團隊討論，明確任務(wù)的價值和優(yōu)先級之后，再決定是否可以把任務(wù)放遵守的原則，甚至可到當(dāng)前的Scrumworks 上。這是最的基本要求，這是每個團隊成員默認(rèn) 以認(rèn)為這是一個開發(fā)者最起碼的職業(yè)素質(zhì)要求。我們從上面的描述可以再次看出，大家是在對SCRUM有抵觸的。如果，到現(xiàn)在，推廣者到還不能讓大家理解、 認(rèn)可和接受 SCRUM方法。那么，引入SCRUM ,也絕不可能獲得成功， 甚至?xí)苯油峡逭麄€項目。敏捷方法，需要有一個英明的領(lǐng)導(dǎo)（也許就是Scrum Master ）,以身作則

14、，帶領(lǐng)著團隊向前沖鋒，大家齊心協(xié)力，以項目的成功作為最高奮斗目標(biāo)。只有這樣，才能發(fā)揮敏捷方法的 威力，只有這樣項目才可能獲得成功。再回到迭代開發(fā)，它能給我們帶來什么樣的好處呢？一、明確的短期目標(biāo)。 如果讓一個團隊做半年的詳細工作計劃，一定非常困難，但如果是2周，那就完全不一樣。假設(shè)，客戶有 100個東西要做，但團隊在一個迭代（一般是2周左右）中，只能完成20個東西。那么就明確的告訴客戶，一個迭代的時間，我們只可以完成20個東西，那么我們先開發(fā)其中 20個最有價值的東西好嗎？二、如何知道團隊在一個迭代可以完成多少任務(wù)呢顯然，迭代只有兩周的時間，相對的計劃會很準(zhǔn)確，而且前面一個迭代的工作量，是這個

15、迭代最好的參照。如果是第一個迭代，根據(jù)團隊的經(jīng) 驗做好一個合理的 2周計劃應(yīng)該不難。三、迭代結(jié)束之后，給客戶演示工作成果，及早獲得用戶反饋。同時團隊在一個迭代結(jié)束之后， 也會對整個開發(fā)的狀況進行思考和反省，舉行一個回顧會議， 客觀的討論前一段時間的工作，哪些地方做的好，哪些地方做得不夠好，對不好的地方，要能討論出具體可行的解決辦法。敏捷的團隊就是用這種迭代的方式，增量的進行工作。小步前進，不停的思考、反省和總結(jié)，不停的進行自我調(diào)整和完善。讓自己一步一步的變得優(yōu)秀，走向卓越?？偠灾?，如果只是學(xué)了SCRUM的形，卻沒有敏捷的意，沒有掌握敏捷的思想和精神，那么再怎么使用 SCRUM ,仍然只是在東

16、施效顰。成功案例分析至1J此，也許你會吸取上面兩個失敗案例的教訓(xùn)，也認(rèn)同文中的分析，覺得敏捷很實用、很有 價值；也許此時，你卻在緊縮雙眉，因為敏捷的思想和精神，讓你覺得有點理想化，不切實際。是的，思想和精神只可意會不可言傳這些只可以在每天的工作和問題中去領(lǐng)悟、體會和沉淀。在學(xué)習(xí)敏捷方法的時候，我們應(yīng)該盡可能多和深入的學(xué)習(xí)，并融會貫通。在具體工作的時候，我們先要忘掉學(xué)到的條條框框。首先分析自己的上下文環(huán)境，找出最主要的矛盾，然后根據(jù)團隊狀 況，通過學(xué)到的經(jīng)驗和方法將這些問題進行平衡和解決。下面我們看一下嚶珞天色是如何在項目引入SCRUM的。他們路線是這樣：我們不是采用純粹的 Scrum ,而是將

17、Agile 中的很多理念，包括 XP的部分做法，然后 結(jié)合現(xiàn)有的開發(fā)環(huán)境與要求，用Scrum 的回顧不斷地做改進，從而趟出自己的一條路。如果這個Sprint 我們回顧時覺得自己代碼Review （審查）做的不好，下個 Sprint 就會引入新的代碼Review 機制。 這個Sprint 覺得重復(fù)性的 bug較多，下個 Sprint 就會引入缺陷預(yù) 防機制。我們是自底向上，先做小范圍試點，再全面推廣，中間對過程進行不斷改進”他們的具體做法如下：其實我們一開始并沒有把Scrum 這個說法拿出來。就是首先和業(yè)務(wù)一起商量什么時候上線，商量出來的結(jié)果是每個月定期上線。于是就有了一月一個項目的進度（我們是線上服務(wù)，沒有版本的概念，有一堆需求過來，對技術(shù)來說就是在這一個月以內(nèi)完成這些需求，把這一個月以內(nèi)的工作叫一個項目）。然后為了管理，我們開始開晨會。然后為了改進，我們開始開項目總結(jié)會，把 Product review 和Team retrospective放在一起，既有產(chǎn)品經(jīng)理介紹現(xiàn)狀，也有大家討論成績，不足和挑戰(zhàn)。后來