敏捷開發簡介

敏捷開發簡介

敏捷開發

在軟件工業界，敏捷開發已成爲衆多高效開發團隊的制勝之道。它不僅被許多中小公司青睞，在全球一百強的企業中，敏捷也已大行其道，受到許多資深項目管理者和開發人員的推崇。歐美軟件企業中，有近半企業已採用敏捷方法進行開發。大多數尚未應用敏捷的企業，也都對其有所瞭解，而且很多在計劃實施。中國的外企，外包公司和許多知名企業也都開始採用了敏捷方法。例如，騰訊內部幾乎所有的開發團隊都在實施敏捷。

敏捷方法給這些企業也已帶來了巨大的收益。據業內資深人士和長期從事敏捷諮詢的服務公司透露，採用敏捷開發的團隊一般會提高3-10 倍的效率，軟件的質量也有了更加可靠的保證。同時，敏捷開發的應用也給團隊內的每個成員提供了良好的發展機會。他們的技術和合作水平都能得到響應的提高。敏捷的成功來源於其方法本身的適用性和團隊對它的深入理解和合理運用。下面我們就對敏捷開發做一個簡單的介紹和討論。

　　敏捷開發由幾種輕量級的軟件開發方法組成。它們包括：極限編程（ XP ）， Scrum ，精益開發（ Lean Development ），動態系統開發方法（ DSDM ），特徵驅動開發（ Feature Driver Development ），水晶開發（ Cristal Clear ）等等。所有這些方法都具有以下共同特徵，它們也是敏捷開發的原則和方法：

1.  迭代式開發。即整個開發過程被分爲幾個迭代週期，每個迭代週期是一個定長或不定長的時間塊每個迭代週期持續的時間一般較短，通常爲一到六週。

2.  增量交付。產品是在每個迭代週期結束時被逐步交付使用，而不是在整個開發過程結束的時候一次性交付使用。每次交付的都是可以被部署到用戶應用環境中被用戶使用的、能給用戶帶來即時效益和價值的產品。

3.  開發團隊和用戶反饋推動產品開發。敏捷開發方法主張用戶能夠全程參與到整個開發過程中。這使需求變化和用戶反饋能被動態管理並及時集成到產品中。同時，團隊對於用戶的需求也能及時提供反饋意見。

4.  持續集成。新的功能或需求變化總是儘可能頻繁地被整合到產品中。一些項目是在每個迭代週期結束的時候集成， 有些項目則每天都在這麼做。  

5.  開發團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發團隊，是每個敏捷項目必不可少的條件。人是敏捷開發的核心。敏捷開發總是以人爲中心建立開發的過程和機制，而非把過程和機制強加給人。  

簡史

　　許多人認爲，相比於“傳統”的瀑布開發模式，敏捷開發是一種“現代”的開發模式。但是，實際上敏捷方法，特別是迭代和增量開發方法（ IID ）起源於 20 世紀 30 年代的一些非軟件項目。而最早引入一些敏捷方法的項目之一就是 20 世紀 60 年代初的美國航天局水星計劃。在這個項目中，一些極限編程方法如測試先行等也被使用。此後，迭代和增量開發被 IBM 聯邦系統部（ FSD ）和沃森研究中心（ Watson Research Center ）採納。有趣的是一些研究人員甚至在關於瀑布開發模式的最早的論文中發現了敏捷開發的線索。在這篇論文中，溫斯頓. 羅伊斯（ Winston Royce ）建議在一個項目中使用兩次瀑布模式，也就是使用兩次迭代。  

　　 20 世紀 70 年代，最早的有記載的使用迭代和增量開發的主要項目之一，是爲第一艘美國三叉戟潛艇開發的第一指揮和控制系統。該項目有大約一百萬行代碼，進行得非常成功。迭代和增量開發從此開始穩步發展，越來越多的項目開始使用這種開發模式。在 1976 年， Tom Gilb 在他的著作《軟件度量》（ “Software Metrics” ）一書中闡述了他的迭代和增量開發實踐，這可能就是第一部闡述這種方法的書籍。迭代和增量開發的另一次出色發揮，是在一個美國宇航局航天飛機軟件的開發項目。這個項目負責開發其航空電子設備的軟件系統。改項目由 IBM 聯邦系統部（ IBM FSD ）在 1977 至 1980 年完成。一些典型的敏捷做法，如使用 8 個周迭代以及用反饋推動開發循序漸進等方法都在該項目中得以應用。

　　 20 世紀 80 年代，更多的出版物和更多的項目應用進一步推進了迭代開發的發展。在 1895 年，巴里貝母（ Barry Boehm ）正式定義了使用迭代開發的螺旋模型（ Spiral model ）。 80 年代初，在美國國防部發生了一件有趣的事情。美國國防部一直以來都要求其軟件開發商在開發過程中使用嚴格的瀑布開發模型。但是到了 1987 年末，國防部開始“建議”使用迭代和增量開發作爲軟件開發模式。後來美國國防部的項目審查顯示，早期使用瀑布模式開發的軟件項目，有 75% 以失敗告終，有些開發出來的產品根本沒有被使用過，只有 2% 的軟件產品無需大量修改就能被正常使用。

　　 20 世紀 90 年代，推薦使用迭代和增量開發的出版物和文獻顯著增加。在經歷了多次有“瀑布心態”（ ‘waterfall mentality’ ）項目的失敗之後，美國國防部開始“要求”而不是像 80 年代那樣僅僅是“建議”他們的軟件開發商使用 IID 開發模式。 Rational 統一開發過程（ Rational Unified Process ）也是在這一時期產生並發展起來的，它具有更規範的迭代漸進過程。到 2000 年底，更多的敏捷方法被廣泛推廣並被使用於各種不同的項目中。 2001 年二月，一組由 17 位在 DSDM ， XP ， Scrum ， FSD 等領域的專家組成的代表團齊聚美國猶他州，尋找這些方法的共同點。最終，這些專家制定並宣佈了敏捷開發宣言。由此形成了現在我們所認識的敏捷開發和後來的敏捷聯盟。  

敏捷優勢

 

　　爲什麼瀑布模式多數情況下總會失敗？爲什麼我們需要敏捷開發模式？這個問題在日新月異，飛速發展的今天似乎很容易解釋。儘管瀑布模式能夠在一個迭代週期內表現優異，但是，在如何管理需求變化面前，瀑布模式卻顯得無能爲力。而事實上，大多數的軟件項目都具有以下一些特點：

Ø  在初始階段，最終用戶通常不能準確得知道他們需要什麼樣的軟件。即便知道，也很少有人能準確清楚的表達出來。

Ø  對於某些項目，在一開始，我們可以很好的定義其所有的功能，但是可能有很多細節只能隨着項目的不斷深入才能被挖掘出來。即便是我們瞭解了所有的細節，大多數人還是不能很好的處理這些細節，特別是在項目開發初期。

Ø  外部環境如客戶的業務模式，技術進步，甚至是系統的終端用戶都有可能在開發過程中不斷改變。   而預想或試圖阻止這些改變通常都是徒勞的。

Ø  在互聯網時代，許多 Web 應用程序的開發都是基於對遠景客戶的預期，而非當前用戶的實際需求。在這種情況下，變化從開始就有，而且在系統開始應用後幾乎每天都會發生。

　　敏捷方法處理需求和技術變化主要通過迭代過程來管理。在每一次迭代週期結束時，都應交付用戶一個可用的，可部署的系統。使用並體驗該系統所獲得的有價值的反饋意見將按順序，在隨後的迭代週期中和其它需求變化一起在產品中實現和集成。每次迭代週期應儘可能短，以便能及時頻繁地處理需求變化和用戶反饋。

採用敏捷開發方式將會給企業和用戶帶來諸多好處：

Ø  精確。它將帶給用戶真正需要的軟件系統。瀑布模式通常會在產品起點與最終結果之間計劃出一條直線，然後沿着直線不斷往前走。然而當項目到達終點時，用戶通常會發現那已經不是他們想去的地方。而敏捷方法則採用小步的方式向前走，每走完一步，都需要及時調整併爲下一步確定當前的方向，直到真正的終點。

Ø  質量。敏捷方法對每一次迭代週期的質量都有嚴格要求。一些敏捷方法如 XP 等，甚至使用測試驅動開發（ test-driven development ），即在正式開發功能代碼之前，先開發該功能的測試代碼。這些都對敏捷項目的整個開發週期提供了可靠的質量保證。

Ø  速度。敏捷開發提倡避免較大的前期規劃，認爲那是一種很大的浪費。因爲很多預先計劃的東西都會發生改變，大規模的前期規劃通常是徒勞的。敏捷團隊只專注於開發項目中當前最需要的，最具價值的部分。這樣能很快地投入開發。另外，較短的迭代週期使團隊成員能迅速進入開發狀態。

Ø  豐厚的投資回報率（ ROI ）。在敏捷開發過程中，最具價值的功能總是被優先開發，這樣能給客戶帶來最大的投資回報率。

Ø  高效的自我管理團隊。這既是採用敏捷開發的必然結果，也是推動敏捷開發不斷前進的動力。敏捷開發要求團隊成員必須積極主動，自我管理。在這樣的團隊中工作，每個團隊成員的技術能力，交流，社交，表達和領導能力也都能得以提高。

主要的敏捷方法

極限編程（ XP ）

　　極限編程（ XP ）的主要目的是降低需求變化的成本。它引入一系列優秀的軟件開發方法，並將它們發揮到極致。比如，爲了能及時得到用戶的反饋， XP 要求客戶代表每天都必須與開發團隊在一起。同時， XP 要求所有的編程都採用結對編程（ pair-programming ）的方式。這種方式是傳統的同行審查（ peer review ）的一種極端表現，或者可以說是它的替代方式。  

　　 XP 定義了一套簡單的開發流程，包括：編寫用戶案例，架構規範，實施規劃，迭代計劃，代碼開發，單元測試，驗收測試等等。  

　　像所有其他敏捷方法一樣， XP 預期並積極接受變化。它具有以下的價值觀或原則：

Ø  互動交流。團隊成員不是通過文檔來交流，文檔不是必須的。團隊成員之間通過日常溝通，簡單設計，測試，系統隱喻以及代碼本身來溝通產品需求和系統設計。  

Ø  反饋。反饋是一種信息的交流，能使系統更加完善。反饋也和交流密切相關，客戶的實際使用、功能測試、單元測試等都能爲開發團隊提供反饋信息。同時，開發團隊也可以通過估計和設計用戶案例的方式將信息反饋給客戶。  

Ø  簡單。 XP 提倡簡單的設計，簡單的解決方案。 XP 總是從一個簡單的系統入手，並且只創建今天，而不是明天，需要的功能模塊。因爲它認爲，創建明天需要的功能模塊可能會由於需求的變化而成爲浪費。

Ø  勇氣。 XP 在這一點所要達到的目的（我們認爲）是鼓勵一些有較高風險的良好的做法。例如，它要求程序員儘可能頻繁地重構代碼，必須刪除過時的代碼，不解決技術難題就不罷休，等等。  

Ø  團隊。 XP 提倡團隊合作，相互尊重。 XP 以建立並激勵團隊爲一項重要任務。同時它把互相尊重和實際的開發習慣相結合。比如，爲了尊重其他團隊成員的勞動成果，每個人不得將未通過單元測試的代碼集成到系統中。因此，每個人的代碼質量必須過關。

核心做法：

Ø  小規模，頻繁的版本發佈，短迭代週期。

Ø  測試驅動開發（ Test-driven development ）。

Ø  結對編程（ Pair programming ）。

Ø  持續集成（ Continuous integration ）。

Ø  每日站立會議（ Daily stand-up meeting ）。

Ø  共同擁有代碼 Collative code ownership.

Ø  系統隱喻（ System metaphor ）。

Scrum

　　 Scrum 是一個敏捷開發框架，它由一個開發過程，幾種角色以及一套規範的實施方法組成。它可以被運用於軟件開發，項目維護，也可以被用來作爲一種管理敏捷項目的框架。

　　在 Scrum 中，產品需求被定義爲產品需求積壓（ product backlogs ）。產品需求積壓可以是用戶案例，獨立的功能描述，技術要求等。所有的產品需求積壓都是從一個簡單的想法開始，並逐步被細化，直到可以被開發的程度。

　　 Scrum 將開發過程分爲多個 Sprint 週期，每個 Sprint 代表一個 2-4 周的開發週期，有固定的時間長度。首先，產品需求被分成不同的產品需求積壓條目。然後，在 Sprint 計劃會議（ Sprint planning meeting ）上，最重要或者是最具價值的產品需求積壓被優先安排到下一個 Sprint 週期中。同時，在 Sprint 計劃會上，將會預先估計所有已經分配到 Sprint 週期中的產品需求積壓的工作量，並對每個條目進行設計和任務分配。在 Sprint 開發過程中，每天開發團隊都會進行一次簡短的 Scrum 會議（ Daily Scrum Meeting ）。會議上，每個團隊成員需要彙報各自的進展情況，同時提出目前遇到的各種障礙。每個 Sprint 週期結束後，都會有一個可以被使用的系統交付給客戶，並進行 Sprint 審查會議（ Sprint review meeting ）。審查會上，開發團隊將會向客戶或最終用戶演示新的系統功能。同時，客戶會提出意見以及一些需求變化。這些可以以新的產品需求積壓的形式保留下來，並在隨後的 Sprint 週期中得以實現。 Sprint 回顧會隨後會總結上次 Sprint 週期中有哪些不足需要改進，以及有哪些值得肯定的方面。最後整個過程將從頭開始，開始一個新的 Sprint 計劃會議。

Scrum 定義了 4 種主要的角色：

Ø  產品擁有者（ Product Owner ）：該角色負責產品的遠景規劃，平衡所有利益相關者（ stakeholder ）的利益，確定不同的產品需求積壓的優先級等。它是開發團隊和客戶或最終用戶之間的聯絡點。

Ø  利益相關者（ Stakeholder ）：該角色與產品之間有直接或間接的利益關係，通常是客戶或最終用戶代表。他們負責收集編寫產品需求，審查項目成果等。

Ø  Scrum 專家（ Scrum Master ）： Scrum 專家負責指導開發團隊進行 Scrum 開發與實踐。它也是開發團隊與產品擁有者之間交流的聯絡點。  

Ø  團隊成員（ Team Member ）：即項目開發人員。

　　 Scrum 提供一個敏捷開發框架，其他許多敏捷方法都可以被集成到 Scrum 中。比如測試驅動開發（ test-driven development ）和結對編程（ pair programming ）等都可以被整合到 Scrum 中。  

精益開發（ Lean Development ）

　　精益軟件開發模式是從豐田公司的產品開發方法中演化而來。它主要包括兩個部分：一部分是核心思想及原則，另外一部分由一些在相應的工具構成。

　　精益開發的核心思想是查明和消除浪費。在軟件開發過程中，錯誤（ bugs ），沒用的功能，等待以及其他任何對實現結果沒有益處的東西都是浪費。浪費及其源頭必須被分析查明，然後設法消除。精益開發的其它原則包括 :

Ø  強調學習。軟件開發過程是一個不斷學習的過程。每個團隊成員都需要從日常的失敗，互動，交流以及信息反饋中學習，不斷改進所開發的產品和開發效率。

Ø  在最後時刻做決定。這樣可以避免在可能改變的事情上做無謂的努力，從而有效的避免浪費。

Ø  用最快的速度交付用戶。較短的迭代週期能夠加速產品的開發及交付，加快交流，提高生產力。

Ø  給團隊自主權。激勵團隊並讓所有團隊成員自我管理始終是所有敏捷方法獲得成功的基本因素之一。

Ø  誠信。確保整個系統正常工作，真正滿足客戶的需求是整個團隊需要努力堅持的誠信和和對用戶的承諾。

Ø  全局觀。精益開發強調整體優化的系統。無論開發的組織還是被開發的產品， 從整體上考慮優化比從各個局部去優化更高效。  

　　對於上述的每個原則，都有一些相應的實現工具。這些工具包括價值流圖（ Value Stream Mapping ），基於集合的開發（ set-based development ），拉系統（ pull system ），排隊論（ queuing theory ），等等。

　　和其它敏捷方法相比，精益軟件更重要的是不斷完善開發過程的一種思維方式。因此，將精益模式與其他敏捷開發模式一起使用將會取得很好的效果。

其它敏捷方法

　　動態系統開發方法（ DSDM ）是由快速應用程序開發（ RAD ）方法演變而來的敏捷開發模式。 DSDM 在普遍的敏捷價值和原則的基礎上，定義了更加詳細的流程，以涵蓋更完整的項目生命週期。它們包括項目前期活動（ pre-project activities ），項目可行性研究，功能建模，設計和開發，實施或部署，項目後期維護（ post-project maintenance ），等等。同時，每個過程都定義了諸如如何將每個功能模型轉化爲實際代碼，如何將原型交付最終用戶使用並審查，如何處理反饋信息等的詳細步驟。因此， DSDM 相比於其它敏捷方法在過程上顯得比較繁重。  

　　特徵驅動開發（ FDD ）是另一種敏捷開發方式，它將用戶的功能需求劃分成更小的功能特徵，然後逐步地在每個迭代週期中開發實現這些產品特徵。與 DSDM 方式一樣， FDD 仍然會在項目初期對整個項目做較大的規劃和建模，以獲得對該系統的全面瞭解。但是相比 DSDM 來說， FDD 在這些方面簡捷了一些。  

　　 Crystal Clear 是另一種敏捷方法。 Crystal Clear 更專注於人。相比於其他的敏捷方法，它可使人獲得更大的解放。據稱這種方法更適合於較小規模的開發小組（由 2-8 個人組成）和非關鍵項目。 Crystal Clear 定義了七種屬性。前 3 個屬性  -  頻繁的交付（ frequent delivery ），滲透交流（ osmotic communication ），反思提高（ reflective improvement ） -  反映出基本的敏捷開發做法和價值，如週期較短的迭代式開發，自我管理的開發團隊和反饋帶動增量發展等等。另外的 4 個屬性分別是：個人安全（ personal safety ），集中（ focus ），容易接觸專家用戶（ easy access to expert users ）和技術環境（ technical environment ）。其中，容易接觸專家用戶實際就是敏捷方法中提到的客戶持續參與，但 Crystal Clear 對此要求比較寬鬆。 Crystal Clear 也提供了一些通用的做法，比如，它提供了三種回顧分析的方法：訪談，問卷調查和工作組。 Crystal Clear 的過程也是相當簡單，其中涉及短的迭代週期，日常會議及持續集成等。

　　還有其他一些敏捷方法如敏捷統一過程（ Agile Unified process ），上下文驅動開發（ Context Driven Development ）， Getting Real 等。這些方法都是增量和迭代開發過程，並且重視人多過於整個過程。而各種敏捷方法的區別在於它們對敏捷的不同闡釋和不同側重。理解這些方法可以幫助我們從多個角度理解敏捷開發，並且瞭解更多的最佳應用。

如何選擇一種敏捷方法

　　選擇一種合適的方法取決於多種因素。在做出決定之前，我們需要充分考慮以下這些方面：

Ø  方法的複雜度。確保你的團隊或組織能夠應付這種複雜度。

Ø  社區和業界支持。流行的方法可能並不是你最理想的選擇，但流行的方法至少有較多的社區及行業支持，可以使你受益匪淺。

Ø  實用工具。選擇一種可以爲你提供支持工具的方法。一個良好的軟件工具可以幫助團隊有效的處理日常工作，促進團隊協作，並減少管理成本。  

Ø  你目前的開發方式以及團隊關於敏捷方法的認識程度。選擇一些與你當前開發方式比較接近的敏捷方法將有助於推動該方法的實施。

Ø  你的團隊規模。較小規模的團隊最好從簡單的方式入手。當然，這並不意味着你必須選擇那些本身就比較簡單的方法如 Crystal Clear 。你可以選擇一些相對比較全面的方法，但從簡單入手。當你的團隊規模逐漸擴大，再增加相應的細節。

Ø  你不需要只遵從一種方法。你可以爲團隊選擇一個主要的方法（如 Scrum ），然後從其他方法中借鑑對你的團隊或組織有所幫助的其他方式加以整合。

　　 敏捷總是在不斷髮展演變，因此，沒有一個人能保證目前的敏捷方法都是正確的。每個採用敏捷開發的團隊都可以通過發現並形成自己的想法和最佳實踐，對敏捷開發做出自己的貢獻。