敏捷軟件開發(fā)宣言：
1。個體和交互 勝過 過程和工具
團隊的構建要比環(huán)境的構建重要的多。許多團隊和管理者就犯了先構建環(huán)境，然后期望
團隊自動凝聚在一起的錯誤。相反，應該首先致力于構建團隊，然后再讓團隊基于需要來配置環(huán)境
2?？梢怨ぷ鞯能浖?勝過 面面俱到的文檔
3。 客戶合作 勝過 合同談判
那些為開發(fā)團隊和客戶的協(xié)同工作方式提供指導的，合同才是最好的合同。
4。響應變化 勝過 遵循計劃
計劃不能考慮得過遠。首先，商務環(huán)境很可能會變化，這會引起需求的變動。其次，一旦客戶
看到系統(tǒng)開始運作，他們很可能會改變需求。最后，即使我們熟悉需求，并且確信它們不會改變，
我們?nèi)匀徊荒芎芎玫毓浪愠鲩_發(fā)它們需要的時間。
較好的做計劃的策略是：為下兩周做詳細的計劃，為下三個月作粗略的計劃，再以后就作極為
粗糙的計劃。我們應該清楚地知道下兩周要完成的任務，粗略的了解一下以后三個月要實現(xiàn)的需求。
至于系統(tǒng)一年后將要做什么，有一個模糊的想法就行了。
敏捷開發(fā)原則：
敏捷開發(fā)12 條原則，它們是敏捷實踐區(qū)別于重型過程的特征所在。
1．我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。
MIT Sloan 管理評論雜志刊登過一篇論文，分析了對于公司構建高質(zhì)量產(chǎn)品方面有幫助的軟件
開發(fā)實踐①。該論文發(fā)現(xiàn)了很多對于最終系統(tǒng)質(zhì)量有重要影響的實踐。其中一個實踐表明，盡早地
交付具有部分功能的系統(tǒng)和系統(tǒng)質(zhì)量之間具有很強的相關性。該論文指出，初期交付的系統(tǒng)中所包
含的功能越少，最終交付的系統(tǒng)的質(zhì)量就越高。
該論文的另一項發(fā)現(xiàn)是，以逐漸增加功能的方式經(jīng)常性地交付系統(tǒng)和最終質(zhì)量之間有非常強的
相關性。交付得越頻繁，最終產(chǎn)品的質(zhì)量就越高。
敏捷實踐會盡早地、經(jīng)常地進行交付。我們努力在項目剛開始的幾周內(nèi)就交付一個具有基本功
能的系統(tǒng)。然后，我們努力堅持每兩周就交付一個功能漸增的系統(tǒng)。
如果客戶認為目前的功能已經(jīng)足夠了，客戶可以選擇把這些系統(tǒng)加入到產(chǎn)品中。
或者，他們可以簡單地選擇再檢查一遍已有的功能，并指出他們想要做的改變。
2．即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。
這是一個關于態(tài)度的聲明。敏捷過程的參與者不懼怕變化。他們認為改變需求是好的事情，因
為那些改變意味著團隊已經(jīng)學到了很多如何滿足市場需要的知識。
敏捷團隊會非常努力地保持軟件結構的靈活性，這樣當需求變化時，對于系統(tǒng)造成的影響是最
小的。 在本書的后面部分，我們會學習一些面向對象設計的原則和模式，這些內(nèi)容會幫助我們維持
這種靈活性。
3．經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越
好。
我們交付可以工作的軟件（working software ），并且盡早地（項目剛開始很少的幾周后）、經(jīng)常
性地（此后每隔很少的幾周）交付它。我們不贊成交付大量的文檔或者計劃。我們認為那些不是真
正要交付的東西。我們關注的目標是交付滿足客戶需要的軟件。
4．在整個項目開發(fā)期間，商務人員和開發(fā)人員必須天天都工作在一起。
為了能夠以敏捷的方式進行項目的開發(fā)，客戶、開發(fā)人員以及涉眾之間就必須要進行有意義的、
頻繁的交互。軟件項目不像發(fā)射出去就能夠自動導航的武器，必須要對軟件項目進行持續(xù)不斷地引
導。
5．圍繞被激勵起來的個體來構建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工
作。
在敏捷項目中，人被認為是項目取得成功的最重要的因素。所有其他的因素——過程、環(huán)境、
管理等等——都被認為是次要的，并且當它們對于人有負面的影響時，就要對它們進行改變。
例如，如果辦公環(huán)境對團隊的工作造成阻礙，就必須對辦公環(huán)境進行改變。如果某些過程步驟
對團隊的工作造成阻礙，就必須對那些過程步驟進行改變。
6．在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。
在敏捷項目中，人們之間相互進行交談。首要的溝通方式就是交談。也許會編寫文檔，但是不
會企圖在文檔中包含所有的項目信息。敏捷團隊不需要書面的規(guī)范、書面的計劃或者書面的設計。
團隊成員可以去編寫文檔，如果對于這些文檔的需求是迫切并且意義重大的，但是文檔不是默認的
溝通方式。默認的溝通方式是交談。
7．工作的軟件是首要的進度度量標準。
敏捷項目通過度量當前軟件滿足客戶需求的數(shù)量來度量開發(fā)進度。它們不是根據(jù)所處的開發(fā)階
段、已經(jīng)編寫的文檔的多少或者已經(jīng)創(chuàng)建的基礎設施（ infrastructure）代碼的數(shù)量來度量開發(fā)進度的。
只有當30%的必須功能可以工作時，才可以確定進度完成了30%。
8．敏捷過程提倡可持續(xù)的開發(fā)速度。責任人（sponsors）、開發(fā)者和用戶應該能夠保持一個長期的、
恒定的開發(fā)速度。
敏捷項目不是50 米短跑；而是馬拉松長跑。團隊不是以全速啟動并試圖在項目開發(fā)期間維持那
個速度；相反，他們以快速但是可持續(xù)的速度行進。
跑得過快會導致團隊精力耗盡、出現(xiàn)短期行為以致崩潰。敏捷團隊會測量他們自己的速度。他
們不允許自己過于疲憊。他們不會借用明天的精力來在今天多完成一點工作。他們工作在一個可以
使在整個項目開發(fā)期間保持最高質(zhì)量標準的速度上。
9．不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。
高的產(chǎn)品質(zhì)量是獲取高的開發(fā)速度的關鍵。保持軟件盡可能的清潔、健壯是快速開發(fā)軟件的途
徑。因而，所有的敏捷團隊成員都致力于只編寫他們能夠編寫的最高質(zhì)量的代碼。他們不會制造混
亂然后告訴自己等有更多的時間時再來清理它們。如果他們在今天制造了混亂，他們會在今天把混
亂清理干凈。
10．簡單——使未完成的工作最大化的藝術——是根本的。
敏捷團隊不會試圖去構建那些華而不實的系統(tǒng)，他們總是更愿意采用和目標一致的最簡單的方
法。他們并不看重對于明天會出現(xiàn)的問題的預測，也不會在今天就對那些問題進行防衛(wèi)。相反，他
們在今天以最高的質(zhì)量完成最簡單的工作，深信如果在明天發(fā)生了問題，也會很容易進行處理。
11．最好的構架、需求和設計出自于自組織的團隊。
敏捷團隊是自組織的團隊。任務不是從外部分配給單個團隊成員，而是分配給整個團隊，然后
再由團隊來確定完成任務的最好方法。
敏捷團隊的成員共同來解決項目中所有方面的問題。每一個成員都具有項目中所有方面的參與
權力。不存在單一的團隊成員對系統(tǒng)構架、需求或者測試負責的情況。整個團隊共同承擔那些職責，
每一個團隊成員都能夠影響它們。
12．每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行
調(diào)整。
敏捷團隊會不斷地對團隊的組織方式、規(guī)則、規(guī)范、關系等進行調(diào)整。敏捷團隊知道團隊所處
的環(huán)境在不斷的變化，并且知道為了保持團隊的敏捷性，就必須要隨環(huán)境一起變化。