第1章 敏捷-高效軟體開發之道

第2章 態度決定一切
1.做事
指責不會修復bug。把矛頭對準問題的解決方法，而不是人。
2.欲速則不達
不要墜入快速的簡單修復之中。要投入時間和精力保持程式碼的整潔、敞亮。
3.對事不對人
設定最終期限；逆向思維；設立仲裁人；支援已經做出的決定。
4.排除萬難，奮勇前進
做正確的事。要誠實，要有勇氣去說出實情。

第3章 學無止境
5.跟蹤變化
跟蹤技術變化。你不需要精通所有技術，但需要清除知道行業的動向，從而規劃你的專案和職業生涯。
迭代和增量式的學習；瞭解最新行情；參加本地的使用者組活動；參加研討會議；如飢似渴地閱讀。
6.對團隊投資
提供你和團隊學習的更好平臺。通過午餐會議可以增進每個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對專案大有裨益。
7.懂得丟棄
學習新的東西，丟棄舊的東西。在學習一門新技術的時候，要丟棄會阻止你前進的舊習慣。
8.打破砂鍋問到底
不停地問為什麼。不能只滿足於別人告訴你的表明現象。要不停地提問直到你明白問題的根源。
9.把握開發節奏
解決任務，在事情變得一團糟之前。保持事件之間穩定重複的間隔，更容易解決常見的重複任務。

第4章 交付使用者想要的軟體
10.讓客戶做決定
讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。
11.讓設計指導而不是操作開發
好設計是一張地圖，它也會進化。設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計操縱。
12.合理地使用技術
根據需要選擇技術。首先決定什麼是你需要的，接著為這些具體的問題評估使用技術。對任何要使用的技術，多問一些挑剔的問題，並真實地作出回答。
13.保持可以釋出
保持你的專案時刻可以釋出。保證你的系統隨時可以編譯、執行、測試並立即部署。
14.提早整合，頻繁整合
提早整合，頻繁整合。程式碼整合是主要的風險來源。要想規避這個風險，只有提早整合，持續而有規律地進行整合。
15.提早實現自動化部署
一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置檔案測試依賴問題。
16.使用演示獲得頻繁反饋
清晰可見的開發。在開發的時候，要保持應用可見。每隔一週或者兩週，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。
17.使用短迭代，增量釋出
增量開發。釋出帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周左右迭代週期。
18.固定的價格就意味著背叛承諾
基於真實工作的評估。讓團隊和客戶一起，真正地在當前專案中工作，做具體實際的評估。由客戶控制他們要的功能和預算。

第5章 敏捷反饋
19.守護天使
使用自動化的單元測試。好的單元測試能夠為你的程式碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何設計和程式碼修改。
20.先用它再實現它
先用它再實現它。將TDD（測試驅動開發）作為設計工具，它會為你帶來簡單更有實效的設計。
21.不同環境，就有不同問題
不同環境，就有不同問題。使用持續整合工具，在每一種支援的平臺和環境中執行單元測試。要積極地尋找問題，而不是等問題來找你。
22.自動驗收測試
為核心的業務邏輯建立測試。讓你的客戶單獨驗證這些測試要讓他們像一般的測試一樣可以自動執行。
23.度量真實的進度
度量剩下的工作量。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。
24.傾聽使用者的聲音
每一個抱怨的背後都隱藏了一個事實。找出真相，修復真正的問題。

第6章 敏捷編碼
25.程式碼要清晰地表達意圖
要編寫清晰的而不是討巧的程式碼。向程式碼閱讀者明確表明你的意圖，可讀性差的程式碼一點都不聰明。
26.用程式碼溝通
用註釋溝通。使用細心選擇的、有意義的命名。用註釋描述程式碼意圖和約束。註釋不能替代優秀的程式碼。
27.動態評估取捨
動態評估權衡。考慮效能、便利性、生產力、成本和上市時間。如果效能表現足夠了，就將注意力放在其他因素上。不要為了感覺上的效能提升或者設計的優雅，而將設計複雜化。
28.增量式程式設計
在很短的編輯/構建/測試迴圈中編寫程式碼。這要比花費長時間僅僅做編寫程式碼的工作好的多。可以建立根據清晰、簡單、易於維護的程式碼。
29.保持簡單
開發可以工作的、最簡單的解決方案。除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
30.編寫內聚的程式碼
讓類的功能儘量集中，讓元件儘量小。要避免建立很大的類或元件，也不要建立無所不包的大雜燴類。
31.告知，不要詢問
告知，不要詢問。不要搶別的物件或是元件的工作。告訴它做什麼，然後盯著你自己的職責就好。
32.根據契約進行替換
通過替換程式碼來擴充套件系統。通過替換遵循介面契約的類，來增加並改進功能特性。要多使用委託而不是繼承。

第7章 敏捷除錯
33.記錄問題解決日誌
維護一個問題及其解決方案的日誌。保留解決方案是修復問題過程的一部分，以後發生相同或類似問題時，就可以很快找到並使用了。
34.警告就是錯誤
將警告視為錯誤。簽入帶有警告的程式碼，就跟簽入有錯誤或者沒有通過測試的程式碼一樣，都是極差的做法。簽入構建工具中的程式碼不應該產生任何警告資訊。
35.對問題各個擊破
對問題各個擊破。在解決問題時，要將問題域與其周邊隔離開，特別是在大型應用中。
36.報告所有的異常
處理或是向上傳播所有的異常。不要講它們壓制不管，就算是臨時這樣做也不行。在寫程式碼時要估計到會發生的問題。
37.提供有用的錯誤資訊
展示有用的錯誤資訊。提供更易於查詢錯誤細節的方式。發生問題時，要展示出儘量多的支援細節，不過別讓使用者陷入其中。

第8章 敏捷協作
38.定期安排會面時間
使用立會。立會可以讓團隊達成共。保證會議短小精悍不跑題。
立會：必須站著，不能坐著，否則會影響會議時間，因為大部分不喜歡站著進行長時間的談話。
立會議題：昨天有什麼收穫；今天計劃要做哪些工作；面臨著哪些障礙。
39.架構師必須寫程式碼
優秀的設計從積極的程式設計師那裡開始演化。積極的程式設計可以帶來深入的理解。不要使用不願意編碼的架構師-不知道系統的真實情況，是無法展開設計的。
40.實行程式碼集體所有制
要強調程式碼的集體所有制。讓開發人員輪換完成系統不同領域中不同模組的不同任務。
41.成為指導者
要強調程式碼的集體所有制。讓開發人員輪換完成系統不同領域中不同模組的不同任務。
42.允許大家自己想辦法
給別人解決問題的機會。指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。
43.準備好後再共享程式碼
準備好後再共享程式碼。絕不要提交尚未完成的程式碼。故意嵌入編譯未通過或者沒有通過單元測試的程式碼，對專案來說，應被視作玩忽職守的犯罪行為。
44.做程式碼複查
複查所有的程式碼。對於提升程式碼質量和降低錯誤率來說，程式碼複查是無價之寶。如果以正確的方式進行，複查可以產生非常實用而高效的成果。要讓不同的開發人員在每個任務完成後複查程式碼。
45.及時通報進展與問題
及時通報進展與問題。釋出進展狀況、新的想法和目前正在關注的主題。不要等著別人來問專案狀態如何。

第10章 尾聲：走向敏捷