敏捷式軟體開發 (Agile Software Development)–敏捷宣言

敏捷式軟體開發 (Agile Software Development)宣言
我們正在通過親身實踐以及協助他人實踐，提示更好的軟體開發方法。
通過這項工作，我們認為：
人和互動   重於    過程和工具
   可以工作的軟體   重於   面面俱到的文檔     
   客戶合作   重於   合約談判     
 隨時應對變化   重於   遵循計劃         
雖然右項也有價值，但我們認為左項更加重要。

敏捷宣言遵循的原則

　　我們遵循以下原則：

• 我們最優先要做的是通過儘早地、持續地交付有價值的軟體來滿足客戶需要。
• 我們歡迎需求的變化，即使到了開發後期。敏捷過程能夠駕馭變化，為客戶創造竟爭優勢。
• 經常交付可以工作的軟體，從幾個星期到幾個月，時間間隔越短越好。
• 在整個項目開發期間，業務人員和開發人員必須朝夕工作在一起。
• 圍繞鬥志高昂的人構建項目。給他們提供所需的環境和支援，並且信任他們能夠完成任務。
• 在團隊內部，最有效率也最有效果的資訊傳達方式，就是面對面的交談。
• 可以工作的軟體是進度主要的度量標準。
• 敏捷過程提倡可以持續開發。出資人、開發人員和使用者應該總是保持穩定的開發速度。
• 對卓越技術和良好技術的不斷追求有助於提高敏捷性。
• 簡單--盡量減少工作量的藝術是至關重要的。
• 最好的構架、需求和設計都源自自我組織的團隊。
• 每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。

敏捷式軟體開發 (Agile Software Development)宣言

1．個體和互動勝過過程和工具
　　人是獲得成功的最為重要的因素。如果團隊中沒有優秀的成員，那麼就是使用好的過程也不能從失敗中挽救項目，但是，不 好的過程卻可以使最優秀的團隊成員失去效用。如果不能作為一個團隊進行工作，那麼即使擁有一批優秀的成員也一樣會慘敗。一個優秀的團隊成員未必就是一個一 流的程式員。一個優秀的團隊成員可能是一個平均水平的程式員，但是卻能夠很好地和他人合作。合作、溝通以及互動能力要比單純的編程能力更為重要。一個由平 均水平程式員組成的團隊，如果具有良好的溝通能力，將要比那些雖然擁有一批高水平程式員，但是成員之間卻不能進行交流的團隊更有可能獲得成功。合適的工具 對於成功來說是非常重要的。像編譯器、IDE、原始碼控制系統等，對於團隊的開發人員正確地完成他們的工作是至關重要的。然而，工具的作用可能會被過分地誇 大。使用過多的龐大、笨重的工具就像缺少工具一樣，都是不好的。我們的建議是從使用小工具開始，嘗試一個工具，直到發現它無法適用時才去更換它。不是急著 去購買那些先進的、價格昂貴的原始碼控制系統，相反先使用一個免費的系統直到能夠證明該系統已經不再適用。在決定為團隊購買最好的CASE工具許可證 （license）前，先使用白板和方格紙，直到有足夠的理由表明需要更多的功能。在決定使用龐大的、高效能的資料庫系統前，先使用一般檔案 （flat file）。不要認為更大的、更好的工具可以自動地幫你做得更好。通常，它們造成的障礙要大於帶來的協助.記住，團隊的構建要比環境的構建重 要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。

2．可以工作的軟體勝過面面俱到的文檔
　　沒有文檔的軟體是一種災難。代碼不是傳達系統原理和結構的理想媒介。團隊更需要編製易於閱讀的文檔，來對系統及其設計決策的依據進行描述。然而，過多的文檔 比過少的文檔更糟。編製眾多的文檔需要花費大量的時間，並且要使這些文檔和代碼保持同步，就要花費更多的時間。如果文檔和代碼之間失去同步，那麼文檔就會 變成龐大的、複雜的謊言，會造成重大的誤導。對於團隊來說，編寫並維護一份系統原理和結構方面的文檔將總是一個好主意，但是那份文檔應該是短小的 （short）並且主題突出的（salient）。“短小的”意思是說，最多有一二十頁。“主題突出的”意思是說，應該僅論述系統的高層結構和概括的設計 原理。如果全部擁有的僅僅是一份簡短的系統原理和結構方面的文檔，那麼如何來培訓新的團隊成員，使他們能夠從事與系統相關的工作呢？我們會非常密切地和他 們在一起工作。我們緊挨著他們坐下來協助他們，把我們的知識傳授給他們。我們通過近距離的培訓和互動使他們成為團隊的一部分。在給新的團隊成員傳授知識方 面，最好的兩份文檔是代碼和團隊。代碼真實地表達了它所做的事情。雖然從代碼中提取系統的原理和結構資訊可能是困難的，但是代碼是惟一沒有二義性的資訊 源。在團隊成員的頭腦中，儲存著時常變化的系統的脈絡圖（road map）。人和人之間的互動是把這份脈絡圖傳授給他人的最快、最有效方式。
許多團隊因為注重文檔而非軟體，導致進度拖延。這常常是一個致命的缺陷。有一個叫做“Martin文檔第一定律（Martin’s first law of document）”的簡單規則可以預防該缺陷的發生：直到迫切需要並且意義重大時，才來編製文檔。

3．客戶合作勝過合約談判
　　不能像訂購日用品一樣來訂購軟體。你不能夠僅僅寫下一份關於你想要的軟體的描述，然後就讓人在固定的時間內以固定的價格去開發它。所有用這種方式來對待軟體 項目的嘗試都以失敗而告終。有時，失敗是慘重的。告訴Team Dev想要的東西，然後期望Team Dev消失一段時間後就能夠交付一個滿足需要的系統來，這對於公司的 管理者來說是具有誘惑力的。然而，這種操作模式將導致低劣的品質和失敗。成功的項目需要有序、頻繁的客戶回函。不是依賴於合約或者關於工作的陳述，而是讓 軟體的客戶和Team Dev密切地在一起工作，並盡量經常地提供反饋。一個指明了需求、進度以及項目成本的合約存在根本上的缺陷。在大多數的情況下，合約中指明 的條款遠在項目完成之前就變得沒有意義。①那些為Team Dev和客戶的協同工作方式提供指導的合約才是最好的合約。我在1994 年為一個大型的、需要多年完 成的、有50 萬行代碼的項目達成的合約，可以作為一個成功合約的範例。作為Team Dev的我們，每個月的報酬相對是比較低的。大部分的報酬要在我們交付了某 些大的功能塊後才支付。那些功能塊沒有在合約中詳細地指明。合約中僅僅聲稱在一個功能塊通過了客戶的驗收測試時才支付該功能塊的報酬。那些驗收測試的細節 也沒有在合約中指明。在這個項目開發期間，我們和客戶緊密地在一起工作。幾乎每個周五，我們都會把軟體提交給客戶。到下一周的周一或者周二，客戶會給我們 一份關於軟體的變更列表。我們會把這些變更放在一起排定優先順序，然後把它們安排在隨後幾周的工作中。客戶和我們如此緊密地在一起工作，以至
於驗收 測試根本就不是問題。因為他們周複一周地觀察著每個功能塊的演化，所以他們知道何時這個功能塊能夠滿足他們的需要。這個項目的需求基本處於一個持續變化的 狀態。大的變更是很平常的。在這期間，也會出現整個功能塊被減掉，而加進來另外一些功能塊。然而，合約和項目都經受住了這些變更，並獲得成功。成功的關鍵 在於和客戶之間真誠的協作，並且合約指導了這種協作，而不是試圖去規定專案範圍的細節和固定成本下的進度。

4．響應變化勝過遵循計劃
　　響應變化的能力常常決定著一個軟體項目的成敗。當我們構建計劃時，應該確保計劃是靈活的並且易於適應商務和技術方面的變化。計劃不能考慮得過遠。首先，商務 環境很可能會變化，這會引起需求的變動。其次，一旦客戶看到系統開始運作，他們很可能會改變需求。最後，即使我們熟悉需求，並且確信它們不會改變，我們仍 然不能很好地估算出開發它們需要的時間。對於一個缺乏經驗的管理者來說，建立一張優美的PERT 或者Gantt 圖並把他們貼到牆上是很有誘惑力的。他 們也許覺得這張圖賦予了他們控制整個項目的權力。他們能夠跟蹤單個人的任務，並在任務完成時將任務從圖上去除。他們可以對實際完成的日期和計劃完成的日期 進行比較，並對出現的任何偏差做出反應。實際上發生的是這張圖的組織圖不再適用。當團隊增加了對於系統的認識，當客戶增加了對於需求的認識，圖中的某些 任務會變得可有可無。另外一些任務會被發現並增加到圖中。簡而言之，計劃將會遭受形態（shape）上的改變，而不僅僅是日期上的改變。較好的做計劃的策 略是：為下兩周做詳細的計劃，為下三個月做粗略的計劃，再以後就做極為粗糙的計劃。我們應該清楚地知道下兩周要完成的任務，粗略地瞭解一下以後三個月要實 現的需求。至於系統一年後將要做什麼，有一個模糊的想法就行了。計劃中這種逐漸降低的細緻度，意味著我們僅僅對於迫切的任務才花費時間進行詳細的計劃。一 旦制定了這個詳細的計劃，就很難進行改變，因為團隊會根據這個計劃啟動工作並有了相應的投入。然而，由於計劃僅僅支配了幾周的時間，計劃的其餘部分仍然保 持著靈活性。

敏捷宣言遵循的原則

　　從上述的價值觀中引出了下面的12 條原則，它們是敏捷實踐區別於重型過程的特徵所在。
　　1．我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。MIT Sloan 管 理評論雜誌刊登過一篇論文，分析了對於公司構建高品質產品方面有協助的軟體開發實踐。該論文發現了很多對於最終系統品質有重要影響的實踐。其中一個實踐 表明，儘早地交付具有部分功能的系統和系統品質之間具有很強的相關性。該論文指出，初期交付的系統中所包含的功能越少，最終交付的系統的品質就越高。該論 文的另一項發現是，以逐漸增加功能的方式經常性地交付系統和最終品質之間有非常強的相關性。交付得越頻繁，最終產品的品質就越高。
　　敏捷實踐會儘早地、經常 地進行交付。我們努力在項目剛開始的幾周內就交付一個具有準系統的系統。然後，我們努力堅持每兩周就交付一個功能漸增的系統。如果客戶認為目前的功能已 經足夠了，客戶可以選擇把這些系統加入到產品中。或者，他們可以簡單地選擇再檢查一遍已有的功能，並指出他們想要做的改變。

　　2．我們歡迎需求的變化，即使到了開發的後期。敏捷過程能夠駕馭變化 ，為客戶創造競爭優勢。這是一個關於態度的聲明。敏捷過程的參與者不懼怕變化。他們認為改變需求是好的事情，因為那些改變意味著團隊已經學 到了很多如何滿足市場需要的知識。
　　敏捷團隊會非常努力地保持軟體結構的靈活性，這樣當需求變化時，對於系統造成的影響是最小的。 在本書的後面部分，我們 會學習一些物件導向設計的原則和模式，這些內容會協助我們維持這種靈活性。

　　3．經常性地交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。我們交付可以工作的軟體working software ），並且儘早地（項目剛開始很少的幾周后）、經常性地（此後每隔很少的幾周）交付它。我們不贊成交付大量的文檔或者計劃。我們認為那些不是真正要交付的東西。我們關注的目標是交付滿足客戶需要的軟體。
　　4．在整個項目開發期間，業務人員和開發人員必須朝夕工作在一起。為了能夠以敏捷的方式進行項目的開發，客戶、開發人員以及涉眾之間就必須要進行有意義的、頻繁的互動。軟體項目不像發射出去就能自動導航的武器，必須要對軟體項目進行持續不斷地引導。

　　5．圍繞鬥志高昂的人構建項目。給 他們提供所需要的環境和支援，並且信任他們能夠完成工作。在敏捷項目中，人被認為是項目取得成功的最重要的因素。所有其他的因素??過程、環境、管理等 等??都被認為是次要的，並且當它們對於人有負面的影響時，就要對它們進行改變。例如，如果辦公環境對團隊的工作造成阻礙，就必須對辦公環境進行改變。如 果某些過程步驟對團隊的工作造成阻礙，就必須對那些過程步驟進行改變。

　　6．在團隊內部，最具有效率也最有效果的資訊傳達方式，就是面對面的交談。在敏捷項目中，人們之間相互進行交談。首要的溝通方式就是交談。也許會編寫文檔，但是不會企圖在文檔中包含所有的項目資訊。敏捷團隊不需要書面的規範、書面的計劃或者書面的設計。團隊成員可以去編寫文檔，如果對於這些文檔的需求是迫切並且意義重大的，但是文檔不是預設的溝通方式。預設的溝通方式是交談。

　　7．可以工作的軟體是首要的進度度量標準。敏捷項目通過度量當前軟體滿足客戶需求的數量來度量開發進度。它們不是根據所處的開發階段、已經編寫的文檔的多少或者已經建立的基礎結構（infrastructure）代碼的數量來度量開發進度的。只有當30%的必須功能可以工作時，才可以確定進度完成了30%。

　　8．敏捷過程提倡可持續的開發速度。出資人、開發人員和使用者應該能夠保持一個長期的、恒定的開發速度。敏捷項目不是50 米短跑；而是馬拉松長跑。團隊不是以全速啟動並試圖在項目開發期間維持那 個速度；相反，他們以快速但是可持續的速度行進。
　　跑得過快會導致團隊精力耗盡、出現短期行為以致於崩潰。敏捷團隊會測量他們自己的速度。他們不允許自己過 於疲憊。他們不會借用明天的精力來在今天多完成一點工作。他們工作在一個可以使在整個項目開發期間保持最高品質標準的速度上。

　　9．對卓越技術和良好設計的為斷追求有助於提高敏捷性。高的產品品質是擷取高的開發速度的關鍵。保持軟體儘可能的簡潔、健壯是快速開發軟體的途徑。因而，所有的敏捷團隊成員都致力於只編寫他們能夠編寫的最高品質 的代碼。他們不會製造混亂然後告訴自己等有更多的時間時再來清理它們。如果他們在今天製造了混亂，他們會在今天把混亂清理乾淨。

　　10．簡單--盡量減少工作的的藝術是至關重要的。敏捷團隊不會試圖去構建那些華而不實的系統，他們總是更願意採用和目標一致的最簡單的方法。他們並不看重對於明天會出現的問題的預測，也不會在今天就對那些問題進行防衛。相反，他們在今天以最高的品質完成最簡單的工作，深信如果在明天發生了問題，也會很容易進行處理。

　　11．最好的構架、需求和設計都源自自我組織的團隊。敏 捷團隊是自組織的團隊。任務不是從外部分配給單個團隊成員，而是分配給整個團隊，然後再由團隊來確定完成任務的最好方法。
　　敏捷團隊的成員共同來解決項目中 所有方面的問題。每一個成員都具有項目中所有方面的參與權力。不存在單一的團隊成員對系統構架、需求或者測試負責的情況。整個團隊共同承擔那些責任，每一 個團隊成員都能夠影響它們。

　　12．每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。敏捷團隊會不斷地對團隊的組織方式、規則、規範、關係等進行調整。敏捷團隊知道團隊所處的環境在不斷地變化，並且知道為了保持團隊的敏捷性，就必須要隨環境一起變化。

結 論
　　每 一位軟體開發人員、每一個Team Dev的職業目標，都是給他們的僱主和客戶交付最大可能的價值。可是，我們的項目以令人沮喪的速度失敗，或者未能交付任何價 值。雖然在項目中採用過程方法是出於好意的，但是膨脹的過程方法對於我們的失敗至少是應該負一些責任的。敏捷式軟體開發 (Agile Software Development)的原則和價值觀構成了一個可以協助團 隊打破過程膨脹迴圈的方法，這個方法關注的是可以達到團隊目標的一些簡單的技術。

----摘自：《敏捷式軟體開發 (Agile Software Development)  原則、模式與實踐（C#版）》