態度決定一切
1.做事
職責不會修復bug。把矛頭對準問題的解決辦法，而不是人。這是真正有用處的正面效應。
2.欲速則不達
不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。
3.對事不對人
對事不對人。讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好。
4.排除萬難，奮勇前進
做正確的事。要誠實，要有勇氣去說出實情。有時，這樣做很困難，所以我們要有足夠的勇氣。
學無止境
5.跟蹤變化
跟蹤技術變化。你不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的項目和職業生涯。
6.對團隊投資
提供你和團隊學習的更好平臺。通過午餐會議可以增進每個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的熱情，將會對項目大有裨益。
7.懂得丟棄
學習新的東西，丟棄舊的東西。在學習一門新技術的時候，要丟棄會阻止你前進的舊習慣。畢竟，汽車要比馬車車廂強得多。
8.打破砂鍋問到底
不停地問爲什麼。不能只滿足於別人告訴你的表面現象。要不停地提問直到你明白問題的根源。
9.把我開發節奏
解決任務，在事情變得一團糟之前。保持事件之間穩定重複的間隔，更容易解決常見的重複任務。
交付用戶想要的軟件
10.讓客戶做決定
讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，並讓他們做決定。
11.讓設計指導而不是操縱開發
好設計是一張地圖，它也會進化。設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計（或設計師）操縱。
12.合理地實用技術
新技術就應該像是新的工具，可以幫助你更好地工作，它自己不應該成爲你的工具。
13.保持可以發佈
保持你的項目時刻可以發佈。保證你的系統可以隨時編譯、運行、測試並立即部署。
14.提早集成，頻繁集成
提早集成，頻繁集成。代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
15.提早實現自動化部署
一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置文件測試依賴的問題。質量保證人員要像測試應用一樣測試部署。
16.使用演示獲得頻繁反饋
清晰可見的開發。在開發的時候，要保持應用可見（而且客戶心中也要了解）。每隔一週或者兩週，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。
17.使用短迭代，增量發佈
增量開發。發佈帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周迭代週期。
18.固定的價格就意味着背叛承諾
基於真實工作的評估。讓團隊和客戶一起，真正地在當前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
敏捷反饋
19.守護天使
使用自動化的單元測試。好的單元測試能夠爲你的代碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何設計和代碼修改。
20.先用它再實現它
先用它再實現它。將TDD作爲設計工具，它會爲你帶來更簡單更有實效的設計。
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.及時通報進展與問題
及時通報進展與問題。發佈進展狀況、新的想法和目前正在關注的主題。不要等着別人來問項目狀態如何。