態度決定一切
(1)做事，把矛頭對準問題的解決辦法，而不是人，這是真正有用處的正面效應
(2)欲速則不達，要投入時間和精力保持代碼的整潔、敞亮
(3)對事不對人，讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好
(4)排除萬難，奮勇前進，要誠實有勇氣去說出實情，有時候這樣做很困難，所以我們需要有足夠的勇氣
學無止境
(5)跟蹤變化，不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的項目和職業生涯
(6)對團隊投資，通過午餐會議可以增進每個人的知識和技能，并幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對項目大有裨益。
(7)懂得丟棄，在學習一門新技術的時候，要丟去會阻止你前進的舊習慣。畢竟，汽車要比馬車強得多。
(8)打破沙鍋問到底，不能只滿足與別人告訴你的表面現象。要不停地提問直到你明白問題的根源。
(9)把握開發節奏，保持時間之間穩定重復的間隔，更容易解決常見的重復任務
交付用戶想要的軟件
(10)讓客戶做決定，開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，并讓他們做決定。
(11)讓設計指導而不是操縱開發，設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計（或者設計師）操控。
(12)合理地實用技術，首先決定什么是你需要的，接著為這些具體的問題評估使用技術，對任何要使用的技術，多問一些挑剔的問題，并真實地作出回答。新技術就應該像是新的工具，可以幫助你更好地工作，她自己不應該是成為你的工作。
(13)保持可以發布，保證你的系統隨時可以編譯、運行、測試并立即部署。
(14)提早集成，頻繁集成，代碼集成式主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
(15)提早實現自動化部署，使用部署系統安裝你的應用，在不同的機器上用不同的配置文件測試依賴問題。質量保證人員要像測試應用一樣測試部署。
(16)使用演示獲得頻繁反饋，在開發的時候，要保持應用可見（而且客戶心中也要了解）。每隔一周或者兩周，邀請所有客戶，給他們演示最新完成的功能，積極獲得他們的反饋。
(17)使用短迭代，增量發布，發布帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周左右的迭代周期。
(18)固定的價格就意味著背叛承諾，讓團隊和客戶一起，真正地在當前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
敏捷反饋
(19)守護天使，好的單元測試能夠為你的代碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何的設計和代碼修改。
(20)先用它再實現它，使用測試驅動開發作為設計工具，它會為你帶來更簡單更實效的設計。
(21)不同環境，就有不同問題，使用持續集成工具。在每一種支持的平臺和環境中運行單元測試。要積極地尋找問題，為不是等問題來找你。
(22)自動驗收測試，為核心的業務邏輯創建測試，讓你的客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動運行。
(23)度量真實的進度，不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。
(24)傾聽用戶的聲音，每一個抱怨的背后都隱藏了一個事實，找出真相，修復真正的問題。
敏捷編碼
(25)代碼要清晰地表達意圖，向代碼閱讀者明確表明你的意圖。可讀性差的代碼一點也不聰明。
(26)用代碼溝通，使用細心選擇的、有意義的命名。用注釋描述代碼意圖和約束。注釋不能替代優秀的代碼。
(27)動態評估取舍，考慮性能、便利性、生產力、成本和上市時間。如果性能表現足夠了，就將注意力放在其他因素上。不要為了感覺上的性能提升或者設計的優雅，而將設計復雜化。
(28)增量式編程，在很短的編輯/構建/測試循環中編寫代碼，這要比花費長時間僅僅做編寫代碼的工作好得多。可以創建更加清晰、簡單、易于維護的代碼。
(29)保持簡單，除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
(30)編寫內聚的代碼，讓類的功能盡量集中，讓組件盡量小。要避免創建很大的類或組件，也不要創建無所不包的大雜燴類。
(31)告知，不要詢問，不要搶別的對象或者是組件的工作。告訴它做什么，然后盯著你自己的指責就好了。
(32)根據契約進行替換，通過替換遵循接口契約的類，來添加并改進功能特性。要使用更多的委托而不是繼承。
敏捷調試
(33)記錄問題解決日志，保留解決方案是修復問題過程的一部分，以后發生相同或類似問題時，就可以很快找到并使用了。
(34)警告就是錯誤，簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。簽入構建工具中的代碼不應該產生任何警告信息。
(35)對問題各個擊破，在解決問題時，要將問題域與周邊隔離開。特別是在大型應用中。
(36)報告所有的異常，不要將它們壓制不管，就算是臨時這樣做也不行，在寫代碼時要估計到會發生的問題。
(37)提供有用的錯誤信息，提供更多易于查找錯誤細節的方式，發生問題時，要展示出盡量多的支持細節，不過別讓用戶陷入其中。
敏捷協作
(38)定期安排會面時間。使用立會(站著開的會議)可以讓團隊達成共識。保證會議短小精悍不跑題。
(39)架構師必須寫代碼。優秀的設計從積極的程序員那里開始演化。積極的編程可以帶來深入的理解。不要使用不愿意編程的架構師——不知道系統的真實情況。是無法展開設計的。
(40)實行代碼集體所有制。讓開發人員輪換完成系統不同領域中不同模塊的不同任務。
(41)成為指導者。分享自己的知識很有趣——付出的同時便有收獲。還可以激勵別人獲得更好的成果，而且提升了整個團隊的實力。
(42)允許大家自己想辦法。指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。
(43)準備好后再共享代碼。絕對不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有通過單元測試的代碼，對項目來說，應該被視作為玩忽職守的犯罪行為。
(44)做代碼復查。對于提升代碼質量和降低錯誤率來說，代碼復查是無價之寶。如果以正確的方式進行，復查可以產生非常實用而高效的成果。要讓不同的開發人員在每個任務完成后復查代碼。
(45)及時通報進展與問題。發布進展狀況，新的想法和目前正在關注的主題。不要等著別人來問項目狀態如何。
iReader iReader Logo
http://book.douban.com/review/4880087/
