身爲一個攻城獅如果你沒有聽說敏捷開發，那麼你可能就out了，抱着與時俱進的態度，今天我們就來學習一下敏捷開發是個什麼鬼？
敏捷開發模式由來已久，已經被無數的大公司所採用，如Google，faceboo等公司，最近國內的也掀起了敏捷開發的熱潮。下面摘取一段百度百科對敏捷開發的解釋先來認識一下。
敏捷開發以用戶的需求進化爲核心，採用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
看了上面的圖我們就能很容易理解了，它的核心思想就是：以儘可能低的成本展現產品的核心概念，用最快、最簡的方式建立一個可用的產品原型，用這個原型表達出你產品最終想要的效果，然後通過迭代來完善細節。
假如你的產品願景是一種高級出行工具，比如小轎車。傳統的產品設計思路是一步一步，從車輪、車軲轆、外殼、動力裝置、內部裝飾一個流程一個流程做起，最後得到一個完善的產品。而敏捷開發的思路，我們可能會先做一個小滑板車或者自行車，看看用戶對出行工具的認可程度。如果用戶認可我們的產品概念，我們可以接下去生產更加高級、完善的摩托車、甚至小轎車。
傳統產品迭代思路成本高、速度慢、風險大，花高成本做出來的產品用戶可能不認可；敏捷開發策略的優點在於試錯成本低、速度快、風險低，能滿足產品快速迭代的需求。
敏捷開發宣言：
1. 個體和互動 高於 流程和文檔
2. 工作的軟件 高於 詳盡的文檔
3. 客戶合作 高於 合同談判
4. 響應變化 高於 遵循計劃
核心價值觀：
1. 溝通：夠促進你團隊內部的開發人員之間溝通、還能夠促進你的團隊和你的project stakeholder之間的溝通。
2. 簡單：畫一兩張圖表來代替幾十甚至幾百行的代碼，通過這種方法，建模成爲簡化軟件和軟件（開發）過程的關鍵。這一點對開發人員而言非常重要－它簡單，容易發現出新的想法，隨着你（對軟件）的理解的加深，也能夠很容易的改進。
3. 反饋：Kent Beck在Extreme Programming Explained中有句話講得非常好：“過度自信是編程的職業病，反饋則是其處方。”通過圖表來交流你的想法，你可以快速獲得反饋，並能夠按照建議行事。
4. 謙遜：最優秀的開發人員都擁有謙遜的美德，他們總能認識到自己並不是無所不知的。事實上，無論是開發人員還是客戶，甚至所有的 project stakeholder，都有他們自己的專業領域，都能夠爲項目做出貢獻。一個有效的做法是假設參與項目的每一個人都有相同的價值，都應該被尊重。
敏捷開發的原則：
1. 快速迭代：相對那種半年一次的大版本發佈來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年僅發佈僅2~3個版本，發佈流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。
2. 讓測試人員和開發者參與需求討論：需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕鬆定義可測試的需求，將需求分組並確定優先級。 同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。
3. 編寫可測試的需求文檔：開始就要用“用戶故事”（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。
4. 多溝通，儘量減少文檔：任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裏面混得越久，越會強調良好高效的溝通的重要性。團隊要確保日常的交流，面對面溝通比郵件強得多。
5. 做好產品原型：建議使用草圖和模型來闡明用戶界面。並不是所有人都可以理解一份複雜的文檔，但人人都會看圖。
6. 及早考慮測試：及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚纔開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。
看到這裏不知道同學們有沒有對敏捷開發有一些認識呢？當然要完全的把這種開發模式運用到現實的生產中去還是需要做很多努力，我們數聚傳媒的同學們也在積極的探索這種新的開發模式，只有這樣才能更加快速高效的完成開發工作，爲客戶的提供更優秀的產品。