TOC
1. 個人與互動 重於 程序與工具
- 人是獲得成功最關鍵的因素
- 正確的工具 => 先用小工具開始，直到他無法適用。不要認為更大的工具會自動幫你把工作得更好，通常它造成的阻礙大於幫助。
2. 可用的軟體 重於 詳盡的文件
- 文件短小 - 代表最多大概不超過一二十頁
- 凸顯主題 - 則是僅限於論述系統的最高層結構和概括設計原理
- 最好的兩份文件是 程式碼 與 團隊
- Martin’s First Law of Documention 直到迫切需要且意義重大時，才撰寫文件
3. 與客戶合作 重於 合約的談判
- 成功的專案需要定期且頻繁的客戶回饋，絕不是依賴合約和關係工作的那些陳述。關鍵是讓軟體的客戶和開發團隊緊密地工作在一起，並盡可能經常地提供回饋。
4. 回應變化 重於 遵循計畫
- 做計劃時，較好的策略是：為下一周作詳細的計畫，為下3個月做粗略的計畫，在往後一年只做極為簡略的計畫。
原則
- 我們最優先的任務，是透過及早且持續地交付有價值的軟體來滿足客戶的需求。
- 我們竭誠歡迎客戶改變需求，即便已經到了開發後期亦然。敏捷程式能夠駕馭變更，為客戶創造競爭優勢。
- 經常交付可以工作的軟體，交付頻率可以從幾個星期到幾個月，而時間間隔是越短越好
- 業務人員與開發人員必須在專案開發的工程中，天天在一起工作。
- 依靠鬥志高昂的人來建置專案，並給予他們所需的環境和支援，信任他們能夠完成工作。
- 在團隊內部，效率最高且效果最佳的資訊傳遞方式，是面對面的交談。
- 可工作的軟體是進度最主要量測(度量)標準
- 敏捷程式提倡可持續的開發，贊助者、開發者和使用者應當總是保持穩定的開發速度。
- 持續追求卓越的技術和良好設計，將有助於提高敏捷性。
- 精簡 - 將未完成的工作量最大化的技藝 - 是不可或缺的。(今天以最高品質完成最簡單工作)
- 最佳的架構、需求與設計都源自於能夠自我組織的團隊。
- 每隔一段固定的時間，團隊會定期檢討如何更有效率，然後依照檢討結果，適當地調整與修正自己的行為。