敏捷軟件開發的含義

　　雖然右項也有價值，但是我們認為左項具有更大的價值。

　　敏捷宣言遵循的原則：

　　① 我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。

　　② 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

　　③ 經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
　　④ 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

　　⑤ 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。

　　⑥ 在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是麵對麵的交談。

　　⑦ 工作的軟件是首要的進度度量標準。
　　⑧ 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。

　　⑨ 不斷地關注優秀的技能和好的設計會增強敏捷能力。

　　⑩ 簡單是最根本的。最好的構架、需求和設計出於自組織團隊。

　　每隔一定時間，團隊會在如何才能更有效地工作方麵進行反省，然後相應地對自己的行為進行調整。

　　
      當軟件開發需求的變化而變化時，軟件設計會出現壞味道，當軟件中出現下麵任何一種氣味時，表明軟件正在腐化。

　　n 僵化性： 很難對係統進行改動，因為每個改動都會迫使許多對係統其他部分的其它改動。

　　n 脆弱性： 對係統的改動會導致係統中和改動的地方在概念上無關的許多地方出現問題。

　　n 牢固性： 很難解開係統的糾結，使之成為一些可在其他係統中重用的組件。

　　n 粘滯性： 做正確的事情比做錯誤的事情要困難。

　　n 不必要的複雜性： 設計中包含有不具任何直接好處的基礎結構。

　　n 不必要的重複性： 設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。

　　n 晦澀性： 很難閱讀、理解。沒有很好地表現出意圖。

　　敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要一個成熟的初始設計。他們更願意保持設計盡可能的幹淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續地改進設計，以便於每次迭代結束生成的係統都具有最適合於那次迭代中需求的設計。

　　為了改變上麵軟件設計中的腐化味，敏捷開發采取了以下麵向對象的設計原則來加以避免，這些原則如下：

　　① 單一職責原則(SRP)：就一個類而言，應該僅有一個引起它變化的原因。

　　② 開放-封閉原則(OCP)：軟件實體應該是可以擴展的，但是不可修改。

　　③ Liskov替換原則(LSP)：子類型必須能夠替換掉它們的基類型。

　　④ 依賴倒置原則(DIP)：抽象不應該依賴於細節。細節應該依賴於抽象。

　　⑤ 接口隔離原則(ISP)：不應該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。

　   ⑥ 重用發布等價原則(REP)：重用的粒度就是發布的粒度。

　   ⑦ 共同封閉原則(CCP)：包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對於其他的包不造成任何影響。

　　⑧ 共同重用原則(CRP)：一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。
　　⑨ 無環依賴原則(ADP)：在包的依賴關係圖中不允許存在環。

　　⑩ 穩定依賴原則(SDP)：朝著穩定的方向進行依賴。

　　⑾穩定抽象原則(SAP)：包的抽象程度應該和其穩定程度一致。

　　上述中的包的概念是：包可以用作包容一組類的容器，通過把類組織成包，我們可以在更高層次的抽象上來理解設計，我們也可以通過包來管理軟件的開發和發布。目的就是根據一些原則對應用程序中的類進行劃分，然後把那些劃分後的類分配到包中。

　　敏捷設計是一個過程，不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟件的結構和可讀性的過程。它致力於保持係統設計在任何時間都盡可能得簡單、幹淨和富有表現力