敏捷式軟體開發 (Agile Software Development)讀書筆記（一）

標籤：

 第一部分 敏捷開發

　　2001年初，由於看到許多公司的軟體團隊陷入了不斷增長的過程的泥潭，一批業界專家聚集在一起概括出了一些可以軟體Team Dev具有快速工作、響應變化能力的價值觀（value）原則。他們稱自己為敏捷（Agile）聯盟。在隨後的幾個月中，他們建立出了一份價值觀聲明。也就是敏捷聯盟宣言（The Manifesto of the Agile Alliance）。

敏捷聯盟宣言如下：

 1.個體和互動勝過過程和工具。

人是獲得成功的最為重要的因素。如果團隊中沒有優秀的成員，那麼就是使用好的過程也不能從失敗中挽救項目，但是，不好的過程卻可以使最優秀的團隊成員失去效用。如果不能作為一個團隊進行工作，那麼即使擁有一批優秀的成員也一樣會慘敗。

一個由平均水平程式員組成的團隊，如果就具有良好的溝通能力，將要比那些雖然擁有一批高水平的程式員，但是成員之間卻不能交流的團隊更有可能獲得成功。

合適的工具對於成功來說是非常重要的。然而，工具的作用可能會被過分的誇大。使用過多的龐大、笨重的工具就像缺少工具一樣，都是不好的。

團隊的構建要比環境的構建重要得多。應該首先致力於構建團隊，然後在讓團隊基於需要來配置環境。

2.可以工作的軟體勝過面面俱到的文檔。

沒有文檔的軟體是一種災難。代碼不是傳達系統原理和結構的理想媒介。然而，過多的文檔比過少的文檔更糟。編製眾多的文檔需要花費大量的時間，並且要使這些文檔和代碼保持同步，就要花費更多的時間。如果文檔和代碼之間失去同步，那麼文檔就會變成龐大的、複雜的謊言，會造成重大的誤導。

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

在給新的團隊成員傳授知識方面，最好的兩份文檔是代碼和團隊。代碼真實的表達了它所做的事情，是唯一沒有二義性的資訊源。在團隊成員的頭腦中，儲存著時常變化的系統的脈絡圖（road map）。人和人之間的互動是把這份脈絡圖傳授給他人的最快、最有效方式。

Martin’s first law of document：直到迫切需要並且意義重大時，才來編製文檔。

3.客戶合作勝過合約談判。

不能像訂購日用品一樣來訂購軟體。你不能夠僅僅寫下一份關於你想要的軟體的描述，然後就讓人在固定的時間內以固定的價格來開發它。告訴Team Dev想要的東西，然後期望Team Dev消失一段時間後就能交付一個滿足需要的系統來，這對於公司的管理者來說是非常具有誘惑力的。然而，這種操作模式將導致低劣的品質和失敗。

成功的項目需要有序、頻繁的反饋。不是依賴於合約或者關於工作的陳述，而是讓軟體的客戶和Team Dev密切地在一起工作，並盡量經常地提供反饋。

項目成功的關鍵在於和客戶之間真誠的協作，並且合約指導了這種協作，而不是試圖去規定專案範圍的細節和固定成本下的進度。

4.響應變化勝過遵循計劃。

相應變化的能力常常決定著一個軟體項目的成敗。當我們構建計劃時，應該確保計劃是靈活的並且易於適應商務和技術方面的變化。

較好的做計劃的策略是：為下兩周做詳細的計劃，為下三個月做粗略的計劃，再以後就做極為粗糙的計劃。我們應該清楚的知道下兩周要完成的任務，粗略地瞭解一下以後三個月要實現的需求。至於系統一年後要做什麼，有一個模糊的想法就行了。

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

綜觀上述四個過程，敏捷開發強調以人為中心，而不是以過程為中心，強調儘可能的溝通（與客戶，與團隊成員），儘可能地以最簡單的設計解決問題（從而能夠擁抱變化）。

到目前為止，已經有許多的敏捷過程可供選擇了。包括SCRUM，Crystal，特徵驅動軟體開發（Feature Driven Development，簡稱FDD），自適應軟體開發（Adaptive Software Development，簡稱ADP），以及最重要的極限編程（eXtreme Programming，簡稱XP）。

敏捷式軟體開發 (Agile Software Development)讀書筆記（一）