我們的最高目標是，通過盡早持續(xù)交付有價值的軟件來滿足客戶的需求。
一般產品只有20%左右的功能是用戶常用的，即對用戶有價值的，為實現(xiàn)其他80%功能的投入被視為浪費；同時對客戶無用的功能不僅不會產生價值，反而會讓客戶反感、甚至放棄使用整個產品；所以交付有價值的功能或產品是最基本的要求；
盡早地交付產品，小則可以通過客戶的反饋盡早發(fā)現(xiàn)產品的調整點，減少后期的不合理成本投入；大則可以及早調整產品策略或先于竟爭對手搶占市場，進而讓產品獲得更大成功；
持續(xù)地讓“盡早”交付“有價值的”產品的能力具備持續(xù)性，而不是建立在一種臨時突擊的策略上，好比打了興奮劑能跑得更快，但是好名次不能總靠打興奮劑得來；
另外持續(xù)交付產品一方面可以滿足用戶持續(xù)增長或改變的需求，另一方面任何一個產品都不可能一次做完美、只有通過持續(xù)優(yōu)化才能越來越好，越來越符合用戶的使用。
歡迎對需求提出變更，即使在項目開發(fā)后期也不例外。敏捷過程要善于利用需求變更，幫助客戶獲得競爭優(yōu)勢。
要經常交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
這條里的“不斷”、“可用”“越短越好”與第一條的“持續(xù)”、“有價值”、“盡早”上的表達的應該是一個意思；只是說的更具體明了一點、同時特別強調了周期越短越好，較短的迭代周期為團隊提供架構并強化團隊持續(xù)關注客戶的價值；
對于“越短越好”，需要有個“度”，這個“度'是要用戶能接受的；不同業(yè)務特點、用戶特點、反饋方式讓這個“度”會不同，需要我們靈活的去判斷。
Scrum的迭代周期大概為一個月，XP的迭代周期會短至一周。
頻繁的交付，項目團隊可以得到更多的商業(yè)機會和反饋。通常在交付演示時，項目團隊會得到新的業(yè)務優(yōu)先級的變更要求，這都是很有價值的。
項目實施過程中，業(yè)務人員與開發(fā)人員必須始終通力協(xié)作。
業(yè)務人員和開發(fā)人員是一個團隊的不同角色，要像一個團隊那樣工作；他們最好物理空間上在一起，可以迅速達成有效的溝通合作。
開發(fā)人員通過每天和業(yè)務代表的共同工作，開發(fā)團隊對業(yè)務的學習速度遠遠超過通過需求收集會議中對業(yè)務的理解。
當業(yè)務代表和開發(fā)團隊不能每日在一起交流敏捷方法經常嘗試的方法是將兩個工作小組一起工作，或者使用“代理客戶”(他們對相關業(yè)務的商業(yè)分析非常的有經驗，將“代理客戶”作為商業(yè)代表的替身。
要善于激勵項目人員，給予他們所需的環(huán)境和支持，并相信他們能夠完成任務。
我們不能總是挑選出我們夢想的團隊，我們可以做的是嘗試去激勵團隊成員。團隊作為項目的一個重要的因素，敏捷方法促進鼓勵團隊成員。當員工開始自組織和計劃工作,他們會工作的更好。敏捷方法主張將團隊從微觀管理和甘特圖中的任務重釋放出來。取而代之的重點是工作技巧、平等合作和團隊合作，將會提高生產率。
知識性項目也包含有特殊經驗和技能的成員。如果允許開發(fā)團隊可以更好的做出日常決定和處理本項目的計劃。這不意味著我們放棄和拋棄了項目團隊反而是認為項目團隊中每個成員都是專家，可以為項目的成功做出支持。
無論是對開發(fā)團隊還是團隊內部，信息傳達最有效的方法都是面對面的交談。
寫文檔是記錄事件和決定的好方法，但緩慢的速度也會造成高額的生產成本。相對比的是，面對面的溝通可以快速傳達大量的信息，也包括表情和肢體語言。
在面對面的會談中，問題可以立刻得到解決的答案，而不是暫時擱置問題等待解釋或者答案會過一段時間再反饋。
當然，在此推薦的面對面會談不能運用于所有的溝通場合，但是應該盡量遵循。隨著團隊規(guī)模的不斷增長，面對面的溝通將會越來越難去組織，就需要引入適當?shù)奈臋n要求。
可用的軟件是衡量進度的首要衡量標準。
將“可用的軟件”作為衡量進度的首要指標，我們首先要將可用的軟件作為項目的關注目標，努力將創(chuàng)建文檔和設計作為支持目標的手段而不是首要任務活動。當一個功能特性不能被衡量或測試一換句話說，如果產品不能工作一這將不能被認為是產品完成。這里強調'可用”的軟件幫助提醒團隊要接受功能特性，而不是當還未接受的時候勍打上“完成開發(fā)”的條目。
定義“可用的軟件”的演變過程創(chuàng)立了項目結果為導向的觀點。
敏捷過程提倡可持續(xù)的開發(fā)。項目發(fā)起人、開發(fā)人員和用戶應該都能夠始終保持步調穩(wěn)定。
對于時間長而且緊張的開發(fā)階段，敏捷方法認為保持穩(wěn)定的進展速度的價值在于允許團隊成員有工作和生活的平衡。不僅對團隊有好處，對于整個組織也會帶來益處。過長的工作時間會導致員工的辭職，組織也會失去很多才能和知識。重新雇傭和整合新的成員都會是一個緩慢和高成本的過程。
保持一定的工作速度可以創(chuàng)造一個更加開心和高效的團隊。開心的團隊也比過勞團隊給業(yè)務代表帶來更多的正能量。這里有更少的緊張壓力，會提高工作關系。就類似極限編程(XP)推薦保持每周40小時的工作時間。
對技術的精益求精以及對設計的不斷完善將是高敏捷性。
當我們希望開發(fā)團隊可以努力工作并且提交大量有價值產品，我們同樣必須注意保持設計的清晰、高效、和對變更的開放性。精藝的技術和良好的設計會使產品或開發(fā)團隊更早的理解和更新的設計。
在軟件世界中，一旦編程的基礎紊亂了，組織將喪失對變更響應的能力換句話說。丟失了敏捷性。所以我們需要給開發(fā)團隊足夠的時間來組織重構。重構就是類似于家政清潔、打掃清理、和簡單化，使編碼更加穩(wěn)定和維持更長的時間。
對于一個項目需要平衡精力在持續(xù)關注于解決方案設計的高價值特性交付物上。這種平衡將使系統(tǒng)交付長期的價值，而不是難以維持、難以變化和擴展的。
簡潔，即盡最大可能減少不必要的工作，這是一門藝術。
最為可靠的特性我們尚未完成-但是好像也沒有什么做錯的。然而，在軟件世界里，完成的多達60%的功能是很少使用或者從不使用的。
很多的功能并沒有實際的使用，而且復雜的系統(tǒng)更有潛在不可靠情況，敏捷方法注重于簡潔。這意味著只完成必要的元素。不為未來的需求寫代碼，不為寫文檔而寫文檔當是專注于如何用最簡單的方法解決現(xiàn)在的問題，盡可能的減少浪費的產生。
完成復雜的項目會用時更長，會暴露出更長的風險視界( horizon of risk)，會帶來更多在失敗點和更多成本泛濫的風險。因此，敏捷方法尋求可以允許工作的最簡潔品并推薦為首先完成的解決方案。
最佳的架構、需求和設計將出自于自組織團隊。
團隊要定期反省怎樣做才能更有效，并相應地調整團隊的行為。
在項目最后收尾過程來進行學習，太少也太遲了。我們應該在項目進展的時候進行收集和學習。這意味著在項目的進行中要對已經完成的任務進行學習和調整，為剩下的項目工作做好準備，這點非常重要。
多次回顧的好處在于可以注意很多可能被遺忘的細節(jié)。相比較項目單次的復習而言，在很長時間后，團隊成員很難記得項目在哪里做的好，哪里出現(xiàn)了問題。團隊通過定期的反省，找出可以改進的方向并據(jù)此調整團隊的行為，以團隊認可的方式不斷修正達到目標的路徑，保持團隊的敏捷性。
定期的回顧會議與反省是讓團隊成長和進步的最好的機會。
