敏捷軟件開發——第1章 敏捷實踐

第1章　敏捷實踐

敏捷軟件開發宣言：
人和交互    重於     過程和工具
能夠工做的軟件  重於     面面俱到的文檔
客戶合做   重於     合同談判
隨時應對變化  重於     遵循計劃
雖然右項也有其價值，但左項更加劇要。

 

1.人和交互重於過程和工具
　　人是得到成功的最爲重要的因素。若是團隊中沒有優秀的成員，那麼就算是使用好的過程也不能從失敗中挽救項目，可是，不 好的過程卻可使最優秀的團隊成員失去效用。若是不能做爲一個團隊進行工做，那麼即便擁有一批優秀的成員也同樣會慘敗。

　　一個優秀的團隊成員未必就是一個一 流的程序員。一個優秀的團隊成員多是一個平均水平的程序員，可是卻可以很好地和他人合做。合做（溝通以及交互）能力要比單純的編程能力更爲重要。一個由平均水平程序員組成的團隊，若是具備良好的溝通能力，將要比那些雖然擁有一批高水平程序員，可是成員之間卻不能進行交流的團隊更有可能得到成功。

　　合適的工具 對於成功來講是很是重要的。像編譯器、IDE、源代碼控制系統等，對於團隊的開發者正確地完成他們的工做是相當重要的。然而，工具的做用可能會被過度地誇 大。使用過多的龐大、笨重的工具就像缺乏工具同樣，都是很差的。

　　咱們的建議是從使用小工具開始，嘗試一個工具，直到發現它沒法適用時纔去更換它。不是急着去購買那些先進的、價格昂貴的源代碼控制系統，相反先使用一個免費的系統直到可以證實該系統已經再也不適用。在決定爲團隊購買最好的CASE工具許可證 （license）前，先使用白板和方格紙，直到有足夠的理由代表須要更多的功能。在決定使用龐大的、高性能的數據庫系統前，先使用平面文件 （flat file）。不要認爲更大的、更好的工具能夠自動地幫你作得更好。一般，它們形成的障礙要大於帶來的幫助。

　　記住，團隊的構建要比環境的構建重 要得多。許多團隊和管理者就犯了先構建環境，而後指望團隊自動凝聚在一塊兒的錯誤。相反，應該首先致力於構建團隊，而後再讓團隊基於須要來配置環境。

2.能夠工做的軟件重於面面俱到的文檔
　　沒有文檔的軟件是一種災難。代碼不是傳達系統原理和結構的理想媒介。團隊更須要編制易於閱讀的文檔，來對系統及其設計決策的依據進行描述。

　　然而，過多的文檔 比過少的文檔更糟。編制衆多的文檔須要花費大量的時間，而且要使這些文檔和代碼保持同步，就要花費更多的時間。若是文檔和代碼之間失去同步，那麼文檔就會變成龐大的、複雜的謊話，會形成重大的誤導。

　　對於團隊來講，編寫並維護一份系統原理和結構方面的文檔將老是一個好主意，可是那份文檔應該是短小的 （short）而且主題突出的（salient）。「短小的」意思是說，最多有一二十頁。「主題突出的」意思是說，應該僅論述系統的高層結構和歸納的設計 原理。

　　若是所有擁有的僅僅是一份簡短的系統原理和結構方面的文檔，那麼如何來培訓新的團隊成員，使他們可以從事與系統相關的工做呢？咱們會很是密切地和他 們在一塊兒工做。咱們緊挨着他們坐下來幫助他們，把咱們的知識傳授給他們。咱們經過近距離的培訓和交互使他們成爲團隊的一部分。

　　在給新的團隊成員傳授知識方面，最好的兩份文檔是代碼和團隊。代碼真實地表達了它所作的事情。雖然從代碼中提取系統的原理和結構信息多是困難的，可是代碼是唯一沒有二義性的信息 源。在團隊成員的頭腦中，保存着時常變化的系統的脈絡圖（road map）。人和人之間的交互是把這份脈絡圖傳授給他人的最快、最有效的方式。
　　許多團隊由於注重文檔而非軟件，致使進度拖延。這經常是一個致命的缺陷。有一個叫作「Martin文檔第必定律（Martin’s first law of documentation）」的簡單規則能夠預防該缺陷的發生：直到迫切須要而且意義重大時，纔來編制文檔。

3.客戶合做重於合同談判
　　不能像訂購日用品同樣來訂購軟件。你不可以僅僅寫下一份關於你想要的軟件的描述，而後就讓人在固定的時間內以固定的價格去開發它。全部用這種方式來對待軟件 項目的嘗試都以失敗而了結。有時，失敗是慘重的。

　　告訴開發團隊想要的東西，而後指望開發團隊消失一段時間後就可以交付一個知足須要的系統來，這對於公司的 管理者來講是具備誘惑力的。然而，這種操做模式將致使低劣的質量和失敗。

　　成功的項目須要有序、頻繁的客戶反饋。不是依賴於合同或者關於工做的陳述，而是讓軟件的客戶和開發團隊密切地在一塊兒工做，並儘可能常常地提供反饋。

　　一個指明瞭需求、進度以及項目成本的合同存在根本上的缺陷。在大多數的狀況下，合同中指明的條款遠在項目完成以前就變得沒有意義。那些爲開發團隊和客戶的協同工做方式提供指導的合同纔是最好的合同。

　　我在1994 年爲一個大型的、須要多年完 成的、有50 萬行代碼的項目達成的合同，能夠做爲一個成功合同的樣例。做爲開發團隊的咱們，每月的報酬相對是比較低的。大部分的報酬要在咱們交付了某 些大的功能塊後才支付。那些功能塊沒有在合同中詳細地指明。合同中僅僅聲稱在一個功能塊經過了客戶的驗收測試時才支付該功能塊的報酬。那些驗收測試的細節 也沒有在合同中指明。

　　在這個項目開發期間，咱們和客戶緊密地在一塊兒工做。幾乎每一個週五，咱們都會把軟件提交給客戶。到下一週的週一或者週二，客戶會給咱們 一份關於軟件的變動列表。咱們會把這些變動放在一塊兒排定優先級，而後把它們安排在隨後幾周的工做中。客戶和咱們如此緊密地在一塊兒工做，以致於驗收測試根本就不是問題。由於他們周復一週地觀察着每一個功能塊的演進，因此他們知道什麼時候這個功能塊可以知足他們的須要。

　　這個項目的需求基本處於一個持續變化的 狀態。大的變動是很日常的。在這期間，也會出現整個功能塊被減掉，而加進來另一些功能塊。然而，合同和項目都經受住了這些變動，並得到成功。成功的關鍵 在於和客戶之間真誠的協做，而且合同指導了這種協做，而不是試圖去規定項目範圍的細節和固定成本下的進度。

4.隨時應對變化重於遵循計劃
　　隨時應對變化的能力經常決定着一個軟件項目的成敗。當咱們構建計劃時，應該確保計劃是靈活的而且易於適應商務和技術方面的變化。

　　計劃不能考慮得過遠。首先，商務環境極可能會變化，這會引發需求的變更。其次，一旦客戶看到系統開始運做，他們極可能會改變需求。最後，即便咱們知道需求是什麼，而且確信它們不會改變，咱們仍然不能很好地估算出開發它們須要的時間。

　　對於一個缺少經驗的管理者來講，建立一張優美的PERT 或者Gantt 圖並把他們貼到牆上是頗有誘惑力的。他們也許以爲這張圖賦予了他們對項目的控制權。他們可以跟蹤單我的的任務，並在任務完成時將任務從圖上去除。他們能夠對實際完成的日期和計劃完成的日期 進行比較，並對出現的任何誤差作出反應。

　　實際上發生的是這張圖的組織結構再也不適用。當團隊增長了對於系統的認識，當客戶增長了對於需求的認識，圖中的某些任務會變得沒有必要。另一些任務會被發現並增長到圖中。簡而言之，計劃圖的形態（shape）將會改變，而不只僅是日期上的改變。

　　較好的作計劃的策略是：爲下一週作詳細的計劃，爲下3個月作粗略的計劃，再之後就作極爲粗糙的計劃。咱們應該清楚地知道下週要完成的任務，粗略地瞭解一下之後3個月要實現的需求。至於系統一年後將要作什麼，有一個模糊的想法就好了。

　　計劃中這種逐漸下降的細緻度，意味着咱們僅僅對於迫切的任務才花費時間進行詳細的計劃。一 旦制定了這個詳細的計劃，就很難進行改變，由於團隊會根據這個計劃啓動工做並有了相應的投入。然而，因爲計劃僅僅支配了幾周的時間，計劃的其他部分仍然保 持着靈活性。

 

敏捷開發遵循的原則
　　從上述的價值觀中引出了下面的12 條原則，它們是敏捷實踐區別於重型過程的特徵所在。

　　（1）咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。《MIT Sloan管理評論雜誌》刊登過一篇論文，分析了對於公司構建高質量產品方面有幫助的軟件開發實踐。該論文發現了不少對於最終系統質量有重要影響的實踐。其中一個實踐 代表，儘早地交付具備部分功能的系統和系統質量之間具備很強的相關性。該論文指出，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高。該論 文的另外一項發現是，以逐漸增長功能的方式常常性地交付系統和最終質量之間有很是強的相關性。交付得越頻繁，最終產品的質量就越高。
　　敏捷實踐會盡早地、常常地進行交付。咱們努力在項目剛開始的幾周內就交付一個具備基本功能的系統。而後，咱們努力堅持每兩週就交付一個功能漸增的系統。若是客戶認爲目前的功能已經足夠了，客戶能夠選擇把這些系統加入到產品中。或者，他們能夠簡單地選擇再檢查一遍已有的功能，並指出他們想要作的改變。

　　（2）咱們歡迎需求的變化，即便到了開發的後期。敏捷過程可以駕馭變化 ，爲客戶創造競爭優點。這是一個關於態度的聲明。敏捷過程的參與者不害怕變化。他們認爲改變需求是好的事情，由於那些改變意味着團隊已經學 到了不少如何知足市場須要的知識。
　　敏捷團隊會很是努力地保持軟件結構的靈活性，這樣當需求變化時，對於系統形成的影響是最小的。 在本書的後面部分，咱們 會學習一些面向對象設計的原則和模式，這些內容會幫助咱們維持這種靈活性。

　　（3）常常性地交付能夠工做的軟件，交付的間隔能夠從幾周到幾個月，交付的時間間隔越短越好。咱們交付能夠工做的軟件，而且儘早地（項目剛開始不多的幾周後）、常常性地（此後每隔不多的幾周）交付它。咱們不同意交付大量的文檔或者計劃。咱們認爲那些不是真正要交付的東西。咱們關注的目標是交付知足客戶須要的軟件。
　　

　　（4）在整個項目開發期間，業務人員和開發人員必須朝夕工做在一塊兒。爲了可以以敏捷的方式進行項目的開發，客戶、開發人員以及利益相關者之間就必需要進行有意義的、頻繁的交互。軟件項目不像發射出去就能自動導航的武器，必需要對軟件項目進行持續不斷地引導。

　　（5）圍繞鬥志高昂的人構建項目。給 他們提供所須要的環境和支持，而且信任他們可以完成工做。人是項目取得成功的最重要的因素。全部其餘的因素（過程、環境、管理等）都被認爲是次要的，而且當它們對於人有負面的影響時，就要對它們進行改變。例如，若是辦公環境對團隊的工做形成阻礙，就必須對辦公環境進行改變。若是某些過程步驟對團隊的工做形成阻礙，就必須對那些過程步驟進行改變。

　　（6）在團隊內部，最具備效率也最有效果的信息傳達方式，就是面對面的交談。在敏捷項目中，人們之間相互進行交談。首要的溝通方式就是交談。也許會編寫文檔，可是不會企圖在文檔中包含全部的項目信息。敏捷團隊不須要書面的規範、書面的計劃或者書面的設計。團隊成員能夠去編寫文檔，若是對於這些文檔的需求是迫切而且意義重大的，可是文檔不是默認的溝通方式。默認的溝通方式是交談。

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

　　（8）敏捷過程提倡可持續開發。出資人、開發者和用戶應該老是保持穩定的開發速度。敏捷項目不是50 米短跑；而是馬拉松長跑。團隊不是以全速啓動並試圖在項目開發期間維持那個速度；相反，他們以快速可是可持續的速度行進。
　　跑得過快會致使團隊精力耗盡、出現短時間行爲以至於崩潰。敏捷團隊會測量他們本身的速度。他們不容許本身過於疲憊。他們不會借用明天的精力來在今天多完成一點工做。他們工做在一個可使在整個項目開發期間保持最高質量標準的速度上。

　　（9）對卓越技術和良好設計的爲斷追求有助於提升敏捷性。高的產品質量是獲取高的開發速度的關鍵。保持軟件儘量的簡潔、健壯是快速開發軟件的途徑。於是，全部的敏捷團隊成員都致力於只編寫他們可以編寫的最高質量的代碼。他們不會製造混亂而後告訴本身等有更多的時間時再來清理它們。若是他們在今天製造了混亂，他們會在今天把混亂清理乾淨。

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

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

　　（12）每隔必定時間，團隊都要總結如何更有效率，而後相應地調整本身的行爲。敏捷團隊會不斷地對團隊的組織方式、規則、規範、關係等進行調整。敏捷團隊知道團隊所處的環境在不斷地變化，而且知道爲了保持團隊的敏捷性，就必需要隨環境一塊兒變化。

 

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

 http://www.cnblogs.com/jesselzj/p/4757209.html

 

摘自：《敏捷軟件開發：原則、模式與實踐(C#版)》Robert C.Martin　Micah Martin 著