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