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