1. 程式人生 > >SCRUM 敏捷開發 基礎及失敗成功案例分析

SCRUM 敏捷開發 基礎及失敗成功案例分析

 

什麼是敏捷開發方法?什麼是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的公司,無疑是瓔珞天色的團隊最能深入敏捷的精髓。

小結

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