- 需求文件：充滿著"應該"、"必須"之類的要求
- 使用案例：可以用來分類和定義系統行為，幫盼我們真正弄清楚軟體應該要做的事、將要做的事，還有必須要做的事
- 閱讀需求文件，同時討論需求的含意以及隱含的系統行為，並將其命名為一堆的使用案例，可以了解系統邊界和系統行為
- 使用案例鑑定：目的是為所有的行為命名
- 團隊中有專人代表客戶的利益。客戶決定產品的功能範圍，及負責驗收和測試產品。意味著當中要有技術熟練的 QA 團隊成員
- 使用者敘述代表系統的某一性能。它很小，小到一個人在一個迭代中就足以完成。如果敘述太大造成一個迭代不能完成，就要分成更小的敘述
- 小發行版是以小版本為建構的基礎，每個迭代持續兩個星期，一個版本是一組迭代的工作，迭代的發行要為系統使用者提供有價值的功能
- 驗收測試提供敘述背後的細節，而且會在敘述開發之前界定清楚。測試必須要能夠自動化完成，而且可以在任何時間運作，一般每天會執行很多次
- 團隊要在開發工作空間工作，可以方便互相溝通，使用各種設備和了解專案訊息
- 測試驅動設計：以非常小，可驗證的步驟開發軟體。先寫小測試，然後寫大小剛好的程式碼來滿足測試，接下來再寫另一個新測試，以此類推
- 兩個程式設計師相互協同作業解決一個問題
- 程式碼必須有一個共同的模式，以方便程式設計師之間的溝通
- 持續整合：多次的整合和測試軟體，避免大規模的分支和合併
- 共享所有權，團隊擁有程式碼，程式設計師成對修改任何一段需要修改的程式碼。廣泛的單元測試助於防止團隊寫出錯誤的程式碼
- 團隊需要保持活力，以高效率開發軟體。過多的加班會導致品質下降，人員倦怠，會出現不可預測的結果。每個人都要努力工作，但必須能同時保有持續性的步調
- 設計文件的目的是為了提供系統一個高階路線圖
- 設計細節會顯現在程式碼和所對應的測試中
- 測試優先程式設計概念，就會有許多自動化的單元測試，每一個測試的使用案例就是詳細的文件
- 一旦學會閱讀測試，測試就會成為一種非常有效的詳細文件。它不像散文形式的文件，人們必須閱讀和理解。而且此測試規範可以被執行，無論何時，只要有任何偏差都可以看出來
- 測試像是一個不斷送出的禮物
- 形成一個偉大團隊的第一要件：一位有遠見、敢擔當、願意支持團隊的管理者，而且讓我們安全地突破現有的既定規範
- 要成為一個成功的重構者，必須能尋找和識別程式碼的壞味道。察覺問題是邁向成功的第一步
- 成對開發確實有助於打破溝通障礙。當你和某人坐在一起幾個小時，你透露出自己的優勢和弱點。這是一個雙向溝通，有了正確的人和正確的態度，會增長學習的情況和相互的信任
- 文件永遠不可能描述到所有細節，唯一具備了所有細節的需求形式就是程式碼
- 大公司有一種壞習慣，人被當成是一台機器的零件。人不是可以隨意更換的零件。一個態度惡劣的人，可以將整個團隊士氣拉下來
- 組成團隊的是人，不是資源