什么是敏捷開發方法?什么是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，無異是火上澆油。

原文轉自：http://www.kjueaiud.com