6.1 选择估算方法时考虑的问题
1）估算内容
某些项目会先确定它们要实现的特性，然后集中注意力来估算为了交付这些特性需要多少时间和工作量。而有些项目则是先确定它们的预算和开发时间限制，然后集中注意力来估算在这些限制内可以交付多少特性。
许多估算方法可以适用于各种待估算对象；而有些方法则分别更适合于估算项目需要多少工作量、要花多少时间或者可以交付多少功能。
在本书中，对规模（size）的估算是指使用诸如代码行、功能点、用户故事或其他度量单位来估算给定特性集的技术工作的范围。对特性（feature）的估算是指估算在时间进度和预算限制内能够交付多少特性。这些术语并不是行业标准；在这里定义它们是为了让本书更为清楚。
2）项目规模
小型：不超过5个技术人员，最佳估算方法更多的是 "自底向上" 的方法，也就是基于将要实际进行工作的个人提供的估算值来进行估算
大型：大约 25 个以上的团队人员，项目工作将持续 6~12 个月以上。
大型项目的最佳估算方法在项目过程中会发生显著的变化。在项目早期，最佳估算方法可能是基于数学和统计学的“自顶向下”的方法。在尚不知道团队中将有哪些特定成员的时候，这些方法是有效的——例如在根据由“11名高级工程师、25名开发人员和8名测试人员”而不是特定个体组成的团队来制定计划的时候。
在项目中期，把自顶向下的方法和基于项目自身历史数据的自底向上的方法结合起来，可以产生最准确的估算。在大型项目的后期，自底向上的方法可以提供最准确的估算。
中型：大约包括 5~25 个人，持续时间为 3~12 个月。它们的优势在于几乎可以使用大型项目可用使用的所有估算方法，也可以使用几种小型项目能够使用的方法。
3）软件开发方式
对估算而言，开发方式主要可分为两种，分别是顺序开发和迭代开发。对本书而言，这些项目类型之间的主要区别在于它们在项目早期定义的需求在与项目构造过程中定义的需求的比例的高低。
下面，根据这些原则对一些常见开发方法进行了分类。
- 演进式原型法：在需求未知时可以使用演进式原型法
- 极限编程：极限编程有意地只定义将在接下来的一次迭代中实现的需求，而迭代的时间通常不会超过 1个月
- 演进式交付：演进式交付项目先期定义的需求可以少到 "几乎没有"，也可以多到 "几乎全部"。大部分演进式交付项目在开始构造时都会流出许多需求不定义，使得这种开发方式通常都以迭代方式进行
- 分阶段交付：分阶段交付试图在构造活动主体开始前定义需求的主体。该方法在设计、构造和测试中使用迭代方式
- Rational 统一过程（RUP）：典型的RUP项目会寻求在构造活动开始之前定义大约 80% 的需求
- Scrum：项目团队每次处理一组在30天的 "冲刺" 中实现的特性。一旦开始冲刺，就不再允许客户改变需求
开放方式对估算方法选择的影响：迭代式项目和顺序式项目都可能开始于自顶向下的或者说基于统计学的估算方法，最后都迁移到自底向上的方法。由于迭代式项目的每次迭代都可以产生实际的生产率数据，所以在使用项目相应的数据时，它们可以更快地对估算结果进行精化。
4）开发阶段
随着团队在项目中的工作进展，会逐渐产生可以支持更准确估算的信息。对需求的理解会更准确、设计会更详细、计划会更牢靠，项目本身也会产生生产率数据，可以用于估算项目的剩余部分。
本书将开发阶段定义为：
- 早期 在顺序式项目中，早期阶段是指从项目概念起始到需求定义基本完成的时期。在迭代式项目中，早期指的是初始计划时期。
- 中期 中期阶段是指从初始计划到早期构造的时间。在顺序式项目中，它覆盖了需求工作和架构工作，直到完成足够的构造活动，产生了可以用于估算的项目生产率数据。在迭代式项目中，中期是指最初的2~4次迭代——也就是项目可以放心地使用自身的生产率数据建立估算之前的几次迭代。
- 后期 后期包括从中期构造直到项目发布的时间。
5）可能的准确度
估算方法的准确度取决于三个方面。其一是方法本身；其二是该方法是否被应用于适当的估算问题；最后是该方法被应用于项目的哪个阶段
6.2 估算方法适用性表
| 表格条目 | 可能条目 |
|---|---|
| 估算对象 | 规模、工作量、进度、特性 |
| 项目规模 | 小、中、大 |
| 开发阶段 | 早期、中期、后期 |
| 迭代式或顺序式 | 迭代式、顺序式或两者皆可 |
| 可能的准确度 | 低、中、高 |
