第1章 敏捷——高效軟件開發之道
- 敏捷開發宣言
*個體和交互勝過過程和工具
*可工作的軟件勝過面面俱到的文檔
*客戶協作勝過合同談判
*響應變化勝過遵循計劃
2. 敏捷工具箱
*Wiki
*版本控制
*單元測試
*自動構建
第2章 態度決定一切
態度非常重要，包括團隊中的所有人。專業的態度應該着眼於項目和團隊的積極結果，關注個人和團隊的成長，圍繞最後的成功開展工作。
1. 做事
在敏捷團隊中，大家的重點是做事。他們把精力直接放到解決問題上，而不是抱怨。你可以從自己先做起。如果一個開發者帶着抱怨或者問題來找你，你要了解具體的問題，詢問他你能提供什麼樣的幫助，這樣簡單的一個行爲就清晰地表明你的目的是解決問題，而不是追究責任。
指責不能修復bug(Blame doesn’t fix bugs)。把矛頭對準問題的解決方法，而不是人。這纔是真正有用處的正面效應。
- 欲速則不達
在修改代碼之前一定要很好地理解它。
如果團隊成員花些時間閱讀其他同事寫的代碼，他們就能確保代碼是可讀和可理解的。實行CodeReview，不僅有助於代碼更好理解，而且是發現bug最有效的方法之一。
另一種防止代碼難懂的重要技術就是UnitTest。Unit Test幫助你很自然地把代碼分層，分成很多可管理的小塊，這樣就會得到設計更好、更清晰的代碼。在更深入項目的時候，可以直接閱讀單元測試——它們是一種可執行的文檔。
不要墜入快速的bugfix之中。要投入時間和精力保持代碼的整潔。
- 對事不對人
在同事John描述了自己的觀點後，對於你的顧慮最適合並且最有效的表達方式應該是：“謝謝，John，但是我想知道，如果兩個用戶同時登陸會發生什麼情況？”——詢問你的隊友，並提出你的顧慮，而不是否定其觀點，更不是否定其個人能力。
在隊友提出想法後，應該多給予鼓勵，而不是否定，有利於問題的解決。
有效的特殊技術：
*設定最終期限。如參加設計方案，設定一個明確的deadline，例如午飯時間或者一天的結束。最有最好的答案，只有更合適的方案。
*逆向思維。先是積極地看到它的正面，然後努力地從反面去認識它。目的是要找出優點最多缺點最少的那個方案。
*設立仲裁人。選擇一個仲裁人作爲本次會議的決策者，確保每個人都有發言的機會。
*支持已經做出的決定。一旦方案被確定了，每個成員都必須通力合作，努力實現這個方案。
設計充滿了妥協（生活本身也是如此），成功屬於意識到這一點的團隊。在開始尋找最好的解決方案之前，大家對“最好”的含義要先達成共識，包括對開發者和用戶。
- 排除萬難，奮勇前進
當發現問題時，不要試圖掩蓋這些問題。而要有勇氣站起來，說：“我現在知道了，我過去使用的方案不對。我想到了一些辦法，可以解決這個問題。”
做正確的事。要誠實、要有勇氣去說出實情。有時，這樣做很困難，所以我們要有足夠的勇氣。
如果遇到一段奇怪的代碼，在你沒有馬上理解那段代碼，不要輕易地否定和重寫它們。那不是勇氣，那是魯莽。
第3章 學無止境
敏捷需要持續不斷的學習和充電。
- 跟蹤變化
跟上技術變化的步伐的建議：
*迭代和增量式的學習。每天計劃用一段時間來學習新技術。記下那些想學的東西，然後在計劃的時間中深入研究它。
*瞭解最新行情。互聯網上有大量的關於學習新技術的資源。選擇一些公認的優秀技術博客，經常去讀一讀。
*如飢似渴地閱讀。找一些關於軟件開發和非技術主題的好書，也可以是一些專業的期刊和商業雜誌。
跟蹤技術變化。不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的項目和職業生涯。
- 對團隊投資
提供你和團隊學習的更好平臺。堅持有計劃有規律地舉行講座，不要侷限於純技術的圖書和主題，相關的非技術主題（項目估算、溝通技巧等）也會對團隊有幫助。
- 懂得丟棄
敏捷的根本之一就是擁抱變化。學習新的東西，丟棄舊的東西。
- 打破沙鍋問到底
在遇到/修復一個問題前，多問幾個爲什麼，不停地問爲什麼，不能只滿足於別人告訴你的表面現象。要不停地提問直到你明白問題的根源。但是，問問題，要問到點子上。還有，在問問題之前，想好爲什麼有這個疑問，爲什麼要問這個問題。
- 把握開發節奏
解決任務，在事情變得一團糟之前。
在每天結束的時候，測試代碼，提交代碼，沒有殘留的代碼。不要搞得經常加班。以固定、有規律的長度運行開發迭代週期。小而可達的目標會讓每個人全速前進。慶祝每一次難忘的成功：共享美食或團隊聚餐。
第4章 交互用戶想要的軟件
- 讓客戶做決定
在設計方面，做決定的時候必須有開發者參與。可是，在一個項目中，他們不應該做所有的決定，特別是業務方面的決定。
要麼現在就讓用戶做決定，要麼現在就開始開發，遲些讓用戶決定，不過要付出較高的成本。
開發者（及項目經理）能做的一個最重要的決定就是：判斷哪些是自己決定不了的，應該讓客戶做決定。
讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題並讓他們做決定。
記錄客戶做出的決定，並註明原因，可以使用工程師的工作日誌或Wiki、郵件記錄等。
- 讓設計指導而不是操縱開發
- 合理地使用技術
不要開發你能下載到的東西
- 保持可以發佈
已提交的代碼應該隨時可以行動。在團隊裏工作，修改一些東西的時候必須很謹慎，要時刻警惕，每次改動都會影響系統的狀態和整個團隊的工作效率。
下面是一個簡單的工作流程，可以防止你提交破壞系統的代碼：
(1).在本地運行測試。先保證完成的代碼可以編譯，並且能通過所有的單元測試，接着確保系統中的其他測試都可以通過。
(2).check-out最新的代碼。從版本控制系統中更新代碼到最新的版本，再編譯和運行測試。這樣往往會發現讓你吃驚的事情：其他人提交的新代碼和你的代碼發生了衝突。
(3).提交代碼。現在是最新的代碼了，並且通過了編譯和測試，可以提交它們了。
保證你的項目時刻可以發佈。保證你的系統隨時可以編譯、運行、測試並立即部署。
如果不得不讓系統長期無法發佈，就做一個branch版本，可以繼續自己的修改，如果不行，還可以撤銷，千萬不能讓系統既不可以發佈，又不可以撤銷。
- 提早集成，頻繁集成
集成和獨立不是相互矛盾的，可以一邊進行集成，一邊進行獨立開發。使用mock對象來隔離對象之間的依賴關係，這樣在集成之前就可以先做測試。可以使用mock對象，編寫獨立的單元測試，而不需要立刻就集成和測試其他系統，只有當你自信它能工作時，纔可以集成。
一般需要每天集成幾次，最好不要2~3天才集成一次。絕不要做大爆炸式的集成。如果集成的問題很大，那一定是做得不夠頻繁，會發現整天在解決集成帶來的問題。
- 提早實現自動化部署
一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置文件測試依賴問題。QA人員要像測試應用一樣測試部署。
在沒有詢問並徵得用戶的同意前，安裝程序絕對不能刪除用戶的數據。這個有親身體驗，一個同事應一客戶需求，給客戶做了個小工具，沒有問清客戶在什麼樣的環境下使用，結果客戶拿到工具，一執行，把客戶的某些文件給刪了，客戶那個氣啊……
- 使用演示獲得頻繁反饋
需求就像流動着的油墨。我們經常看到，給客戶演示所完成功能的時間與得到客戶需求的時間間隔越長，那麼你就會離最初需求越來越遠。應該定期地，每隔一段時間，例如一個迭代的結束，就與客戶會晤，並且演示你已經完成的功能特性。
清晰可見的開發。在開發的時候，要保持應用可見。每隔一週或兩週，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。當然，還要尊重客戶的時間，如果客戶只可以接受一個月一次的會議，那麼就定一個月。
- 使用短迭代，增量發佈
對付大項目，最理想的方法就是小步前進，這也是敏捷方法的核心。短迭代讓人感覺非常專注且具效率。
增量開發。發佈帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周左右迭代週期。
- 固定的價格就意味着背叛承諾
第5章
第6章
第7章
第8章