前言

些日子，和一位朋友交流敏捷方面的話題，他所在團隊實施敏捷開發流程，由于競爭的壓力，產品需要盡快上市搶占市場，產品在匆忙開發、測試之后投入運營，上線后出現了一系列的問題，迫切需要快速的改進并投入運營；2008年是經濟困難的一年，物價飛漲，與之合作的外包公司人員大面積的流失，問題也隨之暴露出來：由于人員的快速更迭，產品知識的傳遞與銜接成為產品持續改進的重大障礙。于是他開始懷疑敏捷開發方法，困惑于敏捷開發方法該如何運作；

之前也和朋友斷斷續續的討論過實施敏捷的話題，發現大家對敏捷缺乏一個全面、深入的認識，于是想做一個全面、徹底的梳理，以便于進一步深入的交流、探討敏捷開發這個軟件工程方法；

敏捷開發是近幾年出現的新事物，其發展背景是互聯網的快速發展和開源運動的蓬勃興起；借助互聯網的快速發展，互聯網成為所有公司的無國界的巨大市場，所有公司從誕生的第一天就面臨全球市場競爭；巨大的市場規模、多樣化的用戶需求、突發性的訪問流量、海量計算基礎設施、市場能量的快速輻射等都是互聯網行業的典型特點；

我們也注意到，越來越多的公司為了實現更快的交付產品，實施全球研發部署，或外包或自建研發實驗室，實現東西半球24小時滾動研發；如火如荼的開源運動動員了幾乎全球的閑散力量，以一種更加松散的方式全球協作：開發人員開發程序，用戶參與測試并反饋Bug和修改意見，創造出巨大的生產力，已經成為影響全球軟件業市場格局的一支重要力量；

在這樣的快節奏下，傳統的軟件工程方法無法有效的整合各種研發因素：快速演進變革的社會體系、不斷變化的多樣化的用戶需求、需要更快的響應速度（針對用戶）、活躍的用戶社區、激烈的競爭要求更快的交付、研發成本的快速提高等；

怎么辦？敏捷開發就在這樣的需求驅動下破土而出，被業界廣發關注和討論，并在實踐中不斷完善；

因為敏捷開發沒有一個系統全面的定義和解釋，故無法以大篇幅的方式介紹，就以我們遇到的問題開始，逐個深入探討探討；

敏捷開發是不是一個全新的軟件工程開發方法？

不是！

敏捷開發只是一系列實踐原則，但由于它是構建在已有的軟件開發模型基礎上，雖然沒有整理出屬于它的完整的實踐體系，但是它所總結提煉出的一系列的工程實踐原則仍然能有效的指導軟件開發過程，遵循之能取得顯著的效果，故我們可以稱之為敏捷開發模型；

敏捷聯盟曬出了一系列的精煉的原則，但他們太過于抽象，缺乏可操作性，各人的理解、掌握各不相同，得到的結果也不盡相同，進而對敏捷的效用評價也不相同，有人說敏捷開發好，有人說敏捷開發不好，各執一詞，只因道不同結果亦不同；為了改善這種狀況，我們把對實踐中的敏捷開發過程進行總結和歸納，我們提出了六個更具可操作性的原則：

1、以小周期代替大周期：瀑布模型、螺旋模型、快速原型等方法都有比較長的工程周期，常常要經歷立項、需求、架構設計、詳細設計、開發、測試等大的工程周期，耗時很長，很難看到完成的日子，更別說開什么慶功會了；敏捷開發強調使用小周期：需求、設計、開發、測試、發布，快速實現、快速驗證、快速應用；

2、以小版本代替大版本：過去我們一般是在規劃階段規劃為若干個大版本，一次性整體實現，大版本實現周期長、工程復雜，由于工程整體實現技術復雜、工程周期長，風險很大，常常出現延時和夭折；敏捷開發提倡在規劃階段就根據關鍵成功因數和團隊工程能力規劃為多個小版本，團隊通常情況下只需要稍加努力就能夠完成，大部分情況下版本如期發布，這樣更有利于激勵團隊，使團隊保持良好的戰斗力；

3、以重構為基礎，系統高度組件化、接口化、可擴展，強調契約設計；敏捷歡迎變化，甚至有可能推倒重來，而能實現這一特征的唯一法門就是不斷重構，在重構中融入變化甚至是結構性的變化，重構是敏捷開發的常態行為；

敏捷開發實現的系統是低耦合、可擴展的，系統被打散為多個不同職責的組件，協作完成整個功能；組件是責任的實體，組件之間通過公開的接口交互，契約是組件間交互行為的語義表達；

4、以變化適應變化：敏捷強調小周期、小版本、快速重構，所以新需求總能很快找到并入系統的時機，新需求一旦提出即可進入開發視野，根據重要性排除優先級，即刻設計實現并測試發布；敏捷也重視團隊中人的變化，團隊猶如一個變化的泡泡，不同階段具有不同的形態，由于周期短，人員得到快速調整的時機和機會；

5、重構重視人的能動性，強調用戶參與；小版本規劃的功能少，容易實現，容易發布，使團隊很快就能嘗到成功的喜悅，團隊在成功的激勵下走向下一個成功，這個行為具有很強的社會心理學基礎：成功激勵成功；

心理學實驗表明：一個人面臨的挑戰強度太低或者強度太大，都會士氣底下，進而不重視；挑戰強度太低，輕而易舉的取得成功，兩三次之后就會提不起興趣了；挑戰強度太大則很難看到成功的希望，容易自暴自棄，也會造成士氣低；根據團隊的能力制定適度的版本規劃是很重要的，它能保持團隊良好的士氣，使成功的喜悅迷漫在成員的心頭；

用戶在表達其構想時常常無法完整的表達出來，唯有我們做出來演示給其看時，他才會說：“哦，就是這樣子；這里還需要改一下！我想法是這樣的。。。“，用戶參與能清晰、有效的獲取其真實意圖，通過不斷的確認、修改而實現用戶滿意的交付件；

6、發布是一件輕松愉快的過程；敏捷開發提倡盡早交付，也由于采用了小周期、小版本，開發過程中不斷的有版本構建出來用于測試、驗證、評價、歸檔，因為發布的過程僅僅只是從眾多的版本中挑選一個合適的版本交付給最終用戶使用；這樣的狀態下，發布過程是非常輕松愉快的；

敏捷開發最少需要開發和維護哪些文檔？

軟件終歸是人來維護，業務知識和技能的傳遞就成為產品可持續發展的一個重要因素；但現實中的情況是大多數人不喜歡編寫文檔、也不太喜歡研讀文檔，因此太多的文檔只會消耗團隊有限的時間，并不能帶來多大的好處；

敏捷開發重視文檔的作用，也重視文檔的維護；它認為文檔宜少且精煉，一般情況下建議開發并維護三份文檔：

《軟件需求規格說明書》或者《產品規格說明書》：定義軟件應該具有的功能、邊界等，使軟件相關的涉眾對軟件有一致的理解，它作為用戶同開發團隊之間共同的討論基礎，并在開發過程中不斷的更新維護；

《架構設計文檔》：軟件如何實現，內部之間是什么關系？

《項目管理計劃》：計劃如何分期實現、測試、發布等；

敏捷開發是否需要系統設計？

敏捷開發是以小周期代替大周期，小周期包括：需求、設計、開發、測試、發布，這個過程中是包括設計環節的，也就是說需要做系統設計；

由于做完整的設計需要有相對完整的資料和比較長的時間，與小周期是相對立的，因此敏捷開發不主張高度細化和完整的設計，提倡做出一個大粒度的框架性設計，一般指架構設計或者系統設計，避免在以后的重構中發生架構級別的變化，然后在逐步實現的過程中逐漸深入展開、細化；

傳統的一些設計方法比如結構化設計、面向對象分析(OOA)、面向對象設計(OOD)、自頂向下、快速原型法都是可以融入敏捷開發過程中加以使用的；

敏捷開發是否需要編寫文檔？

一份概要性的高階的文檔是用戶和開發團隊之間的契約，雙方的一致理解有助于溝通和互動；用戶只關心他要什么，不關心如何實現，更不關心實現有多難，所以我們不能奢求用戶理解我們遇到的技術問題，甚至讀懂我們的代碼或者注釋；

敏捷開發主張最起碼需要一份文檔《需求規格說明書》或者《產品規格說明書》，并不斷更新和完善之；這份文檔用于界定產品的邊界，便于和用戶溝通；

百家之言：

Jack Reeves,   2002年1月1日 《源代碼就是設計》

敏捷開發是否需要項目計劃？

商業軟件開發需要承擔獲取利潤的責任，因此對產品的功能完整性、穩定性、即時性等都有較高的要求， 它是一種有組織有目標的行為，因此它需要項目計劃，但這個計劃是一個短程計劃，根據未實現的功能情況、前一個版本的反饋和組織目標制定開發計劃；唯有這樣才能不斷的融入新的變更；

敏捷開發的迭代周期大概多長？

敏捷開發的迭代周期沒有硬性的規定，結合組織目標、功能實現情況、產品穩定性綜合決定，如果產品用戶活躍、功能實現難度小、維護復雜度低，建議以月為周期；對于規模比較大、維護復雜度高的產品，考慮以季度、半年為周期發布較為合適；

頻繁的發布會降低用戶的期望并提高用戶成本，給用戶心理上帶來額外的負擔：他會認為產品質量低，質量控制不嚴謹等；

敏捷開發為何提倡小版本？小版本有哪些優勢？

小版本的目的就是分解復雜度、降低風險，改善團隊士氣等；小版本有眾多優勢，我們一一道來：

Ⅰ、總體風險比較少：小版本變化小，總是在上一個版本基礎上局部調整和增加，技術復雜度低；由于規劃的功能較少，工作量也易于估算，所以其總體風險比較少，常常能如期發布；

Ⅱ、需求的接納能力強：由于小版本快速實現并發布測試，然后就進入下一個版本的規劃實現周期，這樣新需求一旦提出就能快速進入開發視野，就能盡快實現；

Ⅲ、測試和開發高效協作：開發和測試可以并行工作，當開發實現第一個版本時，測試設計測試方案和用例；發布第一個版本后，開發就進入下一個版本輪次，測試就應用測試方案測試剛才發布的版本，提交Bug；開發在下一個版本結束時修正所有上一輪發現的Bug，然后發布新版本，如此循環往復，開發和測試實現高效協作；

敏捷開發與重構的關系如何？

敏捷開發以重構為基礎，時時刻刻處于重構過程中；

敏捷開發為何強調團隊人員的參與、用戶的參與？

人是一切關系的主體，是生產力提升的主體；敏捷強調團隊成員的高度參與就是要統一認識，把團隊的目標變成每個人的工作目標，使之為每個團隊成員的認同，形成高度的凝聚力，以達到群策群力、高效協作的效果；

由于沒有高度細化的文檔，成員之間交換信息的唯一渠道就是面對面溝通，良好的團隊氛圍和協作關系促進這種溝通，并使消息準確有效傳達；

用戶由于缺乏專業訓練，無法清晰、準確的表達其意圖，導致需求的歧義和模糊；用戶的參與使模糊、邊界不確定的需求在互動的過程中得到確認和完善；在用戶參與過程中，我們常常可以聽到這樣的話：

“是的，就是這樣的”

“這正是我想要的。。。”

“這里需要修改一下。。。”

“我的想法是這樣的。。。”

在這個過程中，用戶承擔了一部分測試人員的角色，而開源軟件開發過程中，用戶承擔很大一部分測試工作，用戶已經成為研發團隊一員；

我們努力做的事情就是實現用戶需要的東西，并最終讓用戶喜歡它，唯有用戶喜歡它才能用好它，那么我們怎能不認真聽取用戶的意見呢？

一句話總結就是：用戶參與幫助我們做正確的事情！

怎么才能評估我們團隊和開發過程已經敏捷了？

由于敏捷開發沒有標準的可供參考的實踐過程，所以很難通過某個過程而斷定其開發過程敏捷了，那么我們如何來評估我們的團隊和開發過程是敏捷的呢？這里采用辦法是根據團隊呈現出來的氛圍、項目運作狀態、團隊成員的感性認識等方面來評估團隊和其開發過程是否敏捷，我們認為評估項目團隊和開發過程是否已經敏捷的方法如下：

1、  團隊有共同的愿景，并且對這個愿景充滿信心；

2、  團隊有明確的階段目標并且為每個成員所知曉；

3、  團隊知曉當前計劃：做什么、何時完成、預期效果等

4、  團隊任務是低耦合的，并且緊密協作；

5、  發布過程是輕松愉快的，構建版本并不斷測試是常態行為之一；

敏捷開發能縮短項目時間并提高質量嗎？

敏捷開發能縮短項目周期并提高整體質量嗎？能，但我目前無法提供量化的數據做參考，只能從幾個方面評估和推斷：敏捷開發是能縮短項目時間并提高質量的；

1、  用戶的參與幫助團隊把功能一次性完成并做正確，縮減了返工的時間；

2、  不斷的重構和測試發布能把問題發現在早期，整體質量顯著提高；

3、  過程目標導向，使團隊高度集中于項目目標，提高了生產力；

4、不斷的發布對團隊是種正向激勵，榮譽感和成功欲使團隊保持持續的激情；

附錄：敏捷聯盟發布的敏捷宣言和敏捷12原則

敏捷不是一個過程，是一類過程的統稱，它們有一個共性，就是符合敏捷價值觀，遵循敏捷的原則。

敏捷的價值觀如下：

個體和交互 勝過 過程和工具

可以工作的軟件 勝過 面面俱到的文檔

客戶合作 勝過 合同談判

響應變化 勝過 遵循計劃

由價值觀引出的12條敏捷原則：

1、我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。

2、即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

3、經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

4、在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

5、圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。

6、在團隊內部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。

7、工作的軟件是首要的進度度量標準。

8、敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。

9、不斷地關注優秀的技能和好的設計會增強敏捷能力。

10、簡單——使未完成的工作最大化的藝術——是根本的。

11、最好的構架、需求和設計出自于自組織的團隊。

12、每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。

[原文地址]敏捷釋疑 -- 敏捷開發可操作性指南