敏捷開發，以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。
敏捷是以人為中心的軟體開發方法，保持簡潔的**，經常性測試以及及時地交付應用的功能模組。正如敏捷宣言所提到的那樣。
敏捷宣言強調的敏捷軟體開發的四大宣言是：
1.個體與互動高於流程和工具
2·工作軟體高於理解文件
3·客戶協作高於合同協商
4·變化響應高於計畫遵循
結合軟體研發實際，四大宣言可以這樣理解：
個體與互動勝過過程與工具
方法和工具是死的，人是活的，如何沒有優秀個人和團隊協作，再強大的方法和工具都是擺設。乙個使用普通工具的優秀人員會比使用優秀工具的普通人員做得更好，乙個具有合作精神、自組織的團隊比通過過程規範的團隊工作得更好。敏捷中每個成員都需要定時和團隊的其他成員一起檢視團隊的整體進度，計畫下一步工作，並一起**所遭遇問題的解決方案。自組織團隊通過個人能力和協作能力，可以自發的通過各種途徑解決開發過程中遇到的問題。
雖然我們致力於個體和互動，但並不代表就不需要過程與工具了。scrum、xp等方法本身也有一些方法和過程，每日構造等敏捷實踐也需要工具的支援，需要哪些過程和工具由自組織團隊制定，而不是由領導制定。
工作軟體高於理解文件
在合同中有時會看到分別在需求、設計、開發、測試階段提供什麼文件，支付多少金額等內容，而這些文件對使用者來說是不是真的有價值呢？冗長文件對客戶來說並不重要，其重要程度比不上乙個可以工作的軟體。冗長的文件對開發也不重要，沒有人有時間去讀，而且也不符合敏捷開發的特性，對研發團隊來說最好的文件就是**和團隊，通過頻繁的提供可以工作的軟體，不斷地蒐集市場反饋，保證軟體的市場時效性。
雖然我們致力於提供可供做的軟體，但並不是不要文件。我們在開發過程中仍然需要進行內部交流， 也需要和客戶交流，我們仍舊可能需要製作原型，書寫一些主要需求和演算法，只要可以滿足研發團隊需求就行。
客戶協作高於合同協商
尋求客戶合作的價值重於對合同的談判。軟體開發的最終目標是提供給客戶滿意的軟體，而只有客戶才更清楚怎麼樣才能滿意，敏捷開發提倡客戶和開發團隊密切的在一起工作，經常性的根據市場需求對軟體提供反饋。各種不同的敏捷方法都會利用短期迭代，通過盡早提供軟體來達到與客戶頻繁溝通和反饋的，這也可以把問題及早暴露出來，以免隱藏的問題在後期造成更大的影響。
雖然我們致力於客戶協作，但為了雙方利益和需要仍舊需要進行合同談判。
變化響應高於計畫遵循
敏捷專案承認開發過程中的不確定性，所以不會在開發中制定長時間的複雜計畫，它們的成功都是建立在現實反饋的基礎上的。每次迭代都是基於上一迭代的完善基礎之上進行的，通過不斷的響應變化來消除開發中的不確定性。
在敏捷開發時，我們不應該為了讓自己的專案看起來像是按照計畫好的樣子循序漸進，而花費大量的時間讓研發團隊去附和計畫。相反，敏捷需要的不是計畫，而是規劃。
敏捷開發方法是「規劃－執行－調整」、「規劃－執行－調整」。乙個專案的不確定性越高，敏捷開發方法對取得成功就越是至關重要，不斷學習和調整是敏捷開發的核心。
像3355中5會那樣，計畫會、sprint評審會、回顧會、每日立會、product backlog的梳理（發生在整個scrum週期的任何時間）。階段性的召開會議，提出當前階段的問題，根據昨天完成的情況來做出新的調整，根據上乙個迭代對新的迭代功能等進行規劃。在sprint評審會上，團隊除了對當前sprint完成的故事進行show case還需要對剩餘的任務卡進行梳理，可以讓團隊有機會去回顧和識別版本發布的風險。
敏捷開發的12條原則包括：
1.通過早期和連續型的**值工作交付滿足「客戶」。
2.大工作分成可以迅速完成的較小組成部門。
3.識別最好的工作是從自我組織的團隊中出現的，
4.為積極員工提供他們需要的環境和支援，並相信他們可以完成工作。
5.建立可以改善可持續工作的流程。
6.維持完整工作的不變的步調。
7.歡迎改變的需求，即時是在專案後期。
8.在專案期間每天與專案團隊和業務所有者開會。
9.在定期修正期，讓團隊反映如何能高效，然後進行相應地行為調整。
10.通過完成的工作量計量工作進度。
11.不斷地追求完善。
12.利用調整獲得競爭優勢。
大致來講，12宣言的核心內容就是將乙個軟體分成多個迭代去完成，在每個迭代開發時，堅持以人為本的原則，在研發過程中堅持人比工具更重要。在研發中堅持完善工作，擁抱市場擁抱變化，根據市場來調整軟體的功能。快速變化，高效的做出響應。不斷地調整軟體，保持市場時效性。
理解敏捷開發
敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫很多人在不理解敏捷的情況下，簡單的從字面去曲解和批駁敏捷。我就從我的敏捷實踐出發談談我的感想。1 個體和互動勝過過程和工具 我認為這條主要是針對流程和管理上的觀念。...
如何實施敏捷開發
如果嚴格按照書本上的 scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 scrum。不過好歹我們也被稱作 scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。經驗一 整個團隊必須理解 scrum 的目的和限制。如果管理團隊把 scrum 當作一種新的管理流...
理解敏捷開發的常見誤區
1.敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 由價值觀引出的12條敏捷原則 我們最優先要做的是通...