对比其它软件方法评估敏捷和Scrum
一般来说，选择一种软件开发方法，更像是加入一个邪教组织，而不像是做出了一个技术决策。许多公司甚至从未试图去评估这些方法，而仅仅是盲目采用最流行的方法，这就造成了如今五花八门的各种敏捷方法。因此本文将使用包括功能点、缺陷移除率（DRE）、质量成本（COQ）以及总拥有成本（TCO）在内的一些标准的度量指标，对现代软件开发方法的样本进行比较。
目前有约55种已命名的软件开发方法正在使用，还有更大数量的混合方法。这些开发方法中包括传统的瀑布方法、各种花样的敏捷、Rational统一过程（RUP）、团队软件过程（TSP）、V-模型开发、微软解决方案框架、结构化分析和设计技术（SADT）、持续演进开发（EVO）、极限编程（XP）、PRINCE2、Merise和基于模型的开发，以及更多的其它开发方法。
数据本身是来自于对一定数量的客户的研究成果，这些客户集体使用了各式各样的开发方法。预测部分使用了作者的专有工具Software Risk Master™，这个工具可以创造所有55种软件开发方法的理论模型。
引言
目前有超过55种的软件开发方法存在，而且每一种都有其忠实的追随者，这个事实表达了一个强烈的信息：在这55种软件开发方法中，没有任何一种有能力处理所有规模和种类的软件应用。
其中一些方法最适用于小型应用程序和小型团队；而其它一些方法适用于大型系统和大型团队；一些适用于复杂的嵌入式应用；一些适用于高速的Web开发；一些适用于高安全性的军事应用。是否有可能选择出一种最佳方法来适用于各种具体项目呢？一种方法足够吗？或者企业是否应该基于他们需要开发的项目的种类，使用数种方法？
不幸的是，由于缺乏量化的数据和方法之间的比较，选择一种软件开发方法更像是加入一个邪教组织，而不是一个技术决策。许多公司甚至从未试图去评估那些替代方法，而仅仅是采用当时最流行的方法，无论此方法是否适用于他们所构建的软件的类型。
当这些软件方法被评估后，其结果使我想起了古代的佛教寓言：盲人摸象。不同的开发方法分别有着最快的速度、最高的质量和最低的总拥有成本。
（在原来的寓言中，摸到大象鼻子的盲人认为大象像一条蛇。摸到大象侧面的盲人认为大象像一堵墙。摸到象牙的盲人认为大象像一只长矛。摸到尾巴的盲人认为大象像一根绳子。）
影响软件项目的因素组合
理想的解决方案应是遍历各种规模和类型的软件来评价各式各样的方法。然而由于组合的复杂性，这是很困难的。所以我们只考虑那些众所周知的会对软件项目结果产生影响的主要因素：
| 因素 |
可能性数量 |
| 软件开发方法 |
55 |
| 编程语言 |
50 |
| 应用程序的性质、分类和类型 |
15 |
| 软件能力成熟度模型等级 |
5 |
| 团队经验（低，中，高） |
3 |
| 应用的规模水平（小型，中型，大型） |
3 |
| 应用复杂程度（低，中，高） |
3 |
| 因素组合 |
5，568，750 |
由于对每一个因素都进行考量会导致组合数量过于庞大，所以本文将做出一些简化的假设，从而让我们主要专注于软件开发方法因素，而不是所有其它因素。
在这篇文章中的基本假设是：
| 应用规模 |
1000 个功能点 |
| 编程语言 |
C和C++ |
| 逻辑代码语句 |
75，000行 |
| 需求蔓延 |
省略 |
| 延期的功能特性 |
省略 |
| 可重用的功能特性 |
省略 |
| 团队经验 |
中等 |
| 复杂度 |
中等 |
| 每个员工的月成本 |
$7，500 |
通过将规模、语言、复杂性以及团队的经验保持在恒定的水平，让检查开发方法本身所产生的影响变得更加容易。不幸的是，如果要考虑所有的方法，数量实在过于庞大，因此将会展示的是一个拥有10个方法的子集，所有这10个方法都在美国有着相当广泛的应用。
（请注意，对于用于进行比较的实际应用，其功能点数量从大约800个的规模到1300个不等。作者使用一个专有的数学方法将应用程序的规模调整为固定大小，以便在同等条件下进行比较。）
按字母排序的10个方法（译者注：该顺序根据的英文原文单词的字母顺序）
- Scrum式敏捷
- 瀑布式CMMI 1
- 迭代式CMMI 3
- 螺旋式CMMI 5
- 极限编程（XP）
- 面向对象开发
- 迭代式结对编程
- 瀑布式正确性证明
- Rational 统一过程（RUP）
- 团队软件过程（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种，仍有很多需要进行评估的结果。然而根据来自和数以百计的客户打交道的经验，对于开发经理和高级主管来说最为重要的是以下这些问题：
速度相关的指标
- 开发进度
- 开发人员配备
- 开发工作量
- 开发成本
质量相关的指标
- 潜在缺陷总数
- 缺陷移除率（DRE）
- 已交付缺陷数量
- 高严重性缺陷数量
效益相关的指标
- 总拥有成本（TCO）
- 质量成本（COQ）
即使只展示10种方法和10个问题，其信息总量仍然是相当显著的。
本文将试图从三个方面去比较这些方法：
- 速度：开发进度、开发工作量和开发成本
- 质量：根据已交付缺陷数量得出的软件质量
- 效益：总拥有成本（TCO）和质量成本（COQ）
需要注意的是本文中所使用的技术将保持应用程序的规模恒定在1000个功能点，这意味着对于有10000个功能点的大型系统或者100000个功能点的巨型系统而言，使用本文得出的数据去判定最佳方法是不太稳妥的。尽管如此，1000个功能点数量级的应用程序是非常普遍的，而且这个数量级也足够大到能够以一种非常有用的方式来表达比较结果。
本文中的一些数据是使用作者的软件风险大师™（SRM）工具准备完成的，这个工具被设计为可以对任何开发方法、任何CMMI级别、任何复杂程度以及任何团队经验水平进行对比测试。文中的一些数据表是基于SRM输出数据得到的，虽然这些数据源自于早期被测应用。
速度：针对开发进度和成本进行方法比较
针对方法的首个比较关注初始开发速度和开发成本，及一些短期问题。在笔者的客户中，对软件项目进行评估时最常见的要求是预测开发进度。因为对于大多数软件项目经理和管理人员而言，进度被视为重中之重，表1就是按开发速度排序的方法列表。
表1：软件进度，人员配备，工作量，生产率
| 方法 |
进度 |
人员 |
工作量 |
功能点 |
开发成本 |
|
| （月） |
（人月） |
（每人月） |
||||
| 1 |
极限编程（XP） |
11.78 |
7 |
84 |
11.89 |
$630，860 |
| 2 |
Scrum式敏捷 |
11.82 |
7 |
84 |
11.85 |
$633，043 |
| 3 |
TSP |
12.02 |
7 |
86 |
11.64 |
$644，070 |
| 4 |
螺旋式CMMI 5 |
12.45 |
7 |
83 |
12.05 |
$622，257 |
| 5 |
OO |
12.78 |
8 |
107 |
9.31 |
$805，156 |
| 6 |
RUP |
13.11 |
8 |
101 |
9.58 |
$756，157 |
| 7 |
迭代式结对编程 |
13.15 |
12 |
155 |
9.21 |
$1，160，492 |
| 8 |
迭代式CMMI 3 |
13.34 |
8 |
107 |
9.37 |
$800，113 |
| 9 |
瀑布式正确性证明 |
13.71 |
12 |
161 |
6.21 |
$1，207，500 |
| 10 |
瀑布式CMMI 1 |
15.85 |
10 |
158 |
6.51 |
$1，188，870 |
| 平均 |
13.00 |
8.6 |
112.6 |
9.762 |
$844，852 |
可以看出对于1000个功能点的应用程序，能够产生最短的进度计划的软件开发方法是XP和敏捷方法，TSP位居第三。
质量：比较潜在缺陷总数，缺陷移除率，已交付缺陷数量
比较各种方法的下一个有意思的话题就是质量了。本文从4个方面考虑软件质量：潜在缺陷总数、缺陷移除率、已交付缺陷数量和高严重性缺陷数量。
术语“潜在缺陷总数”是指在需求、设计、源代码、文档以及“不良修复”中发现的缺陷的总和。一个不良修复是指在试图修复以前的缺陷时意外引入的新缺陷。（bug修复尝试中的7％会引入新的bug。）
术语“缺陷移除率”是指代码审查、静态分析和测试的合计效率水平。在本文中包括了以下6种测试类型：1）单元测试；2）功能测试；3）回归测试；4）性能测试；5）系统测试；6）验收测试。
（总共约有40种测试类型，但是特殊形式的测试不在本文的讨论范围之内。）
当质量被评估后，读者们就可以知道为什么之前要援引瞎子和大象的寓言故事：
表2：软件潜在缺陷总数，移除率，已交付缺陷数量
| 方法 |
潜在缺陷 |
缺陷 |
已交付 |
高严重性 |
|
| 总数 |
移除率 |
缺陷数量 |
缺陷数量 |
||
| 1 |
TSP |
2，700 |
96.79% |
87 |
16 |
| 2 |
螺旋式CMMI 5 |
3，000 |
95.95% |
122 |
22 |
| 3 |
RUP |
3，900 |
95.07% |
192 |
36 |
| 4 |
极限编程（XP） |
4，500 |
93.36% |
299 |
55 |
| 5 |
OO |
4，950 |
93.74% |
310 |
57 |
| 6 |
迭代式结对编程 |
4，700 |
92.93% |
332 |
61 |
| 7 |
瀑布式正确性证明 |
4，650 |
92.21% |
362 |
67 |
| 8 |
Scrum式敏捷 |
4，800 |
92.30% |
370 |
68 |
| 9 |
迭代式CMMI 3 |
4，500 |
91.18% |
397 |
73 |
| 10 |
瀑布式CMMI 1 |
6，000 |
78.76% |
1，274 |
236 |
| 平均 |
4，370 |
92.23% |
374 |
69 |
当评估的焦点转向质量而不是速度时，TSP、CMMI 5和RUP名列三甲，XP紧随其后。敏捷在质量方面不是很强因此在10种方法中只排到第8名。敏捷方法对质量措施的缺失以及未采用代码审查在接下来的比较中也将造成一定影响。
经济效益：总拥有成本（TCO）和质量成本（COQ）
对于一些较新的方法，比如敏捷和XP，都还没有使用足够长的时间以展示真正的超过10年或10年以上的长期研究结果。在本文中TCO被限制为仅仅使用5年，因为对于敏捷来说，几乎没有超过5年的研究数据可供参考。
TCO的统计结果包括了开发成本、五年期的改良成本、五年期的维护或缺陷修复成本以及五年期的客户支持成本。虽然软件风险大师工具能够独立地预测这些数值，但本文中他们被全部整合成一个单一的统计结果。
COQ的统计结果是指从需求分析开始，一直到用户使用产品的这5年以来，查找和修复bug的所有直接成本的合计金额。
表 3：总拥有成本（TCO）和质量成本（COQ）
| 方法 |
TCO |
COQ |
Percent |
|
| 1 |
TSP |
$1，026，660 |
$298，699 |
29.09% |
| 2 |
螺旋式CMMI 5 |
$1，034，300 |
$377，880 |
36.53% |
| 3 |
极限编程（XP） |
$1，318，539 |
$627，106 |
47.56% |
| 4 |
RUP |
$1，360，857 |
$506，199 |
37.20% |
| 5 |
Scrum式敏捷 |
$1，467，957 |
$774，142 |
52.74% |
| 6 |
OO |
$1，617，839 |
$735，388 |
45.45% |
| 7 |
迭代式CMMI 3 |
$1，748，043 |
$925，929 |
52.97% |
| 8 |
迭代式结对编程 |
$2，107，861 |
$756，467 |
35.89% |
| 9 |
瀑布式正确性证明 |
$2，216，167 |
$863，929 |
38.98% |
| 10 |
瀑布式CMMI 1 |
$3，944，159 |
$2，804，224 |
71.10% |
| 平均 |
$1，784，238 |
$866，996 |
44.75% |
由于使用TSP、CMMI 5和RUP方法开发的应用程序部署后只有少量的缺陷，因此对它们进行改良、维护和支持是相当简单的。因此5年期总拥有成本这个衡量指标显然有利于质量相关的方法，而不是速度相关的方法。
敏捷也不坏，但是COQ占比超过了50％，因此敏捷需要严肃认真地把质量摆在更首要的位置上。
COQ百分比揭示了软件应用的一大痼疾。我们有如此之多的bug，以至于查找和修复bug对开发和总拥有成本而言都是主要成本。
单项指标冠军榜
为了继续瞎子摸象的寓言故事，这里是10类指标中每类单项指标的冠军方法：
表4：10类指标的单项冠军
| 1. |
开发进度 |
极限编程（XP） |
| 2. |
开发人员配备 |
Scrum式敏捷（绑定） |
| 3. |
开发工作量 |
螺旋式CMMI 5 |
| 4. |
开发成本 |
螺旋式CMMI 5 |
| 5. |
潜在缺陷总数 |
TSP |
| 6. |
缺陷移除率（DRE） |
TSP |
| 7. |
已交付缺陷数量 |
TSP |
| 8. |
高严重性缺陷数量 |
TSP |
| 9. |
总拥有成本（TCO） |
TSP |
| 10. |
质量成本（COQ） |
TSP |
对于这些方法的比较结果，成语“三思而后行”（译者注：原文是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也实现了其目标，所交付的产品中只有很少的缺陷。
对各种规模和类型的软件应用程序而言，没有任何一种方法是可以一直获得成功的包治百病的灵丹妙药。
本文尝试去做的是就通过以下三个重要因素找出最恰当的软件开发方法：
- 开发速度
- 开发质量
- 长期经济效益
关于作者
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
感谢赵震一对本文的审校。