今日霧霾，忙於趕作業。分享一篇關於敏捷開發的好文，希望經理爸爸們喜歡~

敏捷開發的起源

在90年代末期，傳統軟體開發的方式因為其繁雜的過程，以及對文件的過於嚴格的要求，造成了很大程度上的效率下降，也就是人們所說的“重型化危機”。因為這一原因，人們開始反思傳統方法的利弊，並對其弊端進行了改進，提出了敏捷方法。

2001年2月，由Martin Fowler，Jim Highsmith等17位軟體開發專家起草的敏捷宣言發表，敏捷聯盟成立。敏捷開發作為一種新的方法正式誕生。敏捷宣言中所表述的價值觀分為四個方面：

（1）個體和互動 高於 流程和工具（2）工作的軟體 高於 詳盡的文件
（3）客戶合作 高於 合同談判
（4）響應變化 高於 遵循計劃

同時敏捷宣言還包括12條原則。這十二條原則是以上四條主要的價值觀在實際工作中的體現。

總體來說，敏捷開發作為一種新的軟體工程方法，與傳統方法相比更加註重人的因素。不再把開發者當作一個物化的，投入多少時間可以完成相應數量程式碼的程式碼開發機器；而是注重開發者之間的互動以及開發者和使用者之間的互動，同時因為增加了交流和協作使得開發的專案更加靈活和易於修改。

敏捷開發的主要特點

與傳統開發方法相比，在敏捷開發的整個過程中，有以下幾個主要的特點：

（1）敏捷開發的過程有著更強的適應性而不是預設性，從敏捷宣言的第四條響應變化高於預設計劃便可以看出來。因為軟體開發過程的本身的不可預見性，很多使用者在專案開始時不可能對於這個專案有著一個完整而明確的預期。很多對軟體的預期都在後期的修改和完善過程中產生。因此高適應性顯然更加符合軟體工程開發的實際。而敏捷開發實現其適應性的方式主要在於，第一，縮短把專案提交給使用者的週期；第二，增加使用者，業務人員，開發人員這三者之間的交流；第三，通過減少重構的成本以增加軟體的適應性。

（2）敏捷開發的過程中，更加的注重人的因素。在傳統軟體工程中，個人的因素很少的被考慮到分工中，每個個體都是隻是整個程式碼開發機器的一個小小的螺絲釘，個人的意志和創造力很大程度上的被抹去為了更好的為集體服務。而在敏捷開發過程中，每個個人的潛力被充分的考慮，應用什麼技術很大程度上直接由在第一線開發的技術人員決定；每個人的特點和創造力都可以充分地發揮，這樣開發出來的軟體更加的具有生命力，因為他融入了開發者的心血和創意，開發者不再是進行機械的乏味的堆砌，而是創造屬於自己的藝術品，這樣的條件下產生的程式碼必然在質量上更佔優勢。

（3）在敏捷開發的過程中，整個專案是測試驅動的而不是文件驅動的。不僅每個模組有著自己的相應的測試單元，開發人員在開發自己的模組的過程中必須保證自己所開發的模組可以通過這一單元的測試，並且整合測試貫穿了整個開發過程的始終。整合測試每天會進行十幾次甚至幾十次，而不是像傳統方法一樣只有當各個模組的編碼都結束了之後再進行聯合除錯。這樣，在軟體開發的程序中每一點改動所引起的問題都容嘉容易暴露出來，使得更加容易在錯誤剛剛產生的時候發現問題從而解決問題。這樣就避免了在最後整個系統完成時錯誤隱藏的太深給除錯造成極大的困難。

 敏捷過程模型的一個例項：極限程式設計

敏捷過程作為一種開發過程模型，產生了很多不同的可以應用到實際中的程式設計方法。這裡介紹一種應用的比較廣泛的開發方法，極限程式設計，來具體體現一些敏捷開發過程的特點。

極限程式設計過程分為策劃、設計、編碼和測試四個階段。

（1）策劃階段

首先在策劃階段，使用者和開發這進行交流，開發者總結出一系列“使用者故事”，描述軟體某一部分功能。之後客戶對這些功能進行優先順序排序，xp團隊評估每一個故事的成本。之後客戶和xp團隊共同決定在開發的下一個版本中將會新增哪些功能。而在版本不斷的迭代的過程中，會進行很多次這樣的策劃過程，每一次客戶都可以根據已有的功能來決定是否要新增一些功能，以及要新增哪些功能。

（2）設計階段

在設計階段，開發人員會根據使用者故事，提出這些使用者故事的實現方案。設計的過程中主要遵循簡潔的原則，也就是儘量使用簡介的表述而不是複雜的表述。而設計的另一個方面則是重構，重構是一種通過不改變程式碼的外部功能的情況下改變軟體模組的內部結構從而優化軟體系統的功能的過程。這是一種改進程式碼的設計。

在設計的這兩個層面中，我們可以看到在xp開發過程中，設計和開發是同步進行的。我們在不斷實現開始設計的過程中，同時要對到嗎進行優化也就是重新設計。這樣，大大的增強了整個軟體開發的適應性，而不是始終刻板的實現最開始的第一版設計。

（3）編碼階段

xp開發的第一件任務不是直接對初步的設計和使用者故事進行編碼，而是針對這些設計全力開發單元測試。完成了單元測試也就確定了開發者要實現的所有功能。這樣開發者就只需要全力通過單元測試，而不必在實現什麼功能上再浪費不必要的時間和精力。這正體現了敏捷開發的以測試驅動的特點。

而在敏捷開發中，很重要的一個提高效率的方式就是結對程式設計。在結對程式設計的過程中，兩個開發者共用一臺電腦，並各有分工。其中一個人進行實際的編碼實現，另一個人在旁邊考慮程式碼在巨集觀上該如何實現，比如針對什麼功能應該使用什麼樣的演算法。這樣，在編碼者工作遇到問題時，兩個人交換位置。這時在旁邊思考的人更有可能可以解決這一問題。事實上，結對程式設計的形式不必拘泥於什麼規矩。關鍵在於，兩個人共同開發的過程中，兩個人的交流可以使得大部分的問題可以在第一時間解決。並且，因為兩個人中只有一個人在進行程式設計這一項比較疲憊的工作，另一個人較為輕鬆，這樣可以保證開發效率一直保持在一個比較高的狀態。

（4）測試階段

每一個模組都通過自己的單元測試之後，開發者會將所有的模組整合到一起進行測試。這樣可以及時發現每一模組在最近一次改動之中出現的問題同時避免一些相容性問題。每一次改動一點小問題要比等到最後一次集中修改所有問題要容易得多。

敏捷開發生態系統

敏捷開發模型在實際中有著很多表現形式。極限過程開發（xp）時其中的最為廣泛應用的一種。還有很多其他的，比如：自適應軟體開發、Scrum、動態系統開發、Crystal、特徵驅動開發、精益軟體開發、敏捷建模、敏捷統一過程等。這裡只舉兩個例子介紹一下其主要的特點。

自適應軟體開發主要從整體上強調軟體專案團隊具有自我組織的動態性、人與人之間的協作、個人以及團隊的學習，從而使團隊更有可能取得成功。

Scrum開發方法，這個開發方法最大的特徵就是每日例會。在每日例會中，每個人交流自己昨天干了什麼，今天將要幹什麼，以及自己在工作中遇到了哪些問題。這樣大大地加強了團隊成員之間的交流。

我們可以看到，很多人都投入到了敏捷開發的研究和使用中。敏捷開發確實有著非常強大的生命力。

敏捷開發與傳統開發方法的比較

優勢

敏捷開發的高適應性，以人為本的特性，和輕量型的開發方法即以測試為驅動取代了以文件為驅動，這三個主要的特點，也就是敏捷開發相對與傳統開發方式的主要有點。因為他更加的靈活並且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。

劣勢

與傳統開發方式相比，敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求，而在每次新的需求產生時都可能引起整個系統的大幅度的修改。因為開發者在開發上一個版本的時候，完全沒有考慮以後的優化將要如何進行。這樣的開發方式實際的軟體開發過程中，並不一定總是有效的。

而另一個方面，敏捷開發因為缺乏很多在敏捷開發中被認為“不重要”的文件，這樣在一個大型專案比如一個作業系統開發的時候，由於其專案週期很長，所以很難保證開發的人員不更換，而沒有文件就會造成在交接的過程中出現很大的困難。