人與人之間的交互是復雜的，并且其效果從來都是難以預期的，但卻是工作中最重要的方面。
　　                                                                                                                         -- Tom DeMacro和Timothy Lister
　　敏捷軟件開發宣言：
　　n 個體和交互 勝過 過程和工具
　　n 可以工作的軟件 勝過 面面俱到的文檔
　　n 客戶合作 勝過 合同談判
　　n 響應變化 勝過 遵循計劃
　　雖然右項也有價值，但是我們認為左項具有更大的價值。
　　敏捷宣言遵循的原則：
　　n 我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
　　n 即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
　　n 經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
　　n 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
　　n 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。
　　n 在團隊內部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。
　　n 工作的軟件是首要的進度度量標準。
　　n 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。
　　n 不斷地關注優秀的技能和好的設計會增強敏捷能力。
　　n 簡單是最根本的。
　　n 最好的構架、需求和設計出于自組織團隊。
　　n 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。
　　當軟件開發需求的變化而變化時，軟件設計會出現壞味道，當軟件中出現下面任何一種氣味時，表明軟件正在腐化。
　　n 僵化性： 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。
　　n 脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
　　n 牢固性： 很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。
　　n 粘滯性： 做正確的事情比做錯誤的事情要困難。
　　n 不必要的復雜性： 設計中包含有不具任何直接好處的基礎結構。
　　n 不必要的重復性： 設計中包含有重復的結構，而該重復的結構本可以使用單一的抽象進行統一。
　　n 晦澀性： 很難閱讀、理解。沒有很好地表現出意圖。
　　敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要一個成熟的初始設計。他們更愿意保持設計盡可能的干凈、簡單，并使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易于理解性。團隊利用這種靈活性，持續地改進設計，以便于每次迭代結束生成的系統都具有最適合于那次迭代中需求的設計。
　　為了改變上面軟件設計中的腐化味，敏捷開發采取了以下面向對象的設計原則來加以避免，這些原則如下：
　　n 單一職責原則(SRP)
　　就一個類而言，應該僅有一個引起它變化的原因。
　　n 開放-封閉原則(OCP)
　　軟件實體應該是可以擴展的，但是不可修改。
　　n Liskov替換原則(LSP)
　　子類型必須能夠替換掉它們的基類型。
　　n 依賴倒置原則(DIP)
　　抽象不應該依賴于細節。細節應該依賴于抽象。
　　n 接口隔離原則(ISP)
　　不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。
　　n 重用發布等價原則(REP)
　　重用的粒度就是發布的粒度。
　　n 共同封閉原則(CCP)
　　包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對于其他的包不造成任何影響。
　　n 共同重用原則(CRP)
　　一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那么就要重用包中的所有類。
　　n 無環依賴原則(ADP)
　　在包的依賴關系圖中不允許存在環。
　　n 穩定依賴原則(SDP)
　　朝著穩定的方向進行依賴。
　　n 穩定抽象原則(SAP)
　　包的抽象程度應該和其穩定程度一致。
　　上述中的包的概念是：包可以用作包容一組類的容器，通過把類組織成包，我們可以在更高層次的抽象上來理解設計，我們也可以通過包來管理軟件的開發和發布。目的就是根據一些原則對應用程序中的類進行劃分，然后把那些劃分后的類分配到包中。
　　敏捷設計是一個過程，不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟件的結構和可讀性的過程。它致力于保持系統設計在任何時間都盡可能得簡單、干凈和富有表現力。