第八章 估算校准和历史数据

8.1 历史数据可以提高准确度并带来其他益处

1）考虑开发组织的影响

影响项目结果的开发组织的因素主要包括：

• 软件有多复杂、运行时间的限制如何、需要达到怎样的可靠性、需要多少文档、有多少先例可循
• 开发组织可以承诺需求是稳定不变的，还是项目团队必须在整个项目中面对易变的需求？
• 项目经理可以自由地开除有问题的团队成员，还是开发组织的人力资源政策导致剔除有问题的雇员很困难或者根本不可能？
• 团队可以全神贯注于当前的项目，还是他们经常会受到打扰，去为以前项目生产的版本提供支持？
• 开发组织可以按计划给新项目增加团队成员，还是拒绝在其他项目完成之前把人手抽调过来？
• 开发组织是否支持采用有效的设计、构造、质量保证和测试实践？
• 开发组织是否在受管制的环境（例如在FAA或FDA规章限制下）下运作，或者必须进行某些特定的实践？
• 团队成员可以稳定地坚持到项目完成，还是开发组织有很多人员流动的现象？

2）避免主观性和无根据的乐观

主观性对估算产生影响的一种方式是，项目经理或估算人员会把新项目和过去的项目进行比较，发现两个项目之间存在许多差别，于是得出结论说新项目会比旧项目进行得更好。他们说：“在上一个项目中有大量的人员流动。这次不会发生这种情况，所以我们会有更高的生产率。而且，以前大家经常会被叫去为以前的版本提供支持，我们也会保证这次不发生这样的情况。以前还有许多很晚才从市场上获得的需求，这次我们在这方面也会做得更好一些。再加上这次我们要使用更好的技术和更新、更有效的开发方法。有了所有这些改进，我们的生产率应该能提高很多。”

3）减少估算中政策的影响

使用历史数据来校准估算的经理可以完全回避程序员是高于平均水平还是低于平均水平的问题。数据表明的生产率有多少，生产率就是多少。不从事技术工作的干系人是很难对这样的陈述进行争论的：“我们平均每人每月可以交付300~450代码行，所以我们使用每人月400代码行的假设来校准模型。我们相信这一假设略微偏向乐观，但仍然处于谨慎的计划范围内。”

8.2 要收集的数据

如果尚未收集历史数据，可以从很少的一组数据开始收集。

• 规模（代码行或软件交付后可以计数的其他对象）
• 工作量（人月）
• 时间（日历月）
• 缺陷（按照严重性分类）

1）与规模度量有关的问题

对于采用代码行表示的规模，需要对下列问题进行定义

• 是对所有代码进行计数，还是只对交付的软件中包含的代码进行计数？（例如，是否对辅助性代码、mock对象代码、单元测试代码和系统测试代码进行计数）
• 如何对复用以前版本的代码进行计数？
• 如何对开源代码或第三方库代码进行计数？
• 是包括对空行和注释的计数，还是只对非空、非注释代码行进行计数？
• 是否对类接口进行计数？
• 是否对数据声明进行计数？
• 如何对那些在逻辑上是一行代码，但由于可读性原因被分成多行的代码进行计数？

在这个方面并不存在行业标准，而且如何回答这些问题也并不是很重要。重要的是这些问题在不同项目中的答案要保持一致。以便做出的估算能够明确地反映收集数据中包含的假设。

2）与工作量度量有关的问题

收集工作量数据时也有一些类似的方面需要注意：

• 使用小时、天还是其他单位来计数？
• 每天算工作多少个小时？是标准的8小时还是实际用于特定项目的小时数？
• 是否计入无报酬的加班时间？
• 是否计入节日、休假和培训的时间？
• 是否为全公司的会议留出时间？
• 在对哪一种类型的工作进行计数？是测试、基层管理、文档编写、需求、设计还是研究？
• 如何计入多个项目共同使用的时间？
• 如何计入为同一个软件的以前版本提供支持花费的时间？
• 如何计入为销售支持电话、展览会等工作提供支持花费的时间？
• 如何计入旅途中花费的时间？
• 如何计入在完全定义好项目前花费在明确软件概念上的时间，也就是模糊的前期工作时间？

3）与日历时间度量有关的问题

在很多开发组织中，很难确定特定项目会持续多长时间。

• 项目开始于何时？是获得正式预算批准的时候？或者是开始对项目进行初始讨论的时候？还是人群全部到位的时候？
• 项目何时结束？是向客户交付软件的时候？还是将最终备选版本（release candidate）交付测试的时候？

4）与缺陷度量有关的问题

最后，对缺陷的度量值根据被看作缺陷的对象的不同也会出现 2~3 倍的差异

• 是把所有变更请求都当作缺陷，还是只算最终被归类为缺陷而不是功能请求的那些变更请求？
• 对同一个缺陷的多次报告是记为单个缺陷还是多个缺陷？
• 是同时包括开发人员发现的缺陷，还是只包括测试人员发现的缺陷？
• 是否计入系统测试开始之前发现的需求和设计缺陷？
• 是否计入alpha或beta测试前发现的编码缺陷？
• 是否计入软件发布后用户报告的缺陷？

5）其他的数据收集问题

在项目进行过程中最容易收集与之相关的历史数据。如果项目已经完成 6 个月了，就很难回头重构项目的“模糊工作状况”来确定它的开始时间，也很容易忘记到项目结束时大家一共加了多少班。

项目结束后尽早收集它的历史数据

在项目结束的同时收集数据有好处，而收集项目进行过程中的阶段采样结果则更有用。每过1~2周就收集一次与规模、工作量和缺陷相关的数据，这可以让人深入了解项目的动态特性，而这种了解具有很大的价值。

在项目进行过程中周期性地收集历史数据，以便根据这些数据建立项目运行情况概貌

8.3 如何校准

收集数据的最终目的是把数据转换成用于估算的模型。可以建立这样一些模型：

• 每个开发人员平均每月完成 X 行代码；
• 3 个人的团队每个日历月可以交付 X 个用户故事；
• 团队平均每 X 人时可以定义一个用例，每 Y 人时可以构造和交付一个用例；
• 测试人员每 X 小时可以建立一个测试用例；
• 在我们的开发环境中，平均每个功能用途在 C# 中需要 X 行代码，在 Python 中需要 Y 行代码；
• 到目前为止，项目对每个缺陷进行修正平均要花费 X 小时。

这些模型的一个共同特点在于它们都是线性的。无论是在构建10,000代码行的系统中，还是在构建1,000,000代码行的系统时，其数学计算都是一样的。但是由于软件规模不经济现象的影响，某些模型需要根据不同的规模等级进行调整。可以尝试使用非正规的方式来处理规模带来的差异。

8.4 使用项目数据精化估算值

本章早些时候曾经指出，历史数据的用途在于使用它时可以考虑开发组织的影响因素——既包括可见的因素，也包括不可见的因素。同样的观念也适用于在特定项目中对自己历史数据的使用。单个项目的动态特性可能在一定程度上与其所在开发组织的动态特性有所不同。使用来自项目本身的数据可以考虑到项目所特有的影响因素。越早在估算中使用项目本身的数据，就能够越早成为真正准确的估算。

使用当前项目的数据（项目数据）可为项目的剩余部分建立高度准确的估算

8.5 使用行业的平均数据进行校准

如果没有自己的历史数据，就没有多少选择余地，只能使用行业的平均数据。行业数据可以作为估算的基础，但其准确度是很低的。