在資訊科技高速發展的今天，有很多的開發任何要求開發人員增量交付，迭代式開發，能夠持續整合。很顯然傳統的瀑布開發模式已經不能滿足需要了，於是，敏捷開發這種模式就出現了。


　　接觸過敏捷開發的朋友可能會知道，敏捷開發有如下的價值觀：


　　個體與互動 勝於 過程與工具，可工作軟體 勝於 複雜文件


　　使用者協作 勝於 合同談判，響應變化 勝於 遵循計劃


　　下面新霸哥將會用一個真實的案例的給大家講講敏捷開發。


　　每天早晨上班前一項重要的任務那就是晨會（由於時間很短，所以大家都是站立開會的），主要就是回報一下昨天自己的工作情況，在工作過程中遇到的問題，有沒有解決，需要誰來幫助，同時還要講講自己今天將要計劃做的事情。對於提出的問題大家共同討論，如果能夠及時解決的就現場解決，不能解決的就會後協調處理，因為每個人的時間是寶貴的，這個高效的會議的目的就是了解組內成員的工作進度和工作態度，同時也能鍛鍊自己的溝通和表達能力。


　　會議結束後，大家各自忙自己的任務了。由於在開發的過程中採用的是專案中劃分出很多的獨立模組，每個人負責的模組都是不一樣的。因為迭代模式中的每個模組交付時都必須是獨立可執行的也是整合可測試的，所以，功能程式碼這一塊在測試環境整合測試無誤後該模組才算驗收通過。

　　開發人員編碼工作完成後就沒有事情做了嗎？其實不是這樣的，因為測試人員會在測試環境對各個模組進行測試，如果發現問題會及時的在bug反饋系統中，開發人員看到有自己相關的bug要及時的反饋，這樣才能保證系統正常執行。

　　迭代開發中一個星期後，相關的團隊成員的編碼工作基本上完成了或完成了大半。這時候專案經理會組織一個開發人員會議，就是開發人員坐到一個會議室裡面瞪著大眼在投影儀上找bug或編碼規範問題。因為團隊的力量還是巨大的，沒過一會，一個功能模組可能就給你揪出了十幾個bug，大家一起發現的問題會議結束後會形成一個bug列表，按責任人給依次分配下去解決。相當於集體重構了一次程式碼，讓系統更加的健壯、穩定。


　　改過了上次的bug後，團隊成員可以小休息一會了。一個迭代週期結束後，專案組成員會再次的坐在一起開一個即重要又輕鬆的會議--迭代回顧會議。專案中遇到的問題總結，下一次在遇到同樣的問題該怎麼對付。其實直到專案交付，期間還會有很多次的迭代的。


　　當然，敏捷開發有十二原則，在這裡新霸哥就不重複了，如果有需要對敏捷開發有更深的瞭解歡迎和新霸哥交流。如今，敏捷的思想算是深入人心了，後面的具體方法就是教會我們如何實施敏捷。新霸哥發現有了這些思想，整個世界都開始美好了。