l         僵化性（Rigidity）：很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其他改動。

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

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

l         粘滯性（Viscosity）：做正確的事情比做錯誤的事情要困難。

l         不必要的復雜性（Needless Complexity）：設計中包含有不具任何直接好處的基礎結構。

l         不必要的重復（Needless Repetition）：設計中包含有重復的結構，而該重復的結構本可以使用單一的抽象進行統一。

l         晦澀性（Opacity）：很難閱讀、理解。沒有很好的表現出意圖。

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

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

　　 規劃迭代故事時必須按照優先級安排，為客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷小組關注完成和交 付具有用戶價值的功能，而不是孤立的任務。以前我們都用需求規格說明書或者用例來編寫詳細的需求，敏捷使用用戶故事來羅列需求。用戶故事是一種表示需求的 輕量級技術，它沒有

固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：“作為【用戶的類型】，我希 望可以【能力】以便【業務價值】“。使用基于用戶故事的需求分析方法時，仍可能需要原型和編寫文檔，只是工作重點更多的轉移到了口頭交流。

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

　　敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味著我們更了解市場需求。
  
3。經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。

　 　迭代是受實踐框限制的，意味著即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟件可以很好的工作，那么交付時間越短，我們和客戶協作就越 緊密，對產品質量就更有益。雖然我們多次迭代，但并不是每次迭代的結果都需要交付給用戶，敏捷開發的目標是讓他們可以交付。這意味著開發小組在每次迭代中 都會增加一些功能，增加的每個功能都是經過編碼、測試，達到了可發布的質量標準的。
　　另外敏捷開發項目中對開發階段沒有什么重要的分割，沒有先期的需求階段，然后是分析階段，架構設計階段，編碼測試階段等，在項目真正開始后，每次迭代中都會同時進

行所有的上述階段工作。
 
4。在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

　　軟件項目不會依照之前設定的計劃原路執行，中間對業務的理解、軟件的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義的、頻繁 

的交互，這樣就可以在早期及時的發現并解決問題。
 
5。圍繞被激勵起來的人個來構建項目。給他們提供所需要的環境和支持，并且信任他們能夠完成工作。

　　業務和技術是引起不確定的二個主要方面，人是第三個方面。而業務和技術又必須由人來執行，所以能夠激勵人來解決這些問題是解決不確定性的關鍵。只要個人的目標和團

隊的目標一致，我們就需要鼓舞起每個人的積極性，以個人為中心構建項目，提供所需的環境、支持與信任。

6。在團隊內部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。

　　在十幾或者二十幾個人組成的大團隊中，文檔是一種比較合適的傳遞知識和交流的途徑。而敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），所以

大量的文檔交流其實并不是很經濟的做法。此時面對面的交談反而更快速有效。
 
7、可工作的軟件是首要進度度量標準。

　 　一般的工作都比較容易衡量任務進展，比如讓你去搬運1噸的石頭，我只要去稱一下你已經搬運的石頭重量就知道你完成多少了。而對于軟件來說，在軟件沒有編 碼、測試完

成之前，我們都不能因為代碼編寫了多少行，測試用例跑了多少個就去度量這個功能是否完成了。衡量這個功能是否完成的首要標準就是這個功能可以工 作了，對用戶來說已經可

以應用了。

8。敏捷過程提可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。

　 　很多人都認為軟件開發中加班是很正常的，不加班反而不正常，我對此有點不理解，這個可能是國情所致吧。敏捷過程希望能夠可持續的進行開發，開發速度不會 隨著迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態度，開發工作不應該是突擊行為。我們不能指望說突擊這個項目后就可以輕松了，因為完成一個項目 后會接踵而來下一個項目，而只要還是拼拼的態度，下一個項目依舊會讓你的組員再次突擊。這時不知道有人會不會說，那我們就一直加班，也是“持續的開發速 度”啊，這時可要注意了，持續加班智

慧導致人疲勞、厭倦，保持長期恒定的速度也只是一種理想而已。
 
9。不斷地關注優秀的技能和好的設計會增強敏捷能力。

　　敏捷過程有很多好的技術實踐可以加強產品敏捷能力，很多原則、模式和實踐也可以增強敏捷開發能力。 《敏捷軟件開發－原則、模式與實踐》一書中介紹了很多設計，感興趣的可以去仔細看看。
 
10。簡單----使未完成的工作最大化的藝術----是根本的。

　 　我們不可能預期后面需求會如何變化，所以不可能一開始就構建一個完美的架構來適應以后的所有變化。敏捷團隊不會去構建明天的軟件，而把注意力放在如何通 過最簡單的方法完成現在需要解決的問題。這時有人會說，我已經預計到了肯定存在哪些需求擴展點，我們在一開始是否需要考慮呢？這時團隊需要根據自己的理解 去決定是否考慮，如果深信在明天發生了這個問題也可以輕易處理的話，那么就最好先不考慮。
 
11。最好的構架、需求和設計出自與自組織的團隊。

        敏捷中有很多種實踐，大家都知道，迭代式開發是主要的實踐方法，而自組織團隊也是主要的實踐之一。在自組織團隊中，管理者不再發號施令，而是讓團隊自身尋找最佳的工作方式來完成工作。要形成一個自組織團隊其實比較難。CSDN采訪Mishkin Berteig中說到 自組織團隊的第一個要素就是必須有一個團隊，而不僅僅是一群人。一群人是一幫在一起工作的人，他們彼此之間并沒有太多的溝通，他們也并不視彼此為一體。項目一開始，我們就會組建“團隊”，但很多時候由構架師、需求人員、開發人員和測試人員組成的是一群人而已。他還認為，團隊的形成必須經歷幾個時期。在 經歷了初期的磨合后，成員才會開始對團隊共同的工作理念與文化形成一個基本的認識和理解。團隊內會逐漸形成規矩，而且這些規矩是不言而喻的。比如，每個人 都知道上午九點來上班，都會主動詢問別人是否需要幫助，也都會去主動和別人探討問題。如果團隊成員之間能夠達成這樣的默契，那么這個團隊將成為一個真正高 效的工作團隊。在這樣團隊中，成員之間相互理解，工作效率非常高。在自組織團隊中，團隊成員不需要遵從別人的詳細指令。他們需要更高層次的指導，這種指 導更像是一個目標，一個致力于開發出更好的軟件的目標。總之，自組織團隊是一個自動自發、有著共同目標和工作文化的團隊，這樣的團隊總是在向它的組織做出 承諾。但是，實現這些承諾對于自組織團隊來說非常重要。否則，一旦出現問題，團隊成員之間就會出現信任危機。

　　雖然敏捷開發小組是以小組為整體 來工作的，但是還是有必要指明一些承擔一定任務的角色。第一個角色是產品所有者（Product Owner）。產品所有者的主要職責包括：確認小組所有成員都在追求一個共同的項目前景，確定功能的優先級以便總是在處理最具有價值的功能，以及作出決定 使得對項目的投入可以產生良好的回報。可以對應為以前開發中的“產品經理”。另一角色是開發團隊（developer），這里的開發人員包括了架構師、設計師、程序員、需求人員、測試人員、文檔編寫者等，有時產品所有者也可以被看作是

開發人員。還有一個重要角色就是項目經理（project manager）。敏捷開發的項目經理會更多的關注領導而不是管理。在某些項目中，項目經理可能同時也是開發人員，少數時候也會擔任產品所有者。
　　 
12。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。

　　由于很多不確定性因素會導致計劃失效，比如項目成員增減、技術應用效果、用戶需求的改變、競爭者對我們的影響等都會讓我們作出不同的反應。　敏捷不是基于預定義的工作方式，而是基于經驗性的方式，對以上這些變化，小組通過不斷的反省調整來保持團隊的敏捷性。

l         單一職責原則（The Single Responsibility Principle，簡稱SRP）：就一個類而言，應該僅有一個引起它變化的原因。在SRP中，我們把職責定義為“變化的原因（）”。如果你能夠想到多于一個的動機去改變一個類，那么這個類就具有多于一個的職責。軟件設計真正要做的許多內容，就是發現職責并把那些職責相互分離。事實上，我們將要論述的其余原則都會以這樣或那樣的方式回到這個問題上。

l         開放封閉原則（The Open-Close Principle，簡稱OCP）：軟件實體（類、模塊、函數等等）應該是可以擴展的，但是不可以修改的。遵循開放封閉原則設計出的模塊具有兩個主要的特征。它們是：（1）、對于擴展是開放的。這意味著模塊的行為是可以擴展的。當應用的需求改變時，我們可以對模塊進行擴展，使其具有滿足那些改變的新行為。換句話說，我們可以改變模塊的功能。（2）、對模塊行為進行擴展時，不必改動模塊的源代碼或者二進制代碼。模塊的二進制可執行版本，無論是可鏈接的庫、DLL或者Java的.jar文件，都無需改動。

l         Liskov替換原則（The Liskov Substitution Principle，簡稱LSP）：子類型必須能夠替換掉它們的基類型。OCP原則是OOD中很多說法的核心。LSP是使OCP成為可能的主要原則之一。正式子類型的可替換性才使得使用基類類型的模塊在無需修改的情況下就可以擴展。這種可替換性必須是開發人員可以隱式依賴的東西。

l         依賴倒置原則（The Dependency Inversion Principle，簡稱DIP）：（1）、高層模塊不應該依賴于底層模塊。二者都應該依賴于抽象。（2）、抽象不應該依賴于細節。細節應該依賴于抽象。使用傳統的過程化設計所創建出來的依賴關系結構，策略是依賴于細節的。面向對象的程序設計倒置了依賴關系結構，使得細節和策略都依賴于抽象，并且常常是客戶擁有服務接口。事實上，這種依賴關系正式好的面向對象設計的標志所在。

l         接口隔離原則（The Interface Segregation Interface，簡稱ISP）：不應該強迫客戶依賴它們不用的方法。如果強迫客戶程序依賴于那些它們不適用的方法，那么這些客戶程序就面臨著由于這些未使用方法的改變所帶來的變更。這就無意中導致了所有客戶程序之間的耦合。我們希望盡可能地避免這種耦合，因此我們希望分離接口。

測試驅動開發

極限編程（eXtreme Programming，簡稱XP）是敏捷方法中最著名的一個。它由一系列簡單卻相互依賴的時間組成。這些實踐結合在一起形成了一個勝于部分結合的整體。其中一個非常重要的，當前也受到格外重視的實踐就是TDD（測試驅動的開發方法）。

在測試驅動的開發方法中，編寫所有的代碼的目的都是為了使失敗的單元測試能夠通過。首先編寫一個單元測試，由于它要測試的功能還不在，所以它會運行失敗。然后編寫代碼使測試通過。

編寫測試用例和代碼之間的更迭速度是很快的，基本上幾分鐘左右。測試用例和代碼共同演化，其中測試用例循序漸進地對代碼的編寫進行指導。作為結果，一個非常完整的測試用例集和代碼一起發展起來。

測試粗略的可以分為單元測試和驗收測試。單元測試是用來驗證系統中個別機制的白盒測試。

單元測試用來驗證系統的小的組成單元應該按照所期望的方式工作，但是它們沒有驗證系統作為一個整體時工作的正確性。所以，單元測試是必要的，但是不夠充分。

驗收測試是用來驗證系統滿足客戶需求的黑盒測試。驗收測試由不了解系統內部機制的人編寫。驗收測試是程序，因此是可運行的。通常通過使用專門為應用程序的客戶創建的腳本語言來編寫驗收測試。正如單元測試作為可編譯、運行的有關系統內部結構的文檔那樣，驗收測試是有關系統特性的可編譯、執行的文檔。

編寫代碼前就編寫單元測試會帶來四個很明顯的好處：

1、首先編寫測試使得程序中的每一項功能都有測試來驗證它的操作的正確性。這就可以給以后的開發提供支援，使我們可以更自由地對程序進行更改，因為測試可以告訴我們程序仍然具有正確的行為。

2、首先編寫測試迫使我們必須從程序調用者的有利視角去觀察我們將要編寫的程序。這樣，我們就會在關注程序的功能的同時，直接關注它的接口，我們也就可以設計出便于調用的軟件。

3、首先編寫測試迫使我們把程序設計為可測試的。為了把程序設計為易于調用和可測試的，程序必須和它周邊環境解耦。這樣首先編寫測試迫使我們解除軟件中的耦合。面向對象設計的原則在進行這種解除耦合方面具有巨大的幫助作用。

4、首先編寫測試的另一個重要效果是，測試可以作為一種無價的文檔形式。測試就像一套范例，它幫助其他程序員了解如何使用代碼。這份文檔是可編譯、可運行的。它保持最新。它不會撒謊。

首先編寫驗收測試的行為對于系統的架構方面具有深遠的影響。為了使系統具有可測試性，就必須要在很高的系統架構層面對系統進行解耦合。正如單元測試可以促使你在小的方面可以做出優良的設計決策一樣，驗收測試可以促使你在大的方面做出優良的系統架構決策。

 軟件大師、C++之父Bjarne Stroustrup曾經說過：設計和編程都是人的活動。忘記了這一點，將會失去一切。敏捷軟件開發方法正是認識到軟件開發的這一本質特征而提出的革新性開發方法。使用敏捷開發方法會給我們帶來巨大的好處。當然要完全做到也是很困難的。這不僅需要對敏捷的深刻理解，更需要敏捷團隊成員的共同努力。