2001 年由 17 位軟體開發的專家們齊聚在美國猶他州雪鳥滑雪場提出著名的『敏捷宣言』。

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃

『也就是說，雖然右側項目有其價值，但我們更重視左側項目。』

個人與互動重於流程與工具
『個人與互動』重於『流程與工具』，並不是表示敏捷方法不需要流程或工具，而是開發團隊與利益關係人（stakeholder）間能持續溝通與理解，透過快速的回饋機制，找出產品的最大價值。
『役物而不役於物』，流程與工具可以幫助開發效率，但是不該被流程與工具限制而減少溝通機會。比如說：很多專案開發都會使用專案追蹤軟體，但如果產品經理與開發團隊只會使用這些專案追蹤軟體進行討論，而不面對面直接溝通，這時候減少了溝通的機會，反而更不利溝通。

可用的軟體重於詳盡的文件
『可用的軟體』重於『詳盡的文件』，並不是表示敏捷方法不需要寫文件，而是在『可用的軟體』為前提的狀況下，一份『詳盡的文件』不是必須的。
舉例來說，一段容易理解的程式碼不是寫了很多註解，而是把『意圖』（Intention）在程式表達上盡可能讓接手的人簡單易懂，反而一份能沒有註解也能讓人理解的程式碼才是一段好的程式碼。同樣一份好的規格書，不是把只有由產品經理寫完就好，而是透過團隊持續溝通產出的共識版。

與客戶合作重於合約協商
『與客戶合作』重於『合約協商』，傳統的專案管理，需求方與開發方都需要一份『雙方都不會佔便宜的合約』，但是產品的最終價值其實是讓需求方盡可能滿意，如果能持續與需求方合作釐清需求，共同達到產品最大價值，這時候合約就相對上沒那麽重要。
舉例來說，與客戶合作的『雙贏』（Win-Win）合約比一份爭的你死我活的『雙輸』（Loss-Loss）合約更容易幫忙客戶創造價值。

回應變化重於遵循計劃
『回應變化』重於『遵循計劃』，傳統的專案管理，希望讓變數最小，專案能遵循計劃，如期如質如預算的交付。
但是在需求不是很明確，技術仍有尚未能掌控的能力時。此時，能快速回應市場與客戶端的回饋，反而比遵循計劃更能產品存活。

原文請參考：【文思不藏私】 敏捷幼幼班～敏捷宣言知多少