敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。核心思想總結如下：

◆簡單化

當從事開發工作時，主張最簡單的解決方案就是最好的解決方案。不必要對這個系統進行過分的建模，只要基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。儘可能的保持模型的簡單。

◆能變化

需求時刻在變，人們對於需求的理解也時刻在變。專案進行中，Project stakeholder可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著專案的進行，專案環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。

◆可持續

可持續性可能指的是系統的下一個主要釋出版，或是你正在構建的系統的運轉和支援。要做到這一點，你不僅僅要構建高質量的軟體，還要建立足夠的文件和支援材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。

◆可遞增

沒有必要試圖在一開始就建立一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，然後慢慢的改進模型，或是在不再需要的時候丟棄這個模型。這就是遞增的思想。

◆先建模

對於自己的產出，例如模型、原始碼、文件，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或擔心它們是否足夠正確。你不應該毫無意義的建模，應該先問問，為什麼要建立這個產出，為誰建立它。首先，你要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。

◆高質量

做這項工作要有成就感；日後負責重構這項工作的人不喜歡，是因為它難以理解，難以更新；終端使用者不喜歡，是因為它太脆弱，容易出錯，也不符合他們的期望。

◆快反饋

從開始採取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一共開發模型，你的想法可以立刻獲得反饋，特別是你的工作採用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客戶緊密工作，去了解他們的的需求，去分析這些需求，或是去開發滿足他們需求的使用者介面，這樣，你就提供了快速反饋的機會。

◆輕上陣

一個開發團隊決定要開發並維護一份詳細的需求文件，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫原始碼上，而是花在了更新文件上。

如下是流程圖：