l         僵化性（Rigidity）：很難對(duì)系統(tǒng)進(jìn)行改動(dòng)，因?yàn)槊總€(gè)改動(dòng)都會(huì)迫使許多對(duì)系統(tǒng)其他部分的其他改動(dòng)。

l         脆弱性（Fragility）：對(duì)系統(tǒng)的改動(dòng)會(huì)導(dǎo)致系統(tǒng)中和改動(dòng)的地方在概念上無關(guān)的許多地方出現(xiàn)問題。

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

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

l         不必要的復(fù)雜性（Needless Complexity）：設(shè)計(jì)中包含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)。

l         不必要的重復(fù)（Needless Repetition）：設(shè)計(jì)中包含有重復(fù)的結(jié)構(gòu)，而該重復(fù)的結(jié)構(gòu)本可以使用單一的抽象進(jìn)行統(tǒng)一。

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

敏捷設(shè)計(jì)是一個(gè)過程，不是一個(gè)事件。它是一個(gè)持續(xù)的應(yīng)用原則、模式以及實(shí)踐來改進(jìn)軟件的結(jié)構(gòu)和可讀性的過程。它致力于保持系統(tǒng)設(shè)計(jì)在任何時(shí)間都盡可能得簡(jiǎn)單、干凈以及富有表現(xiàn)力。

1。我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價(jià)值的軟件來使客戶滿意。

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

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

2。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。

　　敏捷過程參與者不怕變化，他們認(rèn)為改變需求是好事情，因?yàn)檫@些改變意味著我們更了解市場(chǎng)需求。
  
3。經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個(gè)月，交付的時(shí)間間隔越短越好。

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

行所有的上述階段工作。
 
4。在整個(gè)項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。

　　軟件項(xiàng)目不會(huì)依照之前設(shè)定的計(jì)劃原路執(zhí)行，中間對(duì)業(yè)務(wù)的理解、軟件的解決方案肯定會(huì)存在偏差，所以客戶、需求人員、開發(fā)人員以及涉眾之間必須進(jìn)行有意義的、頻繁 

的交互，這樣就可以在早期及時(shí)的發(fā)現(xiàn)并解決問題。
 
5。圍繞被激勵(lì)起來的人個(gè)來構(gòu)建項(xiàng)目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。

　　業(yè)務(wù)和技術(shù)是引起不確定的二個(gè)主要方面，人是第三個(gè)方面。而業(yè)務(wù)和技術(shù)又必須由人來執(zhí)行，所以能夠激勵(lì)人來解決這些問題是解決不確定性的關(guān)鍵。只要個(gè)人的目標(biāo)和團(tuán)

隊(duì)的目標(biāo)一致，我們就需要鼓舞起每個(gè)人的積極性，以個(gè)人為中心構(gòu)建項(xiàng)目，提供所需的環(huán)境、支持與信任。

6。在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談。

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

大量的文檔交流其實(shí)并不是很經(jīng)濟(jì)的做法。此時(shí)面對(duì)面的交談反而更快速有效。
 
7、可工作的軟件是首要進(jìn)度度量標(biāo)準(zhǔn)。

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

成之前，我們都不能因?yàn)榇a編寫了多少行，測(cè)試用例跑了多少個(gè)就去度量這個(gè)功能是否完成了。衡量這個(gè)功能是否完成的首要標(biāo)準(zhǔn)就是這個(gè)功能可以工 作了，對(duì)用戶來說已經(jīng)可

以應(yīng)用了。

8。敏捷過程提可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開發(fā)速度。

　 　很多人都認(rèn)為軟件開發(fā)中加班是很正常的，不加班反而不正常，我對(duì)此有點(diǎn)不理解，這個(gè)可能是國(guó)情所致吧。敏捷過程希望能夠可持續(xù)的進(jìn)行開發(fā)，開發(fā)速度不會(huì) 隨著迭代的任務(wù)不同而不同，不欣賞所謂的拼一拼也能完成的態(tài)度，開發(fā)工作不應(yīng)該是突擊行為。我們不能指望說突擊這個(gè)項(xiàng)目后就可以輕松了，因?yàn)橥瓿梢粋€(gè)項(xiàng)目 后會(huì)接踵而來下一個(gè)項(xiàng)目，而只要還是拼拼的態(tài)度，下一個(gè)項(xiàng)目依舊會(huì)讓你的組員再次突擊。這時(shí)不知道有人會(huì)不會(huì)說，那我們就一直加班，也是“持續(xù)的開發(fā)速 度”啊，這時(shí)可要注意了，持續(xù)加班智

慧導(dǎo)致人疲勞、厭倦，保持長(zhǎng)期恒定的速度也只是一種理想而已。
 
9。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。

　　敏捷過程有很多好的技術(shù)實(shí)踐可以加強(qiáng)產(chǎn)品敏捷能力，很多原則、模式和實(shí)踐也可以增強(qiáng)敏捷開發(fā)能力。 《敏捷軟件開發(fā)－原則、模式與實(shí)踐》一書中介紹了很多設(shè)計(jì)，感興趣的可以去仔細(xì)看看。
 
10。簡(jiǎn)單----使未完成的工作最大化的藝術(shù)----是根本的。

　 　我們不可能預(yù)期后面需求會(huì)如何變化，所以不可能一開始就構(gòu)建一個(gè)完美的架構(gòu)來適應(yīng)以后的所有變化。敏捷團(tuán)隊(duì)不會(huì)去構(gòu)建明天的軟件，而把注意力放在如何通 過最簡(jiǎn)單的方法完成現(xiàn)在需要解決的問題。這時(shí)有人會(huì)說，我已經(jīng)預(yù)計(jì)到了肯定存在哪些需求擴(kuò)展點(diǎn)，我們?cè)谝婚_始是否需要考慮呢？這時(shí)團(tuán)隊(duì)需要根據(jù)自己的理解 去決定是否考慮，如果深信在明天發(fā)生了這個(gè)問題也可以輕易處理的話，那么就最好先不考慮。
 
11。最好的構(gòu)架、需求和設(shè)計(jì)出自與自組織的團(tuán)隊(duì)。

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

　　雖然敏捷開發(fā)小組是以小組為整體 來工作的，但是還是有必要指明一些承擔(dān)一定任務(wù)的角色。第一個(gè)角色是產(chǎn)品所有者（Product Owner）。產(chǎn)品所有者的主要職責(zé)包括：確認(rèn)小組所有成員都在追求一個(gè)共同的項(xiàng)目前景，確定功能的優(yōu)先級(jí)以便總是在處理最具有價(jià)值的功能，以及作出決定 使得對(duì)項(xiàng)目的投入可以產(chǎn)生良好的回報(bào)。可以對(duì)應(yīng)為以前開發(fā)中的“產(chǎn)品經(jīng)理”。另一角色是開發(fā)團(tuán)隊(duì)（developer），這里的開發(fā)人員包括了架構(gòu)師、設(shè)計(jì)師、程序員、需求人員、測(cè)試人員、文檔編寫者等，有時(shí)產(chǎn)品所有者也可以被看作是

開發(fā)人員。還有一個(gè)重要角色就是項(xiàng)目經(jīng)理（project manager）。敏捷開發(fā)的項(xiàng)目經(jīng)理會(huì)更多的關(guān)注領(lǐng)導(dǎo)而不是管理。在某些項(xiàng)目中，項(xiàng)目經(jīng)理可能同時(shí)也是開發(fā)人員，少數(shù)時(shí)候也會(huì)擔(dān)任產(chǎn)品所有者。
　　 
12。每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對(duì)自己的行為進(jìn)行調(diào)整。

　　由于很多不確定性因素會(huì)導(dǎo)致計(jì)劃失效，比如項(xiàng)目成員增減、技術(shù)應(yīng)用效果、用戶需求的改變、競(jìng)爭(zhēng)者對(duì)我們的影響等都會(huì)讓我們作出不同的反應(yīng)?！∶艚莶皇腔陬A(yù)定義的工作方式，而是基于經(jīng)驗(yàn)性的方式，對(duì)以上這些變化，小組通過不斷的反省調(diào)整來保持團(tuán)隊(duì)的敏捷性。

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

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

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

l         依賴倒置原則（The Dependency Inversion Principle，簡(jiǎn)稱DIP）：（1）、高層模塊不應(yīng)該依賴于底層模塊。二者都應(yīng)該依賴于抽象。（2）、抽象不應(yīng)該依賴于細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴于抽象。使用傳統(tǒng)的過程化設(shè)計(jì)所創(chuàng)建出來的依賴關(guān)系結(jié)構(gòu)，策略是依賴于細(xì)節(jié)的。面向?qū)ο蟮某绦蛟O(shè)計(jì)倒置了依賴關(guān)系結(jié)構(gòu)，使得細(xì)節(jié)和策略都依賴于抽象，并且常常是客戶擁有服務(wù)接口。事實(shí)上，這種依賴關(guān)系正式好的面向?qū)ο笤O(shè)計(jì)的標(biāo)志所在。

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

測(cè)試驅(qū)動(dòng)開發(fā)

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

在測(cè)試驅(qū)動(dòng)的開發(fā)方法中，編寫所有的代碼的目的都是為了使失敗的單元測(cè)試能夠通過。首先編寫一個(gè)單元測(cè)試，由于它要測(cè)試的功能還不在，所以它會(huì)運(yùn)行失敗。然后編寫代碼使測(cè)試通過。

編寫測(cè)試用例和代碼之間的更迭速度是很快的，基本上幾分鐘左右。測(cè)試用例和代碼共同演化，其中測(cè)試用例循序漸進(jìn)地對(duì)代碼的編寫進(jìn)行指導(dǎo)。作為結(jié)果，一個(gè)非常完整的測(cè)試用例集和代碼一起發(fā)展起來。

測(cè)試粗略的可以分為單元測(cè)試和驗(yàn)收測(cè)試。單元測(cè)試是用來驗(yàn)證系統(tǒng)中個(gè)別機(jī)制的白盒測(cè)試。

單元測(cè)試用來驗(yàn)證系統(tǒng)的小的組成單元應(yīng)該按照所期望的方式工作，但是它們沒有驗(yàn)證系統(tǒng)作為一個(gè)整體時(shí)工作的正確性。所以，單元測(cè)試是必要的，但是不夠充分。

驗(yàn)收測(cè)試是用來驗(yàn)證系統(tǒng)滿足客戶需求的黑盒測(cè)試。驗(yàn)收測(cè)試由不了解系統(tǒng)內(nèi)部機(jī)制的人編寫。驗(yàn)收測(cè)試是程序，因此是可運(yùn)行的。通常通過使用專門為應(yīng)用程序的客戶創(chuàng)建的腳本語言來編寫驗(yàn)收測(cè)試。正如單元測(cè)試作為可編譯、運(yùn)行的有關(guān)系統(tǒng)內(nèi)部結(jié)構(gòu)的文檔那樣，驗(yàn)收測(cè)試是有關(guān)系統(tǒng)特性的可編譯、執(zhí)行的文檔。

編寫代碼前就編寫單元測(cè)試會(huì)帶來四個(gè)很明顯的好處：

1、首先編寫測(cè)試使得程序中的每一項(xiàng)功能都有測(cè)試來驗(yàn)證它的操作的正確性。這就可以給以后的開發(fā)提供支援，使我們可以更自由地對(duì)程序進(jìn)行更改，因?yàn)闇y(cè)試可以告訴我們程序仍然具有正確的行為。

2、首先編寫測(cè)試迫使我們必須從程序調(diào)用者的有利視角去觀察我們將要編寫的程序。這樣，我們就會(huì)在關(guān)注程序的功能的同時(shí)，直接關(guān)注它的接口，我們也就可以設(shè)計(jì)出便于調(diào)用的軟件。

3、首先編寫測(cè)試迫使我們把程序設(shè)計(jì)為可測(cè)試的。為了把程序設(shè)計(jì)為易于調(diào)用和可測(cè)試的，程序必須和它周邊環(huán)境解耦。這樣首先編寫測(cè)試迫使我們解除軟件中的耦合。面向?qū)ο笤O(shè)計(jì)的原則在進(jìn)行這種解除耦合方面具有巨大的幫助作用。

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

首先編寫驗(yàn)收測(cè)試的行為對(duì)于系統(tǒng)的架構(gòu)方面具有深遠(yuǎn)的影響。為了使系統(tǒng)具有可測(cè)試性，就必須要在很高的系統(tǒng)架構(gòu)層面對(duì)系統(tǒng)進(jìn)行解耦合。正如單元測(cè)試可以促使你在小的方面可以做出優(yōu)良的設(shè)計(jì)決策一樣，驗(yàn)收測(cè)試可以促使你在大的方面做出優(yōu)良的系統(tǒng)架構(gòu)決策。

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