IT工程師數位筆記本

一般來說，選擇一種軟件開發方法，更像是加入一個邪教組織，而不像是做出了一個技術決策。許多公司甚至從未試圖去評估這些方法，而僅僅是盲目采用最流行的方法，這就造成了如今五花八門的各種敏捷方法。因此本文將使用包括功能點、缺陷移除率（DRE）、質量成本（COQ）以及總擁有成本（TCO）在內的一些標準的度量指標，對現代軟件開發方法的樣本進行比較。

目前有約55種已命名的軟件開發方法正在使用，還有更大數量的混合方法。這些開發方法中包括傳統的瀑布方法、各種花樣的敏捷、Rational統一過程（RUP）、團隊軟件過程（TSP）、V-模型開發、微軟解決方案框架、結構化分析和設計技術（SADT）、持續演進開發（EVO）、極限編程（XP）、PRINCE2、Merise和基于模型的開發，以及更多的其它開發方法。

數據本身是來自于對一定數量的客戶的研究成果，這些客戶集體使用了各式各樣的開發方法。預測部分使用了作者的專有工具Software Risk Master™，這個工具可以創造所有55種軟件開發方法的理論模型。

引言

目前有超過55種的軟件開發方法存在，而且每一種都有其忠實的追隨者，這個事實表達了一個強烈的信息：在這55種軟件開發方法中，沒有任何一種有能力處理所有規模和種類的軟件應用。

其中一些方法最適用于小型應用程序和小型團隊；而其它一些方法適用于大型系統和大型團隊；一些適用于復雜的嵌入式應用；一些適用于高速的Web開發；一些適用于高安全性的軍事應用。是否有可能選擇出一種最佳方法來適用于各種具體項目呢？一種方法足夠嗎？或者企業是否應該基于他們需要開發的項目的種類，使用數種方法？

不幸的是，由于缺乏量化的數據和方法之間的比較，選擇一種軟件開發方法更像是加入一個邪教組織，而不是一個技術決策。許多公司甚至從未試圖去評估那些替代方法，而僅僅是采用當時最流行的方法，無論此方法是否適用于他們所構建的軟件的類型。

當這些軟件方法被評估后，其結果使我想起了古代的佛教寓言：盲人摸象。不同的開發方法分別有著最快的速度、最高的質量和最低的總擁有成本。

（在原來的寓言中，摸到大象鼻子的盲人認為大象像一條蛇。摸到大象側面的盲人認為大象像一堵墻。摸到象牙的盲人認為大象像一只長矛。摸到尾巴的盲人認為大象像一根繩子。）

影響軟件項目的因素組合

理想的解決方案應是遍歷各種規模和類型的軟件來評價各式各樣的方法。然而由于組合的復雜性，這是很困難的。所以我們只考慮那些眾所周知的會對軟件項目結果產生影響的主要因素：

由于對每一個因素都進行考量會導致組合數量過于龐大，所以本文將做出一些簡化的假設，從而讓我們主要專注于軟件開發方法因素，而不是所有其它因素。

在這篇文章中的基本假設是：

通過將規模、語言、復雜性以及團隊的經驗保持在恒定的水平，讓檢查開發方法本身所產生的影響變得更加容易。不幸的是，如果要考慮所有的方法，數量實在過于龐大，因此將會展示的是一個擁有10個方法的子集，所有這10個方法都在美國有著相當廣泛的應用。

（請注意，對于用于進行比較的實際應用，其功能點數量從大約800個的規模到1300個不等。作者使用一個專有的數學方法將應用程序的規模調整為固定大小，以便在同等條件下進行比較。）

按字母排序的10個方法（譯者注：該順序根據的英文原文單詞的字母順序）

1. Scrum式敏捷
2. 瀑布式CMMI 1
3. 迭代式CMMI 3
4. 螺旋式CMMI 5
5. 極限編程（XP）
6. 面向對象開發
7. 迭代式結對編程
8. 瀑布式正確性證明
9. Rational 統一過程（RUP）
10. 團隊軟件過程（TSP）

因為并不是每個讀者都可能熟悉每一個方法，以下是本文對這些方法的簡述：

Scrum式敏捷：術語“敏捷”有著多義性，我們有著很多種不同特性的敏捷開發方法。在這篇文章中所使用的術語“敏捷”，用于特指滿足以下條件的項目：或多或少地遵循了1997年的敏捷宣言，由內部用戶提供需求、使用用戶故事、將項目劃分成進行單獨開發的獨立Sprint，并且使用了Scrum的概念以及有每日狀態會議。最大限度地減少文書工作以及加快開發速度，這是敏捷的首要目標。

瀑布式CMMI 1：軟件工程研究所的軟件能力成熟度模型集成™（CMMI）是一個眾所周知的用于評估軟件開發的先進程度的方法。CMMI 1是5個CMMI 等級中位于最底部的初始等級，這意味著相當混亂的開發。術語“瀑布”是指傳統軟件實踐中的順序式開發，它從需求分析開始順序進行，在完成當前步驟之前，都不會進行下一個步驟。

迭代式CMMI 3 ：CMMI的第三級被稱為“定義級”，指的是有一整套的合理順暢、易于理解的開發步驟。術語“迭代”比“敏捷”出現的更早，也有將應用程序劃分成可以單獨構建的獨立部分的類似含義。

螺旋式CMMI 5 ：CMMI的第五級是五級中的頂級，被稱為“優化級”。達到這種水平的組織相當先進和熟練，很少犯嚴重錯誤。軟件開發的螺旋式模型是由Barry Boehm博士首創的，它所強調的思想也出現在敏捷中，比如可以單獨進行開發的獨立分段。螺旋式模型中的分段通常大于敏捷中的分段，并且會先有原型。

極限編程（XP）：這種方法也在敏捷開發的范疇之內，但有一些獨特的特性。最顯著的特征是，在測試用例被首先開發完成之前，會一直推遲編碼。XP方法也使用代碼評審或代碼審查。有時XP也使用結對編程，但并非總是如此，所以那是一個特殊情況。最終軟件的質量是XP方法的主要目標。

面向對象開發（OO）：OO方法是這篇文章中歷史最悠久的開發方法之一，并已經獲得過多次成功。這也導致了一些特殊語言的創立，比如Objective C。在這篇文章中使用的是用例式的OO分析和設計。C++語言也是一種面向對象的語言。OO分析和設計與傳統方法是有所不同的，因此需要有一個學習曲線。

結對編程：結對編程的概念通常是敏捷方法的一部分，但并不限于敏捷方法。在本文中，結對編程和迭代式開發一起使用。結對編程的基本思想是兩個人輪流編碼。當一個人在編碼時，另一個觀察并提出建議。有時這兩個人共同使用一臺計算機或工作站。

正確性證明：正確性證明隱含的觀點是，在軟件應用程序中將會包含對算法實施正規的數學性證明的部分。很明顯算法需要用一個正規的方式來表達，它才可以被證明。同樣明顯的是，進行正確性證明的人需要有足夠的數學技巧來處理相當復雜的公式和算法。

Rational統一過程（RUP）：RUP方法源自于Rational公司，該公司在2003年被IBM收購，所以現在這是IBM的一個方法。RUP方法包括迭代和面向對象開發這兩個方面。自從RUP歸IBM所有至今，已經有了很多支持這種方法的工具。對于使用RUP的應用程序，用例和可視化建模是標準用法，但是筆者的客戶通常也會引入其他方法，比如決策表。

團隊軟件過程（TSP）：TSP方法是由已故的Watts Humphrey發明的，他曾是IBM的程序設計總監，后來他還創立了軟件工程研究所（SEI）能力成熟度模型所使用的評估方法。 TSP非常注重軟件的質量。所有的bug都要被記錄下來并使用代碼審查，鑒于正是bug減慢了開發，因此高質量是主要的目標。TSP方法有著一些與眾不同的方面，比如自管理工具和擔負經理職責的教練。目前TSP受到SEI的擁護和支持。

三種方法評估類型和10個度量指標

即使將方法數目限制到了10種，仍有很多需要進行評估的結果。然而根據來自和數以百計的客戶打交道的經驗，對于開發經理和高級主管來說最為重要的是以下這些問題：

速度相關的指標

1. 開發進度
2. 開發人員配備
3. 開發工作量
4. 開發成本

質量相關的指標

1. 潛在缺陷總數
2. 缺陷移除率（DRE）
3. 已交付缺陷數量
4. 高嚴重性缺陷數量

效益相關的指標

1. 總擁有成本（TCO）
2. 質量成本（COQ）

即使只展示10種方法和10個問題，其信息總量仍然是相當顯著的。

本文將試圖從三個方面去比較這些方法：

1. 速度：開發進度、開發工作量和開發成本
2. 質量：根據已交付缺陷數量得出的軟件質量
3. 效益：總擁有成本（TCO）和質量成本（COQ）

需要注意的是本文中所使用的技術將保持應用程序的規模恒定在1000個功能點，這意味著對于有10000個功能點的大型系統或者100000個功能點的巨型系統而言，使用本文得出的數據去判定最佳方法是不太穩妥的。盡管如此，1000個功能點數量級的應用程序是非常普遍的，而且這個數量級也足夠大到能夠以一種非常有用的方式來表達比較結果。

本文中的一些數據是使用作者的軟件風險大師™（SRM）工具準備完成的，這個工具被設計為可以對任何開發方法、任何CMMI級別、任何復雜程度以及任何團隊經驗水平進行對比測試。文中的一些數據表是基于SRM輸出數據得到的，雖然這些數據源自于早期被測應用。

速度：針對開發進度和成本進行方法比較

針對方法的首個比較關注初始開發速度和開發成本，及一些短期問題。在筆者的客戶中，對軟件項目進行評估時最常見的要求是預測開發進度。因為對于大多數軟件項目經理和管理人員而言，進度被視為重中之重，表1就是按開發速度排序的方法列表。

表1：軟件進度，人員配備，工作量，生產率

可以看出對于1000個功能點的應用程序，能夠產生最短的進度計劃的軟件開發方法是XP和敏捷方法，TSP位居第三。

質量：比較潛在缺陷總數，缺陷移除率，已交付缺陷數量

比較各種方法的下一個有意思的話題就是質量了。本文從4個方面考慮軟件質量：潛在缺陷總數、缺陷移除率、已交付缺陷數量和高嚴重性缺陷數量。

術語“潛在缺陷總數”是指在需求、設計、源代碼、文檔以及“不良修復”中發現的缺陷的總和。一個不良修復是指在試圖修復以前的缺陷時意外引入的新缺陷。（bug修復嘗試中的7％會引入新的bug。）

術語“缺陷移除率”是指代碼審查、靜態分析和測試的合計效率水平。在本文中包括了以下6種測試類型：1）單元測試；2）功能測試；3）回歸測試；4）性能測試；5）系統測試；6）驗收測試。

（總共約有40種測試類型，但是特殊形式的測試不在本文的討論范圍之內。）

當質量被評估后，讀者們就可以知道為什么之前要援引瞎子和大象的寓言故事：

表2：軟件潛在缺陷總數，移除率，已交付缺陷數量

當評估的焦點轉向質量而不是速度時，TSP、CMMI 5和RUP名列三甲，XP緊隨其后。敏捷在質量方面不是很強因此在10種方法中只排到第8名。敏捷方法對質量措施的缺失以及未采用代碼審查在接下來的比較中也將造成一定影響。

經濟效益：總擁有成本（TCO）和質量成本（COQ）

對于一些較新的方法，比如敏捷和XP，都還沒有使用足夠長的時間以展示真正的超過10年或10年以上的長期研究結果。在本文中TCO被限制為僅僅使用5年，因為對于敏捷來說，幾乎沒有超過5年的研究數據可供參考。

TCO的統計結果包括了開發成本、五年期的改良成本、五年期的維護或缺陷修復成本以及五年期的客戶支持成本。雖然軟件風險大師工具能夠獨立地預測這些數值，但本文中他們被全部整合成一個單一的統計結果。

COQ的統計結果是指從需求分析開始，一直到用戶使用產品的這5年以來，查找和修復bug的所有直接成本的合計金額。

表 3：總擁有成本（TCO）和質量成本（COQ）

由于使用TSP、CMMI 5和RUP方法開發的應用程序部署后只有少量的缺陷，因此對它們進行改良、維護和支持是相當簡單的。因此5年期總擁有成本這個衡量指標顯然有利于質量相關的方法，而不是速度相關的方法。

敏捷也不壞，但是COQ占比超過了50％，因此敏捷需要嚴肅認真地把質量擺在更首要的位置上。

COQ百分比揭示了軟件應用的一大痼疾。我們有如此之多的bug，以至于查找和修復bug對開發和總擁有成本而言都是主要成本。

單項指標冠軍榜

為了繼續瞎子摸象的寓言故事，這里是10類指標中每類單項指標的冠軍方法：

表4：10類指標的單項冠軍

對于這些方法的比較結果，成語“三思而后行”（譯者注：原文是be careful of what you wish for because you might get it，大意是請謹慎地許愿，不然你的愿望有可能會實現，但是同時會帶來很多你未曾預料的負面問題）似乎是恰當的。各種方法各有專長，注重速度的方法比如敏捷是非常快的，注重質量的方法比如TSP、RUP和CMMI5只有非常少的缺陷數量。

為什么一些方法在速度，質量和效益方面都名列下游

可以看出，各個方法在速度，質量和效益三方面的效果是參差不齊的。然而，有這么三種方法，它們的所有三項評估結果中都名列下游。這些落后的方法是瀑布式方法（它是倒數第一的方法），正確性證明方法，以及結對編程方法。探究這三種方法名列下游的可能原因是有意義的。

瀑布式CMMI 1

在超過50年的軟件項目中，已經有約35％因質量差或超支問題而被取消，這并不是什么秘密。這些被取消的項目大多數都采用瀑布式開發，并且要么處于CMMI1級水平，要么干脆完全沒有使用CMMI。

在本文使用的1000個功能點數量級的瀑布式開發例子中，用于尋找和修復bug的時間和精力百分比約為25.71％。沒有按期交付、超出預算的項目數量占50％左右。這些都不是非常大型的應用程序，但是在瀑布式開發中他們經常變得困難和棘手。

應當提及的是，大部分新方法的主要動機正是為了克服瀑布式開發相關的歷史問題。

的確有零星的幾個成功的瀑布式項目，但是這些項目往往是由專家團隊完成的。

結對編程

不幸的是，結對編程是一個代價高昂的錯誤。關于“讓兩個人輪流編程，其中一個人觀察”這種想法，它僅僅是一個理論性的想法，在具體實踐中是比較差的。結對編程的根據是有硬傷的。雖然有著這樣的論斷：結對編程比起單獨工作的程序員而言，創造出的軟件bug會更少，但是不幸的是，結對編程中的每個單獨的程序員仍然在使用基本的瀑布方法。對于能夠在工作中使用靜態分析并參加正式的代碼審查的有能力的程序員個體而言，只需要花結對編程一半左右的成本，他們就可以生產出更好的代碼。

此外，約有90種不同的軟件職業。為什么只把程序員數量翻倍而不管其他人？如果結對編程的想法真的能夠像它斷言的那樣起作用，那么架構師，業務分析師，測試人員，QA和其他所有人都應當被翻倍。為什么不使用兩個項目經理而只使用一個？

結對編程的使用是使用了糟糕的評估方法的典型癥狀，而且也是對大規模人群中的人才分布情況缺乏理解的表現。如果一家公司正在用500個程序員建設一個大型系統，那么再引進或雇傭500人和他們結對將是不可能的。

正確性證明

正確性證明的觀點是一個學術構想而且過于理論化。為了驗證軟件中的算法，這些算法需要被正規地表述，而且進行正確性證明的人員需要大量的數學修養。即便如此，在很多正確性證明中仍會有錯誤發生。

本文所使用的1000個功能點的例子，共有約690個具體的需求需要被證明。這就是為什么即使是很小的應用程序，使用正確性證明方法進行開發也需要很長的時間，因為證明過程是非常耗時的。

對于10000個功能點的應用程序，使用正確性證明方法基本上是不可能的，因為有7407個具體的算法需要被證明，這可能要花幾年的時間，而在此期間需求將改變很多以至于早期的證明可能已經不再適用。

使軟件開發方法和項目相匹配

由于沒有一種方法是在所有指標上都名列第一的，讀者可能會問，如何為他們項目的需求選擇相匹配的方法。

對于有1000個或更少的功能點的相對較小的應用程序，交付速度是最關鍵的參數，因此XP，敏捷和TSP都是很不錯的選擇。

對于那些復雜的應用程序，這些應用程序可能需要得到FDA（美國食品和藥物管理局）的批準，可能會操作武器系統或控制敏感的財務數據，對于它們而言較高的質量水平是必需的。在這個類別中，TSP、CMMI 5及RUP是最佳選擇，XP也是另一個可選的方法。此類應用上也曾使用敏捷，但必須做出大量的變化和不同的詮釋，以至于它已經不再是那么敏捷了。敏捷在質量上還是不夠強。

對于那些可能會使用10年以上，或者需要非常頻繁的改進以至于必須精心設計內部結構的應用程序，TSP將會是最佳選擇，同時CMMI 5、RUP和XP也是可選項。對于需要長期維護和改進的項目，敏捷還沒有表現出太多的成功之處。

總結與結論

正如本文所述，軟件行業大約有55種不同的開發方法。在這么短的一篇文章中對所有方法進行比較的話，55種這個數字太大了。

對于本文中進行了比較的10種方法，大多數方法都曾獲得過一些成功同時也曾有過個別失敗。

總體而言，敏捷家族及其它強調速度的方法實現了其目標，它們是相當快的。

強調質量的方法如TSP、RUP和CMMI5也實現了其目標，所交付的產品中只有很少的缺陷。

對各種規模和類型的軟件應用程序而言，沒有任何一種方法是可以一直獲得成功的包治百病的靈丹妙藥。

本文嘗試去做的是就通過以下三個重要因素找出最恰當的軟件開發方法：

1. 開發速度
2. 開發質量
3. 長期經濟效益

關于作者

Capers Jones 目前是 Namcook Analytics LLC 的副總裁和CTO。該公司設計了最前沿的風險、成本和質量評估及測量工具。他曾擔任 Capers Jones & Associates LLC 的總裁直到2012年，之前曾作為軟件研究人員和經理在IBM工作了12年，還曾擔任ITT公司的程序設計副總監，正是在ITT工作時他開始了他們的軟件評估計劃。Capers是一個知名作者同時也是國際級的公開演講發言人。他的一些著作包括 The Economics of Software Quality（《軟件質量的經濟效益》，和Olivier Bonsignour合著），Software Engineering Best Practices（《軟件工程最佳實踐》），Applied Software Measurement and Estimating Software Costs（《實施軟件測量與評估軟件成本》）。目前他正致力于他的第15本著作，書名是 The Technical and Social History of Software Engineering（《軟件工程的技術與社會史》），將會在2013年秋季發行。

Capers和他的同事們收集了用于判斷軟件過程改進方法的有效性的歷史數據，這些數據也可用于校準軟件預估的準確性，假設軟件官司的訴訟中有質量、生產率和進度部分的話，這些數據也會被引用。他還曾在15起涉及違反合約及軟件稅務問題的訴訟中擔任專家證人。

查看英文原文：Evaluating Agile and Scrum with Other Software Methodologies

感謝趙震一對本文的審校。