敏捷開發(fā)是一種理念，現在在國內各個開發(fā)團隊的實現雖然還不成熟，但認可度已經相當可觀。下面是博客園的青宇對敏捷開發(fā)的一些理解與心得分享：
我們部門是一個基礎平臺研發(fā)部門，主要為其他各部門提供技術接口和服務支持。
也正是由于這個特性，部門內正在考慮基于WCF搭建一套服務平臺。
部門內提倡敏捷開發(fā)，談談我自己對敏捷的簡單理解。
對需求做足功課
個人認為敏捷的前提是要對需求做充足的功課。
一、明確需求
比如我們每天都要為別的部門提供很多接口，在開發(fā)過程中逐漸發(fā)現我們其實做了很多重復性的工作。
同時大量的技術接口（webservices調用、post調用）非常分散，難以管理。針對這種情況，我們迫切的需要一套統一的服務平臺。
我們的目的就是能夠提供各種部門之間甚至是公司對外合作的技術接口支持。具體這個平臺叫什么，都包括什么，可能還不是很明確。
二、合理的拆分需求
我們的目的很明確，所以我們決定對目前的需求進行分析。通過和各部門同事交流我們對目前存在的需求做了分析。一是從業(yè)務上拆分，我們可以
得到很多子系統。二是從技術上考慮，我們理出一些通用的基礎的功能以及支持業(yè)務擴展的功能。這樣呈現在我們面前的就是一個個經過組合的子系統。
雖然目前的這個模式還是沒有名字，不過我們已經有了進行下去的勇氣。
三、迎接變化
在我們了解需求的過程中，部門的同事都會提到兩個字“目前”?！斑@是我們目前的工作。”，“這是我們目前存在的問題”。
沒錯，沒人敢預測未來。我們也沒打算做一勞永逸的系統。但我們該如果應對變化呢？
了解變化點，我們做不到預測未來。但我們可以盡力去掌握哪些地方有可能變，哪些地方會經常變。甚至能分析出他會朝著那個趨勢變。
一、“并列式”開發(fā)
將開發(fā)團隊分割成小組，不同的子系統交由各個小組負責開發(fā)。大家可以同年同月同日開工，不一定非得同年同月同日完成?？偙纫粭l線的“瀑布”要快的多。
二、關注代碼，以人為本
不必在開發(fā)的每一個階段整理無窮盡的文檔。整齊的代碼更能體現程序員的智慧?？梢詻]有詳細設計，這樣其實更不害怕變化。
沒有計劃變化也就無所謂變化了。
三、迭代
這是迭代法的解釋：迭代法也稱輾轉法，是一種不斷用變量的舊值遞推新值的過程,跟迭代法相對應的是直接法（或者稱為一次解法），即一次性解決問題。
敏捷開發(fā)中鼓勵迭代，周期性的停下來歇一歇，看看過去幾天寫的東西，整理整理思路。其實這是我們在自己尋找變化。所以說敏捷的核心思想是適應變化！