（壹）重溫《敏捷軟件開發宣言》
我們正在通過親身實踐和幫助他人實踐，揭示更好的軟件開發方法。通過這項工作，我們認為：
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
相應變化 勝過 遵循計劃
雖然右項也具有價值，
但我們認為左項具有更大的價值。
原則性的東東，我們做到了多少？
law_bbc 2007-11-16 03:28 PM
（二）學習《敏捷宣言遵循的原則》
我們遵循以下原則：
●我們最優先要做的是通過盡早地、持續地交付有價值的軟件來使客戶滿意。
●即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化給客戶創造競爭優勢。
●經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
●在整個項目開發期間，業務人員和開發人員必須天天都在壹起工作。
●圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
●在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面地交談。
●工作的軟件是首要的進度度量標準。
●敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持壹個長期的、恒定的開發速度。
●不斷地關註優秀的技能和好的設計會增強敏捷能力。
●簡單——使未完成的工作最大化的藝術——是根本的。
●最好的框架、需求和設計出自於自組織的團隊。
●每隔壹定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
好的原則，知易行難的原則。作為努力的方向吧！
law_bbc 2007-11-17 08:49 PM
（三）看看《面向對象設計的原則》
SRP 單壹職責原則
就壹個類而言，應該僅有壹個引起它變化的原因。
OCP 開發-封閉原則
軟件實體（類、模塊、函數等）應該是可以擴展的，但是不可修改。
LSP Liskov替換原則
子類型必須能夠替換掉它們的基類型。
DIP 依賴倒置原則
抽象不應該依賴於細節，細節應該依賴於抽象。
ISP 接口隔離原則
不應該強迫客戶依賴於他們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。
REP 重用發布等價原則
重用的粒度就是發布的粒度。
CCP ***同封閉原則
包中的所有類對於同壹類性質的變化應該是***同封閉的。壹個變化若對壹個包產生影響，則對該包中所有類產生影響，而對其他包不造成任何影響。
CRP ***同重用原則
壹個包中的所有類應該是***同重用的。如果重用了包中的壹個類，那麽就要重用包中所有類。
ADP 無環依賴原則
在包的依賴關系圖中不允許存在環。
SDP 穩定依賴原則
朝著穩定的方向進行依賴。
SAP 穩定抽象原則
包的抽象程度應該和其穩定程度壹致。
開篇後前幾頁都是些原則性的東東嘔。。。
law_bbc 2007-11-19 09:15 PM
（四）了解《極限編程實踐》的概念
完整團隊
XP項目的所有參與者（開發人員、業務分析師、測試人員等等）壹起工作在壹個開放的場所中，他們是同壹個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他壹些顯示他們進度的東西。
計劃遊戲
計劃是持續的，循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
客戶測試
作為每個所期望的特性的壹部分，客戶定義出自動驗收測試來表明該特性可以工作。
簡單設計
團隊保持設計恰好和當前系統功能相匹配，它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。
結對編程
所有的產品軟件都是由兩個程序員、並排坐在壹起在同壹臺機器上構建的。
測試驅動開發
程序員以非常短的循環周期工作，他們先增加壹個失敗的測試，然後再使之通過。
改進設計
隨時改進糟糕的代碼，保持代碼盡可能的幹凈、具有表達力。
持續集成
團隊總是使系統完整地被集成。
集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。
編碼標準
系統中所有的代碼看起來就好像是被單獨壹個——非常值得信任的——人編寫的。
隱喻
團隊提出壹個程序工作原理的***同景像。
可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作。他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
極限編程的思想在很多開發團隊中得到不同程度的應用。。
law_bbc 2007-11-20 11:36 PM
（五）第I部分 敏捷開發之篇首語
作者首先引用了Tom DeMacro和Timothy Lister在《人件》第5頁的話，“人與人之間的交互是復雜的，並且其效果從來都難以預期，但卻是工作中最為重要的方面。”
然後從三個層次闡述了對引言的理解：
（壹）原則、模式和實踐都是重要的，但是使它們發揮作用的是人。正如Alistair Cockburn所說,“過程和方法對於項目的結果只有次要的影響，首要的影響是人。”
（二）如果想要項目取得成功，就必須構建起具有合作精神的、自組織的團隊。
（三）那些鼓勵構建這種團隊的公司比那些認為軟件團隊不過是由無關緊要的、雷同的壹群人堆砌的公司具有大得多的競爭優勢，有凝聚力的團隊將具有最強大的軟件開發力量。
人、團隊、公司，逐層深入、環環相接，發人深省啊。
law_bbc 2007-11-21 11:49 PM
（六）第I部分 敏捷開發 第1章 敏捷實踐之篇首語
海因裏希?海涅（1797—1856，德國詩人）說：“教堂尖頂上的風標，即使由鋼鐵制成，如果不懂得順應風勢的藝術，壹樣會被暴風立即摧毀。”
許多人都經歷過沒有實踐的指導而導致的項目噩夢。缺乏有效的實踐會導致不可預測性、重復的錯誤以及努力的白白浪費。延期的進度、增加的預算和低劣的質量致使客戶對我們喪失信心。更長時間的工作卻生產出更加低劣的軟件產品，也使得開發人員感到沮喪。
壹旦經歷了這樣的慘敗，就會害怕重蹈覆轍。這種恐懼激發我們創建壹個過程來約束我們的活動、要求有某些人為制品（artifacts）輸出。我們根據過去的經驗來規定這些約束和輸出，挑選那些在以前項目中看起來好像工作得不錯的方法。我們希望這些方法這次還會有效，以消除我們的恐懼。
然而，項目並沒有簡單到使用壹些約束和輸出就能可靠防止錯誤的地步。當連續犯錯誤的時候，我們會對錯誤進行診斷，並在過程中增加更多的約束和人為制品來防止以後重犯這樣的錯誤。經過多次這樣的增加之後，我們就會不堪巨大、笨重的過程的重負，極大地降低我們完成工作的能力。
壹個大而笨重的過程會產生它本來企圖去解決的問題。它降低了團隊的開發效率，使得進度延期、預算超支。它降低了團隊的響應能力，使得團隊經常創建錯誤的產品。遺憾的是，許多團隊認為，這種結果是他們沒有采取更多的過程方法引起的。因此，在這種失控的過程膨脹中，過程會變得越來越龐大。
用失控的過程膨脹來形容2000年前後的許多軟件公司的情形是很合適的。雖然有很多團隊在工作中沒有使用過程的方法，但是采用龐大、重型的過程方法的趨勢卻在快速增長，在大公司中尤為如此。
看到過程方法的由來、演變，不難體會過猶不及。。。
law_bbc 2007-11-22 11:27 PM
（七）1.1敏捷聯盟
2001年初，由於看到許多公司的軟件團隊陷入了不斷增長的過程的泥潭，壹批業界專家聚集在壹起概括出了壹些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀（value）和原則。他們稱自己為敏捷（agile）聯盟。在隨後的幾個月中，他們創建了壹份價值觀聲明，也就是敏捷聯盟宣言（The Manifesto of the Agile Alliance）。
1．個體和交互勝過過程和工具
人是獲得成功的最為重要的因素。團隊中只有好的過程而沒有優秀的成員註定要失敗，不好的過程可以使最優秀的團隊成員失去效用。如果不能作為壹個團隊工作，那麽即使擁有壹批優秀的成員也壹樣會慘敗。
合作、溝通以及交互能力比單純的編程能力更為重要。壹個由平均水平程序員組成的團隊，如果具有良好的溝通能力，要比那些擁有壹批高水平程序員但不能交流的團隊更有可能獲得成功。
合適的工具對於成功非常重要，像編譯器、IDE、源代碼控制系統等。但工具的作用不應被過分的誇大，使用過多龐大、笨重的工具就像缺少工具壹樣，都是不好的。
建議從使用小工具開始，嘗試壹個工具，直到發現它無法適用時才更換。不要認為更大、更好的工具可以自動地幫妳做得更好，通常它們帶來的障礙要大於幫助。
團隊的構建要比環境的構建重要的多，應該首先致力於構建團隊，然後再讓團隊基於需要配置環境。
看來作者更多的著眼於“度”，很辯證的。
law_bbc 2007-11-23 11:24 PM
(八)2．可以工作的軟件勝過面面俱到的文檔
沒有文檔的軟件是壹種災難。代碼不是傳達系統原理和結構的理想媒介。團隊需要編制易於閱讀的文檔，來對系統及其設計決策的依據進行描述。
過多的文檔比過少的文檔更糟。眾多文檔意味著大量時間，而保持文檔與代碼同步所需時間更多；壹旦文檔與代碼失去同步，就變成龐大、復雜的謊言，會造成重大誤導。
對於團隊來說，編寫並維護壹份系統原理和結構方面的文檔總是個好主意，但是那份文檔應該是短小、主題突出的。
在給新的團隊成員傳授知識方面，最好的兩份文檔是代碼和團隊。代碼真實地表達了所做的事情，雖然從代碼中提取系統原理和結構可能是困難的，但代碼是唯壹沒有二義的信息源。在團隊成員的頭腦中保存著時常變化的系統脈絡圖，人與人之間的交互是把這份脈絡圖傳授給他人的最快、最有效的方式。
許多團隊因為重視文檔而非軟件，導致進度拖延，這常常是個致命的缺陷。“Martin文檔第壹定律”可以防止該缺陷：直到迫切需要並且意義重大時，才來編制文檔。
在中國的很多公司、團隊能做到嗎？
law_bbc 2007-11-24 10:29 PM
（九）3．客戶合作勝過合同談判
僅僅寫下壹份關於妳想要的軟件的描述，就讓人在固定的時間以固定的價格開發，這種方式將導致低劣的質量和失敗，有時失敗很慘重。
成功的項目需要有序、頻繁的客戶反饋，。不是依賴合同或關於工作的陳述，而是讓軟件的客戶和開發團隊密切地在壹起工作，並盡量經常地提供反饋。
壹個指明了需求、進度和項目成本的合同存在根本性的缺陷。在大多數情況下，合同中指明的條款遠在項目完成前就失去了意義。那些為開發團隊和客戶的協同工作方式提供指導的合同才是最好的合同。
項目成功的關鍵是和客戶真誠的協作，而合同指導了這種協作。
law_bbc 2007-11-27 12:31 AM
（十）4．響應變化勝過遵循計劃
響應變化能力常常決定著項目的成敗，因此我們應該制定靈活、適應商務和技術方面變化的計劃。
計劃不宜考慮過遠。原因：1、商務環境變化帶來需求變動；2、客戶可能隨著系統運作的進程改變需求；3、需求不變，我們仍然無法很好地估算出開發所需時間。
較好的做計劃的策略是：為下2周做詳細計劃，為下3個月做粗略計劃，再以後做極為粗糙的計劃。計劃中逐漸降低的細致度，可以保證除近幾周難以改變，計劃的其余部分仍保持著靈活性。
law_bbc 2007-11-28 02:44 PM
（十壹）1.2原則
從上述的價值觀引出了12條原則，它們是敏捷實踐區別於重型過程的特征所在。
1．我們最優先要做的是通過盡早地、持續地交付有價值的軟件來使客戶滿意。
MIT Sloan管理評論雜誌刊登過壹篇論文，分析了對於公司構建高質量產品方面有幫助的軟件開發實踐。該論文發現了很多對於最終系統質量有重要影響的實踐，其中壹個實踐表明，盡早地交付具有部分功能的系統和系統質量之間存在很強相關性。該論文指出，初期交付的系統中包含的功能越少，最終交付的系統質量就越高。
該論文的另壹項發現是，以逐漸增加功能的方式經常性地交付系統和最終質量之間有很強相關性。交付越頻繁，最終產品的質量就越高。
敏捷實踐會盡早地、經常地進行交付。我們努力在項目開始的幾周內就交付壹個具有基本功能的系統，然後我們努力每2周就交付壹個功能漸增的系統。
如果客戶覺得目前的功能已經足夠，客戶可以選擇把這些系統加入到產品中。
或者，他們可以簡單地選擇再檢查壹遍所有的功能，並指出他們想要做的改變。
law_bbc 2007-11-29 11:33 PM
（十二）2．即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化為客戶創造競爭優勢。
這是壹個關於態度的聲明。敏捷過程的參與者不懼怕變化。他們認為改變需求是好事情，因為那些改變意味著團隊已經學到了許多如何滿足市場需要的知識。
敏捷團隊會非常努力地保持軟件結構的靈活性，這樣當需求變化時，對於系統造成的影響是最小的。
3．經常地交付可以工作的軟件，交付的周期可以從幾周到幾個月，交付的時間間隔越短越好。
我們不贊成交付大量的文檔或計劃，我們認為那不是真正要交付的東西，我們關註的目標是交付滿足客戶需要的軟件。
4．在整個項目開發期間，業務人員和開發人員必須天天在壹起工作。
為了能夠以敏捷的方式進行項目開發，客戶、開發人員以及涉眾之間就必須進行有意義的、頻繁的交互。軟件項目不像發射出去就能自動導航的武器，必須要對項目進行持續不斷的引導。
law_bbc 2007-12-2 12:51 PM
（十三）5．圍繞被激勵起來的個人構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
在敏捷項目中，人被認為是項目取得成功的最重要的因素。所有其他因素——過程、環境和管理對人有負面影響時就要進行改變。
6．在團隊內部最具效果和最富的信息傳遞方法就是面對面交談。
在敏捷項目中，首要、默認的溝通方式就是面對面交談。敏捷團隊不需要書面的規範、計劃或設計。不會在文檔中包含所有項目信息，只在迫切需要和意義重大時才編寫文檔。
7．工作的軟件是首要的進度度量標準。
敏捷項目通過度量當前軟件滿足客戶需求的數量來度量開發進度，而不是根據所處開發階段、已編寫文檔的多少或已構建基礎結構代碼的數量進行度量。
8．敏捷過程提倡可持續開發速度，責任人、開發者和客戶應該能夠保持壹個長期的、恒定的開發速度。
敏捷過程不是50米短跑，跑得過快會導致團隊精力耗盡、出現短期行為以至於崩潰。敏捷團隊會測量自己的速度，他們不容許自己過於疲憊，他們不會借用明天的精力來在今天多完成壹點工作，他們工作在壹個可以於整個項目開發期間保持最高質量標準的速度上。
law_bbc 2007-12-3 11:57 PM
（十四）9．不斷關註優秀的技能和好的設計可以提高敏捷能力
高的產品質量是獲取高的開發速度的關鍵，保持軟件盡可能簡潔、健壯是快速開發軟件的途徑。因而所有敏捷團隊成員都致力於只編寫他們能夠編寫的最高質量的代碼，如果他們制造了混亂會在當天把它清理幹凈。
10．簡單——使未完成工作最大化的藝術——是根本的。
敏捷團隊不會去構建華而不實的系統，他們總是更願意采用和目標壹致的最簡單的方法。他們並不看重對於明天會出現問題的預測，也不會在今天就對那些問題進行防衛。他們會在今天以最高的質量完成最簡單的工作，深信即使明天發生問題也會很容易進行處理。
11．最佳的架構、需求和設計出自於自組織團隊。
敏捷團隊是自組織團隊。任務不是由外部分配給單個成員，而是分配給整個團隊，再由團隊確定完成任務的最佳方法。
敏捷團隊***同解決項目所有方面的問題。每壹個成員都具有項目中所有方面的參與權，整個團隊***同承擔系統架構、需求或者測試等責任，每壹個成員都能夠影響它們。
12．每隔壹定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地調整自己的行為。
敏捷團隊會不斷地對團隊的組織方式、規則、規範、關系等進行調整，他們知道為了保持團隊的敏捷性必須隨著環境的變化而變化。
law_bbc 2007-12-5 01:49 AM
（十五）第二章 極限編程概述
2.1極限編程實踐
極限編程（XP）是敏捷方法中最著名的壹個，它由壹系列簡單卻相互依賴的實踐組成，這些實踐結合在壹起形成了壹個勝過部分結合的整體。
2.1.1客戶作為團隊成員
我們希望客戶和開發人員在壹起緊密地工作，從而知曉對方所面臨的問題並***同解決之。
XP團隊中的客戶是指定義產品特性並排列這些特性優先級的人或團體。在XP項目中，無論誰是客戶，他們都是能夠和團隊壹起工作的團隊成員。
客戶和開發人員最好在同壹個房間工作，工作距離小於100米次之。距離越遠越難以融入團隊，無法成為真正的團隊成員。
如果確實無法於客戶壹起工作，建議去尋找能夠在壹起工作、願意並能夠代替真正客戶的人。
2.1.2用戶素材
為了制定計劃必須知道和項目需求有關的內容，必須知道存在許多細節、細節的大致分類，但是妳不必知道特定的細節。
需求的特定細節很可能隨時間而變化，看到新系統問世是關註需求的最佳時刻。
在XP中我們和客戶反復討論，以獲取對需求細節的理解，但是不去捕獲那些細節。需求估算是基於和客戶交談期間所得到的對細節的理解進行的。
用戶素材就是正在進行的關於需求談話的助記符，它是壹個計劃工具，客戶可以使用它並根據它的優先級和估算代價來安排實現該需求的時間。
law_bbc 2007-12-7 01:30 AM
（十六）2.1.3短交付周期
XP項目每2周交付壹次可工作軟件。每2周的叠代（重復周期或循環周期）都實現了涉眾的壹些要求。每次叠代結束後，會給涉眾演示叠代生成的系統，以得到他們的反饋。
1．叠代計劃
每次叠代通常花費2周。這是壹次較小的交付，可能會被加入到產品中。它由客戶根據開發人員確定的預算而選擇的壹些用戶素材組成。
開發人員通過度量以前叠代完成的工作量來為本次叠代設定預算。只要估算的成本總量不超過預算，客戶就可以為本次叠代選擇任意數量的用戶素材。
壹旦叠代開始，客戶就同意不再修改當前叠代中用戶素材的定義和優先級。叠代期間，開發人員可以自由地將用戶素材分解成任務，並依據最具技術和商務價值的順序來開發這些任務。
2．發布計劃
XP團隊通常會創建壹個包含隨後大約6次叠代內容的計劃，這就是所謂的發布計劃。壹次發布通常需要3個月的工作。它表示了壹次較大的交付，通常會被加入到產品中。發布計劃是由壹組客戶根據開發人員給出預算所選擇的、排好優先級的用戶素材組成。
開發人員可以度量以前發布的工作量來為本次發布設定預算。只要估算的成本總量不超過預算，客戶就可以為本次發布選擇任意數目的用戶素材。客戶同樣可以決定本次發布中用戶素材實現的順序。如果開發人員強烈要求的話，客戶可以通過指明哪些用戶素材應該在哪次叠代中完成的方式，制定出發布中最初幾次叠代的內容。
發布計劃不是壹成不變的，客戶可以隨時改變計劃的內容。他可以取消用戶素材，編寫新的用戶素材，或者改變用戶素材的優先級別。