一、敏捷的原則：

除了敏捷宣言之外，宣言的發起者還為敏捷方法提供了12條指導原則

• 1、我們的最高目標是通過盡早和持續地交付有價值的軟件/產品來滿足客戶。
• 2、即使在項目開發的后期，仍歡迎對需求提出變更。敏捷過程通過擁抱變化，幫助客戶創造競爭優勢。
• 3、要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
• 4、在項目過程中，業務人員與開發人員要每天在一起工作
• 5、要善于激勵項目人員，給他們所需要的環境和支持，并相信他們能夠完成任務
• 6、團隊內部和各個團隊之間，最有效的溝通方法是面對面的溝通。
• 7、可工作的軟件是衡量進度的首要指標
• 8、敏捷過程提倡可持續的發展。項目方、開發人員和用戶應該能夠保持恒久、穩定的進展速度。
• 9、對技術卓越和好的設計的持續關注有助于增強敏捷性。
• 10、盡量做到簡介、盡最大可能減少不必要的工作。這是一門藝術。
• 11、最佳的架構、需求和設計出自自組織團隊。
• 12、團隊要定期回顧和反省如何能夠做到更有效，并相應地調整團隊的行為

二、敏捷的原則的解讀

(一)、我們的最高目標是通過盡早和持續地交付有價值的軟件來滿足客戶

• 第一點 是要滿足客戶需求。如果我們只創造了完美的項目計劃和文檔來讓公司的項目管理辦公室(PMO)或者質量保證工程師(QA)滿意，那么我們就是失敗的。我們關注的焦點應該是客戶，客戶滿意是衡量項目成功的關鍵因素。
• 第二點 是要盡早和持續交付。我們必須讓我們的項目和項目團隊盡早交付及頻繁交付，鼓勵和支持團隊成員認同這個觀點。早起發現錯誤會有足夠的時間去修正，修正的成本也是最低的。
• 第三點 是要交付有價值的軟件，而不是未完成的工作產品、工作分解結構(WBS)術語、文檔或者項目計劃。應該有具有目標驅動，對軟件項目而言，目標就是可工作的軟件；對于其他類型的項目而言，目標是產出的產品和服務或者成果。

(二) 即使在項目開發的后期，仍歡迎對需求提出變更。敏捷過程通過擁抱變化，幫助客戶創造競爭優勢。

如果是為了交付更好的成果和更高優先級的產品，那么變更對項目就是好事。對于傳統項目管理而言，變通通常被認為是負面的，這意味著項目范圍蔓延和偏離了項目的計劃，需要引發變更成本。所以傳統項目中變更控制流程非常嚴格，只有最高優先級的更變可以被批準。在傳統項目中，項目團隊大量的時間和精力都用在記錄和管理變更請求上。

在軟件項目或者其他類型的有高變更比率的項目而言，嚴格的變更管理流程會帶來很多問題。相比而言，敏捷項目管理允許變更的發生，比如極限變成(XP)提倡"擁抱變化"。敏捷使用輕便、高可視化的方法來處理待辦事項的優先級排序的變更。

高效處理變更可以幫助項目團隊把更多的時間投入在產品開發商，而不是處理變更商。敏捷方法就是利用易理解、高可視的方法來處理變更，使項目更加靈活。

(三) 要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。

雖然我們倡導越早反饋越有價值，但是每個人都會要求完美，把工作長時間抓在受傷反而會適得其反。最好的方式是盡早并且要經常得到對工作產品的反饋，以避免在錯誤的道路上越走越遠。

本條準則重點強調了將工作產品投入到測試環境從而獲得反饋。頻繁測試和反饋對敏捷項目非常重要，團隊需要根據已完成的產品反饋來確定如何繼續。當然，反饋中也會存在變更的要求。

短時間的交付有利于團隊和業務人員之間的互動。頻繁的交付使得項目團隊可以得到更多的商業機會和反饋。通常在演示會上，團隊會得業務優先級高的變更請求。這都是有價值的。

(四) 在項目過程中，業務人員與開發人員要每天在一起工作

頻繁的演示是業務代表和開發人員在項目共同工作的一個很好的切入點。在實際工作中，開發人員每日和業務代表采用面對面的溝通往往比較困難，但是值得去推動。面對面的交流可以更好的觀察肢體語言，相比而言，文檔、電子郵件或者打電話都不能有效地傳遞信息。

每天和業務代表共同工作，開發團隊對業務的學習程度和速度都遠超在需求收集會議中對業務的理解。因此，開發團隊可以提出多種有價值的解決方案來代替直接的業務申請。業務代表也可以學習到那些類型的解決方案或成本高或者開發速度慢，那些功能成本低，進而通過反饋來調整需求。

如果業務代表和開發團隊不能每日在一起工作，那么也應該盡量將兩個工作小組安排在一起，沒兩天或者頻繁的互動參與工作。有些團隊使用"代理客戶"(PO或者BA有時候就會成為代理客戶)，將"代理客戶"作為商業代表的替身。

(五) 要善于激勵項目人員，給他們所需要的環境和支持，并相信他們能夠完成任務

正如軟件估算模型性成本模型(COCOMO)所顯示的，好的團隊成員和好的流程工具，這兩個因素影響之間的比例關系是10:1。這意味著員工對一個項目能否成功會起到更重要的作用，而不是工具和流程。

顯示中，我們雖然不能確保每個團隊都是被精挑細選出來的理想組合，就像中國跳水團隊——夢之隊，但是我們可以嘗試去激發團隊成員，讓他們成為一個可以自我驅動的理想團隊。自組織團隊作為項目的一個重要因素，一旦員工開始自組織和計劃工作，其工作會更加高效。敏捷方法主張將團隊從微觀管理和甘特圖中的任務式管理中脫離出來，聚焦工作技巧和團隊協作從而提高生產率。

知識性項目也包含有特殊經驗和技能的成員。如果開發團隊可以更好地做出日常決定以及處理好計劃的工作，那么項目團隊中每個成員都會是專家，可以為項目的成功予以支持。

(六) 團隊內部和各個團隊之間，最有效的溝通方法是面對面的溝通。

寫文檔可以很好地做記錄，但是速度緩慢會造成高成本。面對面的溝通可以快速傳達大量的信息，包括表情和肢體語言。梅拉賓法則曾經提出：“在信息溝通中，除了語言的表達方式外，信息還可以許多方式表達。說話的內容盡占用7%，語音語調占38%，肢體語言占55%”。

在面對面的會談中，問題可以立刻得到解決，而不是被暫時擱置或者過一段時間再被反饋。但是面對面會談不能用于所有的溝通場所，是提倡盡量遵循。隨著團隊規模的擴大，面對面的溝通很難實現，此時我們就需要引入適當的文檔要求。

(七) 可工作的軟件是衡量進度的首要指標

首先，要將可工作的軟件作為項目的關注目標，努力將創建文檔等活動作為支持目標的手段而不是首要任務。如果產品不能工作，就不能被認為已完成了。強調"可工作"的軟件是為了提醒團隊功能特性只有被接受才算完成。項目是以結果為導向的，中間過程的可交付成果(比如文檔和部分完成的工作)都不會得到外部的認可，被客戶使用的產品才是項目的關注點

(八) 敏捷過程提倡可持續的發展。項目方、開發人員和用戶應該能夠保持恒久、穩定的進展速度。

一些快速應用開發技術并非已達到可持續開發的水平，很可能會由于工作時間過長而導致工作人員過度疲勞，從而造成不必要的錯誤。針對周期長且緊張的開發階段，敏捷方法認為應保持穩定的進展速度，其價值在于允許團隊成員維持工作和生活的平衡?？沙掷m的速度不僅對團隊有好處，也會對整個組織帶來益處。過程的工作時間會導致員工辭職，組織也會失去很多資源。重新雇傭和整合新的成員會是一個緩慢且高成本的過程。

因此，保持恒定的開發速度可以創造一個更加和諧、高效的團隊，較小的壓力會提高工作效率、促進團隊之間的協作。

(九) 對技術卓越和好的設計的持續關注有助于增強敏捷性。

當我們想開發團隊可以努力工作并且交付大量有價值的產品時，我們也必須注意保持設計的清晰、高效和變更的靈活性。精益求精的技術和良好的設計會使產品或開發團隊更好地理解與更新設計。

在軟件世界中，一旦編程的基礎紊亂，組織將喪失對變更響應的能力，失去其敏捷性。因此，我們需要給開發團隊足夠的時間進行重構，重構使編程更加穩定從而維持更長的時間。

(十) 盡量做到簡潔、盡最大可能減少不必要的工作。這是一門藝術。

在軟件行業，多達60%的功能很少被使用或者從來沒有被使用過。因為很多功能并沒有被使用，而且復雜的系統會隱匿很多不確定性，所以敏捷方法專注于簡潔，只完成必要的元素。
復雜的項目耗時長，暴露的風險相對比較多，從而帶來更多潛在的失敗風險。因此，敏捷方法尋求"允許工作的最簡介產品"，并將其推薦為首先的解決方案。這種方法在減輕風險的同時也幫助團隊建立信息。

(十一) 最佳的架構、需求和設計出自自組織團隊。

人們喜歡自我組織，因為他們通過自己的方法最佳地完成工作、協調關系以及適應環境，同時他們也非常理解和支持這種方式。

為什么最佳架構、需求和設計來自項目團隊，而不是來自項目團隊外部的組織中的最佳架構師、商業分析師和設計師？因為外部的建議可能存在很多優點，但是如果技術團隊對其難以實施也是一個問題。

自組織團隊由更高的所有權以及對架構、需求和設計的榮譽感，團隊所創建的觀點如果已經通過審查，就不要再去驗證。相反，如果一些觀點來自團隊外部，那么需要團隊來驗證是否可以成功使用，這又將是一個富有挑戰的任務。

此外，自組織團隊更加貼近項目的技術細節，因此最適合去識別實施中的問題。雖然可以嘗試采納外部的建議，但是敏捷依然采用團隊的能力去打造最好的架構、需求和設計。團隊成員是最了解項目的人，所以最應該去授權參與項目。

(十二) 團隊要定期回顧和反省如何能夠做到更有效，并相應地調整團隊的行為

團隊在項目進展中要不斷地學習，對已經完成的任務進行反思和調整，從而為余下的項目工作做好準備。

敏捷項目通常會在每個迭代的最后用回顧會的方式反映在項目工作中的一些機會以及待改進的工作項上。一個項目會有多次的回顧，而不是每個項目僅有一次復盤，這樣可以注意到很多可能被遺忘的細節，團隊也會相應地區調整和適應行為。