敏捷-新方法論

原文：http://www.cnblogs.com/me-sa/archive/2008/01/14/1037910.html

無章法，繁重，敏捷

多數的軟體開發都是一個混亂無序的活動，常常就簡單的劃分成“CODE&FIX”兩個階段，這就是它的特點。軟體的編寫沒有一個指導性的計劃，系統的設計是由一系列短期的決定構成的。當系統規模小的時候這個方法還真的表現不錯，但是隨著系統規模變大新功能的開發日益艱難。雪上加霜的是這時BUG也無處不在而且難以修改；這種系統的典型特徵就是在做到"feature complete" 之後將有一個漫長的測試階段，這個階段將把時間計劃完全打亂，因為測試和除錯的時間難以預計；

解決上述問題，這就是引入軟體過程方法論的初衷。方法論將一些嚴格的過程應用到軟體開發活動，目的就是提高軟體開發的可預見性和效率；他們是怎麼做的呢？他們把其他工程學的原理引入進來強調計劃的重要性，通過一個詳細的計劃來解決問題。因此這時的方法又稱計劃驅動的方法。

工程方法學存在了很長時間，但是並沒有取得顯著的成功。它們甚至沒有流傳開，最為人詬病的是它太官僚主義了。採用該方法要照顧太多的瑣碎的事情，這讓整個開發節奏慢了下來。

揹負著力挽狂瀾的期望，“敏捷方法”應時而生。對於大多數人來講，敏捷方法最大的吸引力就是它能解決工程方法論的官僚主義問題。這個方法論試圖給出一個介於“無過程”和“過度過程”之間的折衷方案，使用一個適中的過程來獲得合理的收益（成本和收益的一個平衡）。

之所以能做到這一點，是因為敏捷方法與之前工程方法論強調的那些觀點有著顯著的不同。最直接的不同點就是它不是文件驅動的，通常對於給定的任務只需要較少的文件就可以了。它倒是有點像是程式碼驅動的，遵循著一個規則就是把原始碼作為文件的一部分。但我不認為這是敏捷開發的關鍵，文件的精簡只是一個表象，背後有兩個深層次的原因：

• 敏捷方法是適應性的，而不是可預見性的；工程方法論嘗試用較長的時間把軟體開發的絕大部分做到計劃裡面，在事情沒有變化的時候這個方法表現不錯。所以本質上它是拒絕變化的，而敏捷方法恰恰是歡迎變化的，它強調在變化中適應和成長.
• 敏捷方法是以人為本的而不強調過程的重要性。工程學方法論是想定義一個放之四海皆準的過程，無論誰用都可以。敏捷方法斷言沒有什麼過程會提高開發團隊的技能，過程的角色就是在開發團隊的工作中提供支援。

下面的環節我們將從更多的細節來探討這些不同，這樣你就能理解到底什麼是適應性、以人為本的過程，它的優勢與劣勢，以及最關鍵的一個問題：無論你是一個開發者還是軟體使用者,敏捷是不是你需要的。

可預見性VS適應性 - 涇渭分明的設計與實施

軟體過程通常引入的方法論原則是源於土木工程學或者機械工程學。而這些原則強調建造之前的計劃。工程師會提供一系列的圖紙精確的描述要建造什麼已經怎麼把建造的東西進行組合。許多設計上的決定，比如橋樑負載，在設計圖紙的時候就已經確定了。之後圖紙移交給另外一個小組甚至是另外一個公司來施工。整個的實施工程是嚴格按照圖紙進行的。實施過程中會遇到一些問題，但多數是無關痛癢的小問題。

由於圖紙已經明確說明了各個小塊的內容以及怎麼組合，它們的功能就像是一個細化的實施方案，它指出要做完成什麼任務，以及這些任務之間的依賴關係。這就可以進行進度預計和工程預算。圖紙甚至包括人們具體怎麼實施工程，這樣實施工程的一方不需要太智慧，儘管他們往往技術高超。

所以我們這裡看到的是兩個截然不同的活動。設計很難做出預計，需要大量的有創造性的人蔘與，而實施是很容易預計的。一旦完成了設計就可以制定實施計劃，有了計劃我們就可以對實施過程進行預計和控制。在土木工程中，實施比設計和計劃的成本消耗時間消耗都要大。

脫胎於上述理論的軟體工程學方法論也就變成了這樣：我們需要一個可預見的計劃，用技能比較低的人就可以完成它。要做到這一點我們就必須把設計和實施分離開，因此一個出現了：我們必須知道怎樣做軟體設計才能讓實施工作在設計之後一馬平川的進行下去。

這個計劃是什麼樣的呢？很多時候它的角色就是UML中的設計符號。如果我們可以使用UML來做所有的重要的決定，我們就可以構建出來一個實施計劃並把這個計劃移交給開發組進行編碼。但這個有一個關鍵問題，你能用設計把編碼變成一個可預見的實施活動麼？如果可以的話，消耗的成本是在一個可接受的範圍內麼？

這些引出來一些新問題，首先怎樣把UML式的設計轉化到程式設計師可以接受的狀態。UML式的設計有一個特點就是紙上看起來很不錯，但是到編碼實踐的時候嚴重的錯誤就會凸顯出來。

土木工程學的模型都是基於多年工程的實踐總結，佐之以強制執行，加之精確的數學分析。而UML式的設計只能依賴同事評審，這樣就造成一些錯誤只有在編碼和測試階段才浮出水面。甚至對於一些高水平的設計人員也會認為把設計變成軟體是一件很神奇的事情。

另外一個問題就是平衡支出，建一座橋的設計費用大約是總支出的10%，剩下的實施費用。在軟體開發中編碼佔用的時間遠遠小於這個比例； McConnell 指出對於一個大型的專案只有15%的時間來做編碼和單元測試，這幾乎和建橋的比例完全相反的。即使你把測試也作為實施的一部分設計依然保持50%的比例。這就點出了軟體開發中的設計與它在其它工程學分支中的角色迥異不同！

這些問題讓 Jack Reeves甚至得出這樣的結論：事實上原始碼就是設計文件而實施階段就是使用編譯器和聯結器。當然這時所有的實施階段就可以完全可以也應該自動化完成。這種看法可以得出下面的結論：

• 軟體開發中: 實施是很便宜的甚至是免費的
• 在軟體開發中所有的努力都在設計上，因而需要有創造性和才華的人
• 創造性的過程很難計劃，所以可預計性幾乎是一個不可能完成的任務
• 我們要意識到軟體工程學與傳統工程學的區別，這是一個完全不同的活動，需要一不同的過程。

需求的不可預見性

每一個我參加的專案我都會聽到這樣的小插曲，開發人員告訴我“專案最大的問題就是需求總是變化”，讓我感到驚異的是任何人對此都表示不適應；在開發商業軟體的過程中，變更是正常的，問題是我們如何面對它。

一種方式是把需求變更的原因歸結為糟糕的需求分析。這種觀點的隱含意思是需求分析要在編碼開始之前對需求有一個全面的理解，然後使用者簽字，簽字之後啟動開發過程並儘量不做變更。這裡有一個問題那就是充分理解需求是很難的一件事情，而無法對需求的成本進行評估是這件事情更加難上加難。比如你要給你的車新增一個遮陽篷，而銷售人員無法告訴你要新增10美元還是100美元。不知道花多少錢你怎麼判斷是不是要買？

眾多因素導致估計很難做到，因素之一是軟體開發是一個設計活動難以計劃和估計；因素之二：基本資源一直變化難以估計；因素之三：估計取決於過程中的人，人是很難進行預計和量化分析的。

軟體是沒有物質實體的，在它沒有做出來之前你很難看到它的位置。直到你用的時候你才知道那些功能點是有價值的哪些是沒有價值的。這就要求人們應該認為軟體需求是可以變化的，軟體就是應該是“軟”的。需求不僅僅是可變，而且是應該變；花費大量精力來跟客戶確定需求，特別是客戶也曾經涉足軟體開發那就更糟了，因為他們知道軟體變一下很容易；

即使能得到一個精確的穩定的需求，你依然難逃厄運。今天的經濟形勢就決定了軟體的內容快速變化。今天的好需求，六個月之後就可能一文不值；即使需求不斷的改進也是跟不上經濟發展的步伐；經濟是無法預言的，否定這個觀點的人要麼是撒謊要麼是有足夠的實力可以左右市場；軟體開發中的其他事情都取決於需求，你得不到一個穩定的需求，你也得不到一個可預見的計劃。

可預見性不可能做到嗎?

總體上講，不是的；有些軟體開發是可以做到可預見的。像NASA太空穿梭機軟體開發就是軟體可預見性的樣板。這個需要大量環節，大量時間，一個大型的團隊，一個穩定的需求。但是我不認為多數的商業軟體和太空穿梭機軟體屬於統一範疇。所以需要有一個不同的開發過程。

存在一個危險就是做不到可預言的時候“做可預言狀”；研究方法論的人不善於識別邊界條件：在那個點上方法從合適變成不合適；絕大多數的方法論者都希望自己的理論放之四海皆準，所以他們也不願意公開這個邊界。這就導致了方法論誤用的事情，比如把可預見的方法用在了不可預見的環境中。

那樣做是很有誘惑性的； 可預見性是令人嚮往的，當你明明知其不可為而為之的時候，這就會導致人們早早的做了計劃，之後局面慢慢失控；你發現計劃與現實相去甚遠，你可以在一個較長的時間內依然裝作計劃是有效的；但有時候兩者過於不符，就不能視而不見了，失敗總是痛苦的。

所以如果你在一個不可預見的環境中就不要使用可預見的方法論。那需要多個專案控制模型，多個客戶關係模型，這最終還解決不了問題，真的很殘酷。可預見性很美好，但是太難實踐了。就像大多數問題一樣，最重要的是意識到問題的存在！

不依賴可預見性並不是說你要應付一堆不可控的、混亂的事情。相反你需要一個過程可以應對不可預見性。這就是適應性所關心的。

控制不可預見的過程

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-557389/，如需轉載，請註明出處，否則將追究法律責任。