SQ3R閱讀法
Survey：瀏覽
1、書名：《Extreme Programming explained:Embrace Change》,中文譯名《解析極限編程：擁抱變化》；
2、作者：Kent Beck（肯特·貝克），美國著名軟件工程師與作家，在軟件工程方面有很大的貢獻。他是Smalltalk軟件的開發者，設計模式的先驅，測試驅動開發的支持者，也是極限編程的創始者之一。現在Facebook工作。
維基百科摘錄：
Beck全家似乎都瀰漫着技術的味道。生長在硅谷, 有着一個對無線電癡迷的祖父，以及一個電器工程師父親。從小就引導Kent Beck成爲了業餘無線電愛好者。在俄勒岡州大學讀本科期間，Kent Beck就開始研究起模式。然而在他最終拿到計算機學位之前，他卻是在計算機和音樂中交替學習。似乎Java大師都能夠有這樣的能耐，另一Java大牛Rod Johnson同樣也擁有音樂學的博士學位。 Kent Beck一直倡導軟件開發的模式定義。早在1993年，他就和Grady
Booch（UML之父）發起了一個團隊進行這個方面的研究。雖然著有了《Smalltalk Best Practice Patterns》一書，但這可能並不是Kent Beck最大的貢獻。他於1996年在DaimlerChrysler啓動的關於軟件開發的項目，才真正地影響後來的軟件開發。這次的傑作就是XP（極限編程）的方法學。和軟件開發大師Martin Fowler合著的《Planning Extreme Programming》可謂是關於XP的奠基之作。從此，一系列的作品如《Test
Driven Development: By Example》，《Extreme Programming Explained: Embrace Change》讓更多的人領略到了極限編程的精髓，也逐步導致了極限編程的流行。Kent Beck的貢獻遠不僅如此。對於衆多的Java程序員來說，他和Erich Gamma共同打造的JUnit，意義更加重大。也許正式這個簡單而又強大的工具，讓衆多的程序員更加認可和信賴極限編程，從而引起了Java敏捷開發的狂潮吧。
Questions（提出問題）
1、什麼是XP？
XP是一套軟件開發規則，它沒有新的概念，甚至好多都是存在很久的。它的創新之處在於把這些實踐結合在一起，並徹底地執行它們，並確保這些實踐在最大程度上相互支持！
2、XP適用於哪些情形？
XP適用於中小型團隊在需求不明確或者需求迅速變化的情況下進行軟件開發的輕量級方法學。
3、本書結構
本書分三個部分：
第一部分：問題——提出XP試圖解決的問題，並提出用來評估解決方案的標準；
第二部分：解決方案——將第一部分的抽象概念轉換爲具體方法論的實踐，但不會確切地說明如何實現這些實踐，而是討論大體結構；
第三部分：實現XP——如何採用XP來進行工作。
Read：
第一部分：問題
第一章 最基本的問題：風險
1、常見的風險以及XP如何化解？
（1）進度延遲——XP要求發行週期較短，最多爲幾個月；一個發行週期內，要求對客戶提出的功能進行一到四周的迭代，最後要求優先實現優先級較高的功能。
（2）項目取消——XP讓客戶選擇具有最大業務意義的最小版本，從而在投入生產前減少發生錯誤的機率；
（3）系統惡化——XP創建並維護一整套測試程序，每次發生變化後都要運行測試程序，以確保質量；
（4）缺陷率高——XP測試時，既遵從程序員按逐條功能編寫測試程序的觀點，又遵從客戶按逐個程序特性編寫測試程序的觀點；
（5）業務誤解——XP要求客戶成爲整個團隊的一部分。
（6）業務變更——XP縮短了版本週期，因此每個版本的開發過程中的變化就少；
（7）錯誤過多——XP強調只專注於具有最高優先級的任務；
（8）人員調整——XP要求程序員承擔估算和完成自己工作的責任，並將實際花費時間進行反饋，以改進他們的估算。
第二章 開發過程
1、XP開發的完整過程
（1）結對編程
（2）TDD驅動開發
（3）結對程序員不僅讓測試用例運行，還要改進系統設計
（4）開發之後接着進行集成，以及集成測試；
第三章 軟件開發的經濟學
1、從經濟上考慮，爲了使軟件開發更有價值，我們需要減少開銷，加快收益並增加項目的可能的高效生產期，但最重要的是我們需要增加用於業務決策的選擇。
第四章 四大變量
1、軟件開發過程中的四大變量
（1）成本——錢多一點可以促進工作順利進行，但是太短時間內投入太多金錢會產生更多無法解決的問題；
（2）時間——更長的交付時間有助於提高質量和擴大範圍；
（3）質量——有意識的犧牲質量，可能在短時間內獲利，但是未來耗費的成本是巨大的！
（4）範圍——更小的範圍有助於提高質量。
2、專注於範圍
（1）範圍是一個變化很大的量——因爲客戶根本不知道自己想要的是什麼！
（2）XP對控制範圍的解決辦法
a、進行大量估算和反饋實際結果的工作；
b、優先完成客戶最重要的功能！
第五章 變化的成本
1、軟件工程中一個普遍的假定是修改程序的成本會隨着時間的推移而以指數方式上升！——但是現在這個假設不再正確了！
2、XP能夠實現的結果是：隨着時間的推移，修改成本是一個平滑的曲線！
（1）簡單的設計
（2）自動測試
（3）改進設計
第六章 學會開車——我們需要反饋來知道我們何時犯了錯，而且需要能夠以比較合理的成本來完成糾正！每次修改一小步！
1、軟件中的一切東西都是變化的，需求變化、設計變化、業務變化、技術變化、團隊變化、團隊成員變化，只有變化纔是永遠不變的！
2、問題不在於變化，因爲變化總是發生的，問題在於發生變化時沒有能力應對！！
第七章 四大準則——衡量我們方向是否正確的標準！
1、XP的四個準則
（1）溝通——項目出現問題的一大原因是因爲溝通出現問題！
（2）簡單——簡單和溝通是相互支持的關係，溝通越多，要做的越簡單！
（3）反饋——樂觀是編程的一大忌，而反饋則是良藥！
（4）勇氣——要有勇氣更改體系結構的錯誤，要有勇氣放棄原有的代碼！
第八章 基本準則——知道我們進行具體的實踐！
1、基本準則
（1）快速反饋——行動與反饋之間的間隔是學習的關鍵！
（2）假設簡單性——把每個問題都看做可以用近乎荒謬的簡單方法來解決！
（3）遞增更改——每次修改一點點！
（4）提倡更改——最佳的策略就是在實踐中運用最多的辦法！
（5）優質工作——出色完成工作是每個人的希望！
第九章 回到基本問題——開發過程的基本工作！
1、開發過程中的基本工作
（1）編碼——編碼是最佳的實踐！
（2）測試——不能測試的功能是不存在的！
（3）傾聽——不懂業務的程序員不是合格程序員！
（4）設計——好的設計使系統能夠擴展！
第二部分 解決方案
第十章 簡短概述——依靠簡單的實踐之間的合作！
1、所有簡單實踐清單
（1）計劃遊戲——任何事情計劃先行！
a、業務人員需要決定的內容：
- 範圍——對系統而言，將問題解決到什麼程度是有價值的！
- 優先級——確定哪個更重要!
- 版本的組成——軟件完成多少才能使業務能夠因爲使用了該軟件而改善狀況！
- 發佈的日期——軟件發佈會造成重大影響的日期！
b、技術人員需要決定的內容：
- 估算——實現一個功能需要花費多長時間！
- 後果——有些戰略性的業務決策只有瞭解到技術後果後才能確定！
- 過程——如何組織工作和團隊！
- 詳細的日程設計——在一個版本里面，先完成哪些內容！
（2）小版本——每一個版本儘可能的小，包含最有價值的業務需求！
（3）隱喻——引入隱喻，易於溝通和闡述體系結構！
（4）簡單設計——去掉任何可以拿掉而不違反規則的設計！
（5）測試——沒有經過自動化測試的功能是不能夠存在的！
（6）重構——重構是優化系統的捷徑！
（7）結對編程——效率更高的編程！
（8）集體所有權——任何人發現改進任何代碼的機會，都可以進行立即執行！（XP中每個人都對系統負責！）
（9）持續集成——減少出差機會！
（10）每週工作40小時——XP規則很簡單，不能連續兩週加班！
（11）現場客戶——真實的客戶必須與團隊一起工作！
（12）編碼標準——標準可以減少溝通成本！
第十一章 如何湊效——實踐相互支持，一種實踐的弱點可以由其他實踐的優點來彌補！
1、任何實踐都難以獨擋重任，它們需要其他實踐來幫助保持平衡！
第十二章 管理策略——使用商業基本要素全面管理項目
1、度量——製作大的可視表，對任務總量進行度量！
2、指導——好的教練是一個好的溝通者！
a、衡量教練的標準是她做出了多少個技術性決策！
3、跟蹤——蒐集某個時刻所有正在跟蹤的測試數據，確保團隊的實際進度！
4、干預——管理人員進行干預，可能是人員變動，可能是終止項目！
第十三章 設備策略——爲團隊創建開放的工作空間，外圍是小的私人空間，中間是公共編程區！
第十四章 拆分業務責任和技術責任——技術人員把精力集中在技術問題上，業務人員把精力集中在業務問題上！
1、項目必須由業務決策來驅動，而技術決策則要給業務決策提供有關成本和風險的信息！
2、業務方和開發方任何一方得到權力過大，都會對項目造成損害！
第十五章 計劃策略——迅速制定一個總體計劃，然後在越來越短的時間內逐步將其完善！
1、制定計劃是猜測爲客戶開發一套軟件 的情況是什麼樣的過程！
2、制定計劃的目的
（1）團結和組織團隊開發
（2）決定範圍和優先級
（3）估算成本和日程
（4）讓大家對系統的成功信心百倍
（5）爲反饋提供一個基準
第十六章 開發策略——背離傳統的開發觀念，我們認真制定今天問題的解決方案，並相信我們能夠在明天解決明天的問題！
1、開發策略從迭代計劃開始，持續集成減少了開發衝突併爲開發過程創造了一個自然而然的結尾，集體所有權鼓勵整個團隊改善整個系統，最後結對編程將整個過程聯繫在一起！
2、持續集成——幾個小時就集成一次！
3、集體所有權——複雜代碼不會生存很長時間！
4、結對編程——值得用整個後半生來研習並得益！
第十七章 設計策略——永遠使用能運行當前測試套件的最簡單設計！
第十八章 測試策略——在編碼前編寫測試，並一直保留這些測試，並頻繁地運行全部測試！
1、單元測試和功能測試是測試策略的核心！
2、其他測試
（1）並行測試——顯示出新系統與舊系統之間差異的測試；
（2）壓力測試——模擬可能的最高負載測試；
（3）靈活測試——確保遇到無意義的輸入時能做出有意義的反應的測試。
第三部分 實現XP——實現上一部分的策略！
第十九章 採用XP——一次一種實踐地採用XP。始終處理團隊最緊急的問題！
1、實現XP的步驟
（1）找出最緊急的問題；
（2）以XP方式解決它；
（3）重複上述步驟！
第二十章 改進XP
第二十一章 理想的XP項目的生命週期——任意兩個XP項目都不可能是完全相同的！
1、XP項目的聲明週期
（1）探索
（2）計劃
（3）第一本迭代
（4）生產
（5）維護
（6）死亡
第二十二章 人員的角色——程序員、客戶、教練、跟蹤者！
1、程序員——XP的核心
2、客戶——極限編程中的重要組成部分！
3、測試員——負責編寫功能測試
4、跟蹤者——最好估算、收集反饋
5、教練——負責整個過程
6、顧問——幫助解決某個領域深入的技術知識問題
7、大老闆——提供團隊勇氣、信心以及放權！
第二十三章 20-80原則——XP需要集合全部實踐才能發揮最大功效！
1、程序員們喜歡使用20-80原則——80%的效益來自於20%的工作！
第二十四章 使XP難以執行的原因——人的恐懼心理！
1、XP在細節上很簡單，但是執行起來很困難！
第二十五章 什麼時候不應該使用XP——團隊太大、客戶多疑以及技術不能很好地支持更改！
第二十六章 工作中的XP——使用適用於XP的合同！
第二十七章 結論——XP讓你克服心中的恐懼！
Recite:
Review: