什麼是敏捷開發

敏捷的本質是什麼？

「敏捷」一詞實質沒有統必定義，各家有自家的說法，本教程將讓你瞭解「敏捷」的前因後果，抓住「敏捷」本質，並能在工做中實踐「敏捷」。

「敏捷」陷阱

小甲想到某開發公司應聘開發工程師，向該公司的某開發人員打聽他們的開發方式。

小甲：請問貴公司開發模式是怎樣的？

開發人員：我們敏捷開發！不用寫文檔，寫好代碼就能夠了。

小甲心想：哇，爽啊！趕忙去應聘！

小甲已經在該公司工做了數週，他以爲很鬱悶：

無需求文檔，要作東西都是口頭分配的。

無計劃可言，想到啥就作啥。

加班不在話下，返工是屢見不鮮。

這就是敏捷開發嗎？

很多公司搞CMMI認證，推行過程改進，每每被開發人員嗤之以鼻，開發人員喜歡自由奔放有創造力的工做模式，喜歡敏捷！

然而不少號稱「敏捷」的公司，其實只是手工做坊的工做模式，想到啥就幹啥，若是你是開發人員可能還會好一點，若是你是測試人員、實施人員，在這樣的公司你簡直會以爲沒法溝通沒法工做！

到底什麼是敏捷呢？如何纔不會跌入敏捷陷阱呢？

爲何會有「敏捷」這個說法？

大學時咱們就被灌輸了這樣的知識：

生命週期模型有瀑布型、噴泉型、迭代型、螺旋型等。

通常來講，大型的、複雜的、對安全要求高的系統，應該採用傳統的瀑布型來開發，應採起重型過程。

對於中小型、須要快速投產的系統，應採用靈活的生命週期，採用敏捷的方式開發。

其實「敏捷」是相對於「重型」提出來的，重型開發有這樣的特色：（摘自互聯網）

1.刻板而嚴格控制。

2.不少活動和工件，官僚主義氣息濃重。

3.文檔繁多。

4.長期而詳細的計劃。

5.過程高於本質核心的工做。

6.面向過程而不是面向人，把人當作機械方法中的插件。

7.預見而不是適應。

因而我就頗有疑問了，若是重型開發有這樣的特色，那麼請問：對於大型的、複雜的、安全要求高的系統，也須要用具有上述特色的重型過程來開發嗎？若是是這樣，誰願意在這樣的工做環境下工做？具有這樣特色的過程對項目成功有什麼好處？

「重型」的重要特色是呆板，由於你們不喜歡呆板，喜歡靈活，因此提出了「敏捷」的說法！

我猜測：

1.重型過程實際上是一些沒有實際項目經驗的理論家搞出來的產物。

2.重型過程的出發點純粹就是爲了過程而過程。

固然上述論述純屬瞎猜，沒法證明。

每一個人對「重型」與「敏捷」的理解其實都不太同樣，這裏我用一個問題來測試一下你：

我國的航天事業取得長足的發展，讓國人振奮，請問：你認爲嫦娥工程採用的過程是重型的仍是敏捷的？

這麼重大的項目，不少人可能認爲應該是重型過程，不少人可能認爲敏捷的過程是不太嚴禁的過程，其實嫦娥工程是靈活而又十分嚴謹的工程。
你們有沒有留意到咱們火箭發射時間是如何預報的？是否是具體說某天某時某刻發射？

不是！而是說某段時間內擇機發射！「擇機發射」是多麼靈活、科學、嚴謹的發射計劃啊，徹底與咱們傳統的計劃想法不同，難道你能說這也是重型過程嗎？

所謂「重型」與「敏捷」其實都是相對的，咱們沒有必要去爭論究竟是「重型」仍是「敏捷」。咱們平時見到這麼多「重型」「敏捷」的不一樣說法，其實你們都是各自從不一樣的標準出發。

下面咱們將介紹常見的幾種敏捷開發，每種理念其實背後的道理是很相似的，咱們沒有必要去爭論哪一種方式更好，你徹底能夠吸收百家所長化爲本身的理念，按照你的想法將項目作好。

極限編程

極限編程英文叫：Extreme Programming，簡稱叫XP，最開始我接觸到XP的說法時，還以爲是Windows XP的XP呢！

我第一次學習極限編程的最佳實踐時，讓我震撼不已，後來再工做中不斷體會，有了本身的看法。我將這些最佳實踐分爲幾類：需求、設計、測試、編碼、項目管理。

需求方面的最佳實踐：

1.客戶故事：強調以客戶的語言來表達需求。

需求分析有不少科學系統的方法，採用這些系統方法有時候每每不如使用最原始的土方法，就是用客戶的陳述來表達需求！

極限編程認爲，客戶不能清晰認識本身想要什麼是很正常的事情，項目組也沒有必要成爲業務專家，因此經過這兩個最佳實踐讓客戶來引導項目。項目的開發工做講究短平快，系統會分爲多個小版本發佈，客戶通過多個版本發佈會逐步清楚認識到本身想要什麼。

這個最佳實踐鑑於我國的狀況，實際上是很難執行的。咱們的項目通常合同價錢是籤死的，項目時間也是死的，基本都沒有機會讓咱們來回折騰，若是咱們不能在項目初期精準地分析出客戶真正的需求，項目失敗的機會是很是高的。

我在實際工做中每每會經過用戶故事來獲取原始需求，而後對這些用戶故事進行提煉，提煉後的需求再跟客戶確認。我認爲項目組仍是頗有必要成爲業務專家，項目組中仍是很須要有需求分析方面的高手，項目經不起折騰啊！

2.客戶全程參與：強調從項目一開始到最後，客戶應該與項目緊密聯繫，發揮更大的做用。

這個實踐在實際工做中應該很好地貫徹，不要僅在需求階段才讓客戶介入，客戶最好就能常駐在項目小組內。下面有一些讓客戶多參與的建議作法：

1）需求階段要與各用戶反覆確認需求。

2）系統作出界面時立刻讓客戶看看。

3）項目計劃要讓客戶知道。

4）每週向客戶發送項目進展報告。

5）讓客戶參與測試軟件。

設計方面的最佳實踐只有一條：

1.簡單設計：不用長遠考慮，只要設計能保證當前功能能夠實現就行。

軟件開發的可謂變幻無窮，能將功能作出來的最簡單設計就是最好的設計，你不須要考慮之後發生變化還能重用這些設計和代碼，明天的事情鬼知道，搞定今天的事情就能夠了！

這個實踐有點劍走偏鋒，有人還會由於這個實踐不仔細思考軟件設計就編碼了，咱們有不少項目由於設計得太爛而吃了很多苦頭。實戰簡單設計時，我有這樣的一些建議：

1）對於沒有相似經驗的項目，設計應該儘可能簡單，但簡單的設計是須要嚴謹的思考獲得的，你不要認爲簡單想一個設計出來就是簡單設計。

2）思考項目設計時，應考慮有什麼東西能夠重用，同時適當考慮本項目有什麼東西可供之後的項目重用。

測試方面的最佳實踐：

1.測試驅動開發：先有測試再有開發。

咱們通常的順序是先開發後測試，然則這個實踐要求咱們先將測試想好，而後開發來知足這些測試。

這個思路其實就是目標驅動，咱們先假設軟件已經作好，那麼咱們先寫出測試用例，而後咱們編寫的開發代碼應該能經過這些測試用例。這樣思路的好處就是能讓咱們想清楚目標，全部的開發都是有針對性的，減小無用功，提升工做效率，同時由於測試已經寫好了，代碼的質量會更加有保障。

這個思路實際上是至關優秀的，但這個實踐多是這麼多最佳實踐中最難成功實施的！咱們公司曾經推行過一段時間，最終仍是失敗了結。難以施行有如下緣由：

1）開發人員廣泛沒有這麼高的編程素質。

先不說測試驅動開發，咱們每每連單元測試也作不到！測試驅動開發其實就是要求咱們先寫出單元測試代碼，而後再寫出知足單元測試代碼的代碼。

2）編碼是一個按部就班的過程，不太可能一開始接口就想好而且後面不會變了。

我本身編寫代碼也不太可能一開始就徹底想清楚類中的各個屬性方法，有時候會以爲方法名字很差會換掉，參數不太合適也會調整。若是咱們先寫出測試的代碼，其實就要求咱們先肯定各種名稱以及各種的公開接口，但每每咱們須要不斷調整，這樣就會致使開發代碼與測試代碼都須要同時調整，工做量就增大了。

3）達不到自動化測試的技術層次。

自動化測試須要工具支持，並非全部公司都具有這樣的條件。

測試驅動開發的意義仍是很重大的，我有這樣的一些實踐建議：

1）先寫開發代碼，而後寫單元測試代碼。

2）編寫代碼時，應該先想清楚類職責，類公開接口，而後再寫具體實現代碼。

3）某個類完成時或者階段性完成了一些功能時，應該立刻寫出相應的測試代碼，並保證開發代碼能經過測試。

4）若是不能針對全部類都寫出測試類，那至少應該針對重要的、核心的、被使用次數多的類編寫測試代碼。

5）單元測試應該能作到自動化。

2.自動化測試：自動化單元測試、自動化UI測試。

自動化單元測試，目前不少開發工具都支持，技術上問題不大，問題大的是你們不去執行或者說是能力不夠執行不了。

UI方面的自動化測試就有點麻煩了，有這樣兩點：

1）就算是比較好的自動UI測試工具，也難以捕捉到軟件界面上全部的控件以及動做。

2）軟件的界面常常調整是很常見的時間，界面不凍結，UI自動化測試步履維艱。

要推行100%的自動化測試難度仍是很高的，不過應該仍是儘可能自動化測試，單元自動化測試與性能自動化測試在技術上是沒有問題的，是執行的能力與決心問題。

自動化測試這個最佳實踐與測試驅動開發是緊密相關的，這兩個最佳實踐實際上是整個極限編程中最核心、最精彩、要求最嚴格的兩個實踐。只要將這兩個實踐作好，代碼隨便你改，只要能經過測試就行，不用懼怕需求變動帶來的代碼隱患，變就變，反正有自動化測試全面檢查！

編碼方面的最佳實踐：

1）重構：不講究一次將代碼寫好，但須要重構時應該絕不猶豫。

重構的意思是代碼的接口和實現功能不變，但修改代碼的具體實現，從而使代碼的結構、可讀性、性能、安全性等更好。

重構由於有測試驅動以及自動化測試這兩個實踐的支持，故不須要擔憂重構帶來的影響，萬一重構失敗，取回原來的代碼即可。

2）結對編程：兩我的，組成一對，共用一臺電腦編程。

頭次據說這個，還以爲很難想象，兩我的坐在一塊兒，只用一臺電腦，一我的寫代碼，另一個看，過一會兩我的能夠交換一下。

兩我的一塊兒寫代碼，至關於隨時在作同行評審，彷佛效率下降了，但代碼的質量獲得保障，而且能保證全部代碼至少有兩我的瞭解的。

另外要注意的是：組成一對的兩我的，應該水平至關。

這個實踐頗有意思，不過每每也是很難實踐的。

就我我的來講，我就不喜歡兩我的一塊兒編程，我以爲每一個人的思考其實很難同步的，每一個人都須要靜下心來一我的思考問題，思考後才適合與別人討論，若是思考過程也與別人在一塊兒，很難想象這個思考能有好的效果。

咱們曾經將兩位編碼新手放在一塊兒，讓他們結對編程，嘗試了這個實踐，彷佛有一點效果，但咱們後期就沒有再推行過。

3）代碼共有：每一個人寫的代碼都是屬於全體的，每一個人能夠去改別人的代碼。

這裏強調共享與進步精神，歡迎互相研究代碼，歡迎寫出更好的代碼，只要能經過測試就能夠了！這個實踐是依賴於測試驅動開發以及自動化測試這兩個實踐的，若是不能作到那兩個實踐，就不該該隨便改動別人的代碼。

4）強調編碼標準

對於這點你們應該沒啥異議了，如今有很多開發工具支持編碼標準檢查呢！

項目管理方面的最佳實踐：

1.持續集成

持續集成與微軟的「每日構建」是同樣道理的，強調咱們的軟件要隨時處在能夠編譯經過能夠發佈的狀態，持續集成讓軟件的問題提前暴露更快解決。持續集成須要必定的工具和管理措施支持，我有這樣的一些實踐建議：

1）代碼的簽入與簽出要定下嚴格的規矩，如：天天工做前先獲取最新代碼，每次簽入前必須先保證編譯經過。

2）若是能作到測試驅動測試和自動化測試，那麼還應該規定必須經過全部測試才能簽入代碼。

3）通常來講咱們沒有條件作到每日構建，也沒有這麼多工具支持，那麼至少一週要編譯一次內部版本，檢查軟件各部分的協調狀況。

2.站立會議

天天早上項目組全體開5-10分鐘會議，全部人站立講話，簡單講述昨天工做概要、今天計劃、須要別人協調或解決的問題。站立的目的就是讓你們言簡意賅，提升會議效率。天天開這個會，是保證你們有足夠的及時的口頭溝通。極限編程認爲，口頭溝通才是最有效直接的溝通。

在咱們的項目中，我也會推行站立會議，但不必定是早上，固然也不必定非要站立，可是會議必定必須是高效的！口頭溝通頗有效，但必要的記錄仍是應該有的。一些公司推行站立會議，每每是沒有會議記錄的。而個人作法是會議中若是有決定、有代辦工做，我會要求記錄下來。口頭溝通算然來得直接，但容易理解錯、容易忘記等缺點是避免不了的，應該輔以適當的書面記錄。

3.小版本發佈

分小版本屢次發佈，最符合客戶的利益，客戶能夠先使用部分功能，能夠在此基礎上更好地思考後續應該作什麼。

小版本到底應該有多小呢？國外不少書會建議3個月，不過3個月對於國內的項目來講，太長了！咱們常常要在很短的時間內作出一個大系統！

咱們公司每一個版本的發佈週期之前大概是一個月，如今已經縮小到2-3周了。

4.每週工做40小時

加班是咱們IT人的屢見不鮮，極限編程反對加班！那麼是否是咱們只要工做時間到了，哪怕不少事情沒有作完，就直接下班呢？

這條實踐的真正意思是咱們應該充分利用好工做的40小時，少作最好不作無用功，少返工。實際上咱們不少加班是由於咱們作了不少無用功、返工緻使的。

人的腦殼天天能高速運轉8小時其實已經很了不得了，若是還要加班，那麼只能帶來更多的bug，得不償失！不過咱們不少公司的老闆喜歡看到咱們這些打工仔忙，看到咱們加班，而無論實際的效果，這真是悲哀啊。

極限編程的各條實踐是有關係的，我以爲最基礎的最重要的是測試驅動與自動化測試，這兩條作不能作好，重構、代碼共用等實踐就難以實施。
極限編程不少東西很講究靈活，但測試驅動這條是最死的要求最嚴格的，整個靈活的體系其實就是靠這一條來保證質量的。不少公司實踐極限編程時，不能作到測試驅動，就簡單設計，就隨便改代碼，隨便因應需求變化而變更代碼，這些工做都沒有了質量保障的基礎。

極限編程咱們須要總體來理解各條最佳實踐，並根據實際狀況加以調整，爲我所用！

 

下面將會稍微簡單一點介紹另外了兩個比較常見的敏捷開發。

敏捷開發

有一種敏捷開發，就叫敏捷開發。你能夠認爲這種是「狹義」敏捷開發，而本文標題所說的敏捷開發是泛指全部帶有敏捷特色的開發模式。

這種敏捷開發有這樣的特色：

1.個體和交互賽過過程和工具。

以人爲本，注重編程中人的自我特長髮揮。

2.能夠工做的軟件賽過面面具到的文檔。

強調軟件開發的產品是軟件，而不是文檔。文檔是爲軟件開發服務的，而不是開發的主體。

3.客戶合做賽過合同談判。

客戶與開發者的關係是協做，不是合約。

開發者不是客戶業務的「專家」，也不是爲了開發軟件，把開發人員變成客戶業務的專家。

要適應客戶的需求，就要經過客戶合做來闡述實際的需求細節。

4.響應變化賽過遵循計劃。

設計周密是爲了最終軟件的質量，但不代表設計比實現更重要。

要適應客戶需求的不斷變化，設計也要不斷跟進，因此設計不能是「閉門造車」、「自我良好」。

要不斷根據環境的變化，修改本身的設計，指導開發的方向。

你可能會感受到這些特色與極限編程的類似與不一樣之處，同時你也會感受到這些特色不少與傳統的重型開發針鋒相對的。

RUP

統一軟件過程，英文全寫爲：Rational Unified Process

要精確理解RUP的意思仍是有點難度的，簡單談談我對RUP的理解。

按照時間順序，項目分爲初始（inception）、細化（Elaboration）、構造（Construction）、交付（Transition）四個階段，
每一個階段會有不少個小迭代。這四個階段其實很難說有明顯界限的，我以爲你們大概瞭解每一個階段的工做內容就能夠了。

按照工做的性質，項目的工做能夠分爲如下幾類：

商業建模（Business Modeling）

需求（Requirements）

分析和設計（Analysis & Design）

實現（Implementation）

測試（Test）

部署（Deployment）

配置管理與變動管理（Configuration & Change Mgmt）

項目管理（Project Management）

環境（Environment）

以上這些工做，在項目的不一樣時期工做量分佈是不太同樣的，如：商業建模、需求這些工做每每是頭大尾小，分析與設計、實現等是中間大兩頭小，項目管理、環境方面的工做一直都會持續進行。

RUP的思想打破了「需求-設計-編碼-測試」這樣的傳統瀑布模式，需求、設計、編碼、測試這些工做其實一直都在進行的，只是不一樣時間比重不同。這個思想是很符合「敏捷」的特色，也和實際狀況很是吻合。

你們理解這個意思後，我以爲徹底能夠按照本身公司的實際狀況從新定義時間上的階段，也能夠本身從新定義項目的各種工做，以及思考各種工做在項目不一樣時間的工做量分佈。

關於敏捷開發的流派還有不少，如：自適應軟件開發、水晶方法、實用編程等等，我覺不一樣流派其實本質仍是很相似的，這裏就不一一介紹了。

敏捷開發的實質是什麼？

什麼是敏捷？我想你們各有各的說法，我以爲敏捷過程應該是這樣的：

1.一個項目目標明確的過程。

2.有利於實現項目目標的事情，必定要作。

3.對項目目標沒有幫助的事情，一概不作。

4.有效和高效是最重要的項目管理原則。

5.敏捷的過程是讓人愉快、工做起來有戰鬥力的過程。

敏捷開發簡單說就是有有效的辦法去作有用的事情，過程的目的是讓項目作得更好，不是爲了過程而過程，不是用過程來「框死」項目，過程是爲項目服務的。

各家各派的敏捷方法論，其實基本道理都是這樣的，只是各自從不一樣的角度來闡述如何作軟件開發。咱們沒有必要盲目崇拜某某方法論，各類方法論也沒有必要PK，咱們應該集百家所長，爲我所用！

如何才能敏捷起來？

有時候咱們會這樣說：懶人會更聰明，由於他會想盡一切能夠偷懶的辦法。若是說，敏捷開發其實就是「懶人」想出來的，這樣也不算奇怪。

那是否是咱們就能夠作「懶人」了？固然不是了，若是你不足夠聰明你就沒有資格作「懶人」！

其實「懶人」一點都不懶，由於他的腦殼歷來是不偷閒的，他的腦殼是很勤快的。

說了這麼多，我其實想說的是：要敏捷，最關鍵在於多思考！

不要盡信各類敏捷方法論，你必須思考，必須能提出本身的疑問和看法，這樣你纔算理解這些方法論。

你須要多實踐、多充實本身的知識，這樣你纔會有更多的思考本錢，更多的打仗用的武器。

你須要多總結，總結令人進步！

敏捷很容易，只要你開始思考如何讓工做更有效，只要你開始改善你的工做方法，你已經開始敏捷了！