软件估算的艺术 下载 pdf 百度网盘 epub 免费 2025 电子版 mobi 在线

《软件估算的艺术》介绍了如何估算项目进度和成本以及在给定时间框架内可以交付的功能，讲解了如何避免常见的软件估算错误，个人、团队和组织如何估算，介绍了项目中的特定活动，包括开发、管理和缺陷修复等。《软件估算的艺术》共23章，不仅包含严谨的建模技术，还呈现了大量真实的、来自软件行业的实践经验。 作为影响力大的专业估算指南，《软件估算的艺术》为现实世界中的软件项目开发成本估算提供了经济实用的建议，尤其适合软件行业的技术人员和技术管理人员参考与阅读。

第I部分  估算的关键概念

第1章  什么是估算  //  3

1.1  估算、目标和承诺  //  3

1.2  估算与计划的关系  //  4

1.3  关于估算、目标和承诺的沟通  //  5

1.4  用概率表述估算  //  6

1.5  “好的”估算的常见定义  //  9

1.6  估算和项目控制  //  12

1.7  估算的真正目的  //  13

1.8  “好估算”的有效定义  //  14

更多资源  //  15

第2章  你的估算能力如何  //  17

2.1  一个简单的估算测试  //  17

2.2  探讨测试结果  //  18

第3章  准确估算的价值  //  23

3.1  高估和低估，哪个更好？  //  23

3.2  软件行业中一些估算的跟踪记录  //  27

3.3  准确估算的益处  //  30

3.4  相较于其他期望的项目属性，可预测性的价值  //  31

3.5  常见估算技术的问题  //  33

更多资源  //  34

第4章  估算错误从何而来  //  35

4.1  估算中不确定性的来源  //  36

4.2  不确定性锥形  //  37

4.3  混乱的开发过程  //  43

4.4  不稳定的需求  //  44

4.5  被遗漏的活动  //  45

4.6  盲目乐观  //  48

4.7  主观性和偏见  //  49

4.8  即兴估算  //  51

4.9  不适当的数值精度  //  53

4.10  其他错误来源  //  54

更多资源  //  55

第5章  影响估算的因素  //  57

5.1  项目规模  //  57

5.2  正在开发的软件类型  //  64

5.3  人员因素  //  65

5.4  编程语言  //  66

5.5  其他影响项目的因素  //  67

5.6  再论规模不经济效应  //  72

更多资源  //  74

第II部分  基本估算技术

第6章  估算技术介绍  //  79

6.1  选择估算技术时的考虑因素  //  79

6.2  技术适用性列表  //  82

第7章  计数，计算，判断  //  85

7.1  首先计数  //  86

7.2  计数对象  //  87

7.3  使用计算将计数结果转换为估算  //  88

7.4  判断只能作为后的手段  //  90

更多资源  //  91

第8章  校准与历史数据  //  93

8.1  历史数据的益处：提高准确性以及其他  //  94

8.2  需要收集的数据  //  97

8.3  如何校准  //  100

8.4  使用项目数据改进估算  //  101

8.5  用行业平均数据进行校准  //  102

8.6  小结  //  104

更多资源  //  104

第9章  个体专家判断  //  105

9.1  结构化专家判断  //  106

9.2  将估算与实际进行比较  //  110

更多资源  //  112

第10章  分解与重组  //  113

10.1  准确计算总体期望情况  //  113

10.2  基于活动的项目工作分解结构进行分解  //  117

10.3  直接合计情况和差情况估算的危害  //  118

10.4  创建有意义的总体和差情况估算  //  121

更多资源  //  126

第11章  类比估算  //  127

11.1  类比估算的基本方法  //  128

11.2  关于Triad估算中不确定性的评论  //  132

第12章  基于代理的估算  //  135

12.1  模糊逻辑  //  136

12.2  标准组件  //  138

12.3  故事点  //  141

12.4  T恤尺码  //  145

12.5  基于代理的技术的其他使用  //  147

12.6  更多资源  //  147

第13章  群体专家判断  //  149

13.1  团队评审  //  149

13.2  宽带德尔菲法技术  //  150

更多资源  //  155

第14章  软件估算工具  //  157

14.1  手工无法完成只能依赖于工具的事情  //  157

14.2  校准这些工具所需要的数据  //  162

14.3  无论用不用工具都应该做的事  //  162

14.4  可用工具总结  //  162

更多资源  //  163

第15章  多种方法的综合运用  //  165

更多资源  //  169

第16章  一个估算得当的项目的软件 估算流程  //  171

16.1  估算不当的项目的单次估算流程  //  171

16.2  良好估算的项目的单次估算流程  //  172

16.3  随时间推移整个项目的估算流程  //  173

16.4  估算改进  //  175

16.5  如何向其他项目干系人展示重估的结果  //  176

16.6  估算良好的项目的示例  //  178

第17章  标准化的估算流程  //  181

17.1  标准化流程的一般要素  //  181

17.2  在阶段-关卡流程中嵌入估算活动  //  182

17.3  串行项目的标准化估算流程示例  //  184

17.4  迭代项目的标准化估算流程示例  //  187

17.5  来自先进组织的标准化估算流程示例  //  189

17.6  改进标准化流程  //  191

更多资源  //  191

第III部分  估算所面临的具体挑战

第18章  估算项目规模的具体 问题  //  195

18.1  估算规模的挑战  //  195

18.2  功能点估算  //  198

18.3  简化的功能点技术  //  201

18.4  估算规模的技术总结  //  203

更多资源  //  204

第19章  估算工作量的具体问题  //  205

19.1  影响工作量的因素  //  205

19.2  根据规模计算工作量  //  207

19.3  利用估算科学计算工作量估算  //  208

19.4  行业平均工作量图  //  209

19.5  ISBSG方法  //  214

19.6  比较工作量估算结果  //  216

更多资源  //  217

第20章  估算进度的具体问题  //  219

20.1  时间进度基本方程  //  220

20.2  通过与过去项目的非正式比较来计算进度  //  221

20.3  琼斯的一阶估算实践  //  222

20.4  利用估算科学计算进度      估算  //  223

20.5  进度压缩和尽可能短的      进度  //  224

20.6  进度和工作量之间的      权衡  //  227

20.7  进度估算和人员配置      限制  //  228

20.8  不同进度估算方法的结果比较  //  229

更多资源  //  231

第21章  估算项目规划参数  //  233

21.1  估算项目中的活动分解  //  233

21.2  估算不同活动的进度  //  238

21.3  将估算工作量（理想工作量）转为规划工作量  //  240

21.4  成本估算  //  241

21.5  估算软件缺陷的产生和消除  //  242

21.6  估算风险和应急缓冲  //  245

21.7  其他经验法则  //  247

更多资源  //  247

第22章  估算的展示风格  //  249

22.1  沟通估算假设  //  249

22.2  表达不确定性  //  250

22.3  使用范围（任何类型）  //  256

更多资源  //  257

第23章  政治、谈判和解决问题  //  259

23.1  高管的特性  //  259

23.2  对估算的政治影响  //  260

23.3  问题的解决和原则谈判方法  //  263

更多资源  //  270

附录A  估算完整性检查  //  271

附录B  第2章小测验的答案  //  273

附录C  软件估算技巧  //  275

作者简介

史蒂夫·麦康奈尔（Steve McConnell），Construx软件公司的首席软件工程师，负责领导公司的软件工程实践。史蒂夫是软件工程知识体系（SWEBOK）项目中构建知识领域的负责人。史蒂夫先后在微软、波音和西雅图地区的其他公司做软件项目。

史蒂夫是《快速开发》（1996）、《软件项目的艺术》（1998）、《软件开发的艺术》（2004）和《代码大全2》的作者。他的书曾经两次获得《软件开发》杂志的年度杰出软件开发书籍奖。史蒂夫也是SPC估算专家软件的首席开发人员，该软件获得《软件开发》生产力奖。1998年，《软件开发》杂志的读者将史蒂夫与比尔·盖茨（Bill Gates）和莱纳斯·托瓦兹（Linus Torvalds）并列为软件业有影响力的三大人物。

史蒂夫在惠特曼学院获得学士学位，在西雅图大学获得软件工程硕士学位。他生活在华盛顿的贝尔维尤地区。

译者简介

杨志昂，Doris，男生名女生的命，理工脑文艺心，当过程序媛，做过管理者，时而理性，时而感性，可严密论证，可天马行空，个性既矛盾又综合。好学好问，门门懂样样求精的“万精油”型人才。翻译作品有《同理心：沟通、协作与创造力的奥秘》、《代码大全2》（纪念版）与《向上一步：精益敏捷中的增长思维

暂无出版社相关信息，正在全力查找中！

第1章  什么是估算

    没有使用定量方法、几乎没有数据支撑且主要由管理者的预感来决定的估算，人们很难为之进行激情洋溢、合情合理且还冒着失业风险的辩护。

——布鲁克斯（Fred Brooks）

你可能认为你自己早就知道什么是估算。而我的目标是在本章结束时能够说服你“估算并不同于大多数人之前的想法”。一个良好的估算和人们之前的认知差异更大。

下面是《美国传统词典》第2版（1985年）对estimate一词的定义：“1. 尝试性的评估或粗略的计算；2. 项目成本的初步计算；3. 基于印象的判断或见解。”

这些听起来像我们在进行估算时必须要做的事情吗？是否有人要求你做一个尝试性或初步的计算，也就是说，希望以后能对此时的想法做出调整？

或许并非如此。当高层管理者要求有一个“估算”时，通常是要求一个承诺或一个实现目标的计划。估算、目标和承诺之间的区别，对于理解什么是估算、什么不是估算以及如何更好地进行估算至关重要。

  1.1  估算、目标和承诺

严格地说，词典对估算的定义是正确的：估算是对项目将花多长时间或花多少成本的预测。但是软件项目的估算与商业目标、团队承诺和项目控制相互影响又相互作用。

目标是对理想商业目标的陈述。典型的例子如下所示。

? “我们需要在5月份的贸易展上演示2.1版本。”

? “我们需要赶在节假日促销季到来之前发布稳定版本。”

? “这些功能需要在7月1日之前完成，这样我们才能合乎政府的相关规定。”

? “我们必须将下一个版本的成本控制在200万美元以内，因为这是我们对该版本所能提供的预算。”

企业有重要的理由建立独立于软件估算的目标。但一个目标是美好的，甚至是强制性的，并不一定意味着它是可以实现的。

目标是对理想商业目标的描述，而承诺是在特定日期之前以特定质量级别交付已定义功能的保证。承诺可以和估算相同，也可以比估算更激进或更保守。换句话说，请不要假设承诺必须与估算相同，承诺和估算是两个不同的概念。

#1  区分估算、目标和承诺。

  1.2  估算与计划的关系

估算和计划是相关的两个主题，但是估算不是计划，计划也不是估算。估算应被视为一种公正客观的分析过程；计划应该视为一个带有主观偏见并刻意追求目标的过程。对于估算而言，想要估算得出任何特定的答案都是危险有害的。估算的目标应当是准确性，而不是寻求一个特定的结果。但是，计划的目标是寻求一个特定的结果。我们可以故意（当然是适当地）偏离我们的计划以达到特定的结果。我们计划用特定的方法和手段来达到一个具体的目标。

估算是计划的基础，但计划并不总是与估算相同。如果估算与目标差异极大，项目计划必须承认二者之间的差距，并承担与之相应的高风险。如果估算值接近目标，那么计划可以承担相对较小的风险。

估算和计划都很重要，但是这两种活动之间的根本区别意味着，将两者混为一谈往往会导致糟糕的估算和糟糕的计划。一个强势的计划目标的存在，可能导致用目标直接去替代本应客观分析得出的估算；项目成员甚至可能将目标直接称为“估算”，让它堂而皇之顶着一个本不应该有的客观性光环。

以下是某种程度上依赖于准确估算的项目计划考虑：

? 制定详细的时间进度

? 识别项目的关键路径

? 创建一个完整的工作分解结构

? 为交付确定功能的优先级排序

? 将项目分解为多个迭代

准确的估算有助于在这些领域工作更顺利地开展，第21章“估算项目规划参数”将更详细地讨论这些主题。

在线阅读地址：软件估算的艺术在线阅读

在线听书地址：软件估算的艺术在线收听

在线购买地址：软件估算的艺术在线购买

暂无原文赏析，正在全力查找中！

编辑推荐

两届《软件开发杂志》震撼大奖得主畅销多年的估算经典著作

条分缕析，澄清与软件估算相关的误解，提供实用有效的正见

为大中小型软件开发组织提供可以立即落地的实用性估算方法

118个技巧点拨，覆盖软件估算流程和创建成功估算的各个步骤

云端免费提供双色示意图，以通俗易懂的形式揭示估算的魔法

基于复杂性和不确定性的原因，软件估算通常被诟病为“黑魔法”。事实上，它并不是什么不容易掌握的“巫术”，而是有技巧，有规律可循的。事实上，要想做出准确的估算，并不难，甚至可以说是简单直观、一点就破的，前提是我们从根源上透彻理解和掌握估算的艺术。

在这本呼声很高的书中，著名科技类作家史蒂夫•麦康奈尔揭秘了软件估算的成功要素。通过提炼学术研究和实战经验的方式，专门打磨出这样一本供软件从业人员参考的实用指南。本书不同于晦涩难懂的论文，也不涉及严密的建模技术，而是强调经过反复验证的流程、简单易懂的公式以及对实际操作的启发，可以帮助个人和开发团队立即在项目中实践熟练有用的估算。

《软件估算的艺术》覆盖以下特色主题：

●  如何估算项目进度和成本或者估算在给定时间框架内可以交付的软件功能

●  如何避免常见的软件估算错误

●  个人、团队和组织如何学会进行合理的估算

●  项目中特定的活动怎么估，包括开发，管理和缺陷修复

●  小型或大型项目以及敏捷项目或传统项目应该如何估

●  如何聚焦于共同利益，在险象环生的政治环境中做出合理的估算

在软件项目失败屡见不鲜的常态下，史蒂夫•麦康奈尔用这本书向你展示了软件估算的秘诀与要领。

前言

作为成本估算人员，在成长过程中糟糕的那三年简直就像在五年级时做算术题。

——奥古斯丁（Norman R. Augustine）

软件估算并不困难。40年来，专家们一直在研究和撰写关于软件估算的文章，随之开发出来支持准确估算的技术数不胜数。创建准确的估算是一件直截了当的事，一旦我们理解了如何创建它们。但是，并非所有的估算实践都是直观明了的，即便是再聪明的人也做不到独自一人发掘出所有的优秀实践。更何况在软件行业中，实际上，某人是专业的开发人员并不代表此人一定是一名专业的估算人员。

估算涉及的方方面面并不像表面看起来那么简单。许多所谓的“估算问题”，产生的原因是由于误解了什么是估算，或者混淆了其他类似但并不相同的概念。一些直观上有效的估算实践并不能产生准确的结果。直接套用复杂的公式有时弊大于利，一些看似简单的方法反而却能产生不可思议的准确结果。

这本书提炼了40年的科学研究和几十年的软件行业实践经验，以求帮助软件开发人员、团队领导、测试人员和管理人员成为高效的估算人员。由于影响软件估算的因素本身就直接与软件开发紧密相关，所以对于软件估算的学习在软件行业里是广泛适用的。

软件估算的艺术与科学

目前关于软件估算的研究主要集中在改善估算技术，从而使得成熟的组织可以让项目结果落入估算结果上下浮动5%而非上下浮动10%的误差范围。这些技术往往有令人眼花缭乱的数学模型。理解这些模型需要很强的数学背景和长年累月的专业学习，而使用这些数学模型需要捣鼓的数值计算更是远远超出了我们手边计算器的能力。这些估算技术嵌入商业软件估算工具中会有卓越的表现。我在此将此类实践统称为估算科学。

然而，现实中典型的软件组织，并非正在努力将他们软件估算的精度从上下浮动10%提升至上下浮动5%。典型的软件组织正在努力避免100%或更夸张的错误估算。其背后原因林林总总，各不相同，将在第3章和第4章详细阐述。

下面这样的复杂公式总是让人自然而然地产生一种信任：

人们认为，如此复杂的公式总是能比下面这样的简单公式产生更准确的结果：

工作量 = 需求数量 × 平均工作量 / 需求

但是，复杂的公式不一定更好。软件项目受到许多因素的影响，而这些因素会破坏估算科学这些复杂公式中包含的诸多假设。本书后面内容会对这些动态变化进行解释。除此之外，还有一个原因是，大多数软件从业者既没有时间也没有兴趣去学习必要的大量数学知识来充分理解估算科学。

因此，本书更关注经验法则、流程规则和简单公式，这些对于实践中的软件专业人员来说是易于理解和立竿见影的。这些技术不会帮你的项目产生±5%的准确估算，但有助于把估算误差减少到25%或更少，而这一结果正是现实中大多数项目所需要的。不管怎样，我把这些技术称为“估算的艺术”。

这本书借鉴了关于软件估算的艺术性和科学性研究，但是本书的侧重点还是放在软件估算艺术之上。

本书的目的和目标读者

关于软件估算的文献相当地分散。研究人员已经发表了数百篇相关文章，其中不乏诸多有用的篇章。但是，典型的软件从业人员并没有时间从默默无闻的技术期刊中大海捞针地找到几十篇有用的论文。有一些以前的书籍描述了估算的科学。但这些书通常长达800～1000页，需要读者有深厚的数学背景，而且这些书籍的主要目标读者是专业估算人员，即经常估算大型项目的顾问或专家。

我为软件开发人员、团队负责人、测试人员和管理人员写了这本书。这些人的日常工作职责之一，就是时不时地需要为项目创建软件估算。我相信大多数实践者有意愿想要提高他们估算的准确性，但却没有时间去攻读一个软件估算的博士学位。这些实践者努力挣扎在解决实际问题的线，在工作中经常困扰他们的是如何合理展示估算结果以被他人接受，如何尽力避免他人武断专制地篡改估算结果。如果你也属于这样一类人，那么这本书就是为你而写的。

本书中的技术广泛适用于互联网和内联网开发、嵌入式软件、零售商业软件、商业系统软件、全新开发项目、基于旧系统的开发、大型项目和小型项目，本质上来说，适用于各种软件的估算。

本书亮点

聚焦于估算的艺术，本书提供了许多关于估算的真知灼见。

?什么是估算？你可能认为自己早就知道什么是估算，但是一些针对这个术语的不准确用法会损害有效的估算。

?导致以往估算不准的具体因素。

?甄别好的估算方法和坏的估算方法。

?多项技术助力亲手创建良好的估算。

?一些技术，可以用来帮助团队中的其他人创建良好的估算。

?一些方法，组织可以基于它们创建良好的估算。个人技术、团队技术和组织技术之间有较大区别。

?适用于敏捷项目的估算方法以及适用于传统的、串行性（计划驱动的）项目的方法。

?一些适用于小型项目的估算方法，一些适用于大型项目的估算方法。

?在围绕软件估算的强势政治环境中如何进退自如。

除了可以帮助更好地理解估算概念，本书中的实践还将帮助估算软件项目的一些具体参数，如下所述。

?开发全新产品的工作，包括时间进度、工作量和成本。

?在旧系统之上再开发的时间进度、工作量和成本。

?在一个特定的开发迭代中，可以交付多少软件特性。

?当时间进度和团队规模固定时，整个项目可以交付的软件功能数量。

?除软件开发之外，估算其他各种活动的比例，包括需要多少管理工作、需求、构建、测试和缺陷修正活动。

?估算项目规划参数，例如成本和进度之间的权衡、团队规模、应急缓冲区的设置、开发人员与测试人员的比例等。

?估算项目质量参数，包括缺陷修正工作所需的时间，在软件终发布时仍然遗留的缺陷数量，以及其他因素。

?实际工作中想要估算的任何东西。

在许多情况下，本书的实践可以立即运用于实际工作中。

虽然，大多数实践者并不需要更进一步，只需要运用本书中描述的概念就足以改善日常工作中的估算。但如果有个人意愿进一步学习更深奥的数学方法，本书中的概念也能为你继续深入学习铺下坚实的基础。

本书不涉及的内容

这本书并不会讨论如何估算那些规模超级大的项目，比如超过100万行代码，或者超过100个人年的项目。超大项目应该由专业的估算人员进行估算，和一般软件从业者不一样，这些估算行业的佼佼者阅读过数十篇不知名的期刊文章，研究过那些800~1000页的科学巨著，熟悉商业估算软件，并且在估算的艺术和科学方面都游刃有余。

从哪里开始读这本书

从哪里开始读这本书，取决于你想从本书中获得什么。

如果买这本书是因为现在马上就要开始进行估算……推荐从第1章开始，然后转到第7章和第8章。然后，请进一步浏览第10～20章的技巧，找到对你而言立竿见影的技巧。顺便提一句，本书的估算技巧提示在文本中均突出显示并编号，所有技巧（总共118条）也在包含在附录C中。

如果你想提高个人估算技能，或者想提高组织的估算跟踪记录，或者想对软件有一个更深刻的综合理解，推荐你通读整本书。如果你想在深入细节之前先了解通用原则，那就按顺序来阅读这本书。如果想先了解细节，然后从细节中得出一般结论，可以从第1章开始，接着阅读第7章到第23章，然后再回去阅读跳过的前几章。