需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。

9.1 需求基线的理念与策略

《软件需求》一书中需求基线的定义：团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合，RUP中基线的定义是：逐项列举的在应用程序的某个特定版本中提交的特征和需求集合。从这两个观点来看，有两个重点内容：特定版本，一组需求集合。

9.1.1 基线思想的起源

基线就意味着分阶段或迭代开发，基线实际上就是为每次迭代的开发工作定义的任务集(也就是需求集)。

》分阶段开发和迭代开发是有区别的。分阶段开发的每个阶段的时间是不确定的，而且通常比较长，而迭代开发则是将项目切分成固定大小的时间盒，使项目分解成了多个微型项目。

》分阶段开发，每个阶段的结束时间不是固定的，必须将相应的内容开发完成后才结束，另外每个阶段内通常都是相应变更的。这样实际上只是将一个“大混沌”切成了几个“小混沌”。

》迭代开发中，每次迭代的结束时间是固定的，没有完成的任务将会放到下次迭代，每次迭代内通常是不相应变更的。

也就是说迭代的细小的，可管理的开发：计划一小步，说明设计和实现一小步，集成，测试一小步。每次迭代都是一个袖珍项目，迭代方法是业务优先级驱动的。

由此我们就能理解在分阶段开发下的一些现象：频繁的变更对开发节奏的破坏，导致开发团队的进度陷入混乱和失控，团队就像救火队，整天都在处理突发事件。在开发的中后期开发效率大幅下降，因为团队总处于“非计划”状态。

9.1.2 基线的策略

》在需求领域，应该以业务驱动

因为子系统是未知的，而业务主题域是已知的；功能模块是很难确定的，但业务流程，管理控制点却是能够标识的；功能子模块是变化莫测的，但业务活动(用例，场景)缺失可以发现的；

》基线划分的时机 有两种观点

    × 划定基线必须在需求细节都填充完整之后。(感觉CMI和善为，都是这种做法，但是博彦的测试体系不是，毕竟通过CMMI5的企业还是不一样，在FW测试领域或许还有HP指导。)

    × 在需求被标识出来后，就可以划定基线了，称为“早基线，晚冻结”(微软的MSF开发框架如此总结)。也就是先将需求项放到基线内，其细节可以在迭代中填充。这种方法在具体操作时比较实用，之后书里的演示将基于这种方法。

    × 如果在需求开发过程中使用的SERU框架，笔者建议在“需求分析与建模的一阶段”完成时，开始划定基线：首先将所有需求项以树形结构整理出来，然后针对每个需求项进行优先级评估，工作量评估，最后在此基础上完成基线的划定。

9.2 基线划定的基础：优先级评价

在评价优先级之前，我们需要将所有需求都组织成一个树形结构(实际上就是WBS)，然后根据以下步骤进行优先级判断：

》业务优先级

》技术依赖性，项目风险判断。

9.2.1 组织需求项

9.2.2 业务优先级判断

对于每个主题域，建议将所有需求项划分为关键，重要，有用，一般，还可以考虑增加一个镀金等级。

》在做业务优先级判断时，依次标记关键，重要，有用，一般和镀金，不要按需求项逐个标记。

》 优先级是相对的，调整和讨论时，需要在同一级中比较。

》评价具体功能点的优先级时，应将其放到业务场景甚至业务流程环境中考虑。

9.3 基线划定的要素：工作量估算

9.3.1 估算的意义与要点

很多人对估算的意义存在误解，实际上估算是一种方法，而不是目标，我们追求的是管理的可控性，而不是估算结果的准确性。

9.3.1.1 何时进行估算

》需求定义完成时。此时的估算结果比较粗糙，结果可以作为立项的参考。(快速软件开发中，反对直接使用精确的估算值作为估算结果，可以选用其他多种方式来表达，比如范围值，比如估算值加减偏差等。)

》需求分析的一阶段。此时需求已经细化到用例级别，可以得到更精准的估算了。这个阶段的估算结果，将是划定基线，安排迭代计划的基础。

》每次开发迭代完成后，应该进行实际进度数据填充，并根据它调整估算值，调整迭代计算。

9.3.1.2 估算的核心思想

估算实际上就是两个步骤：寻找计数单元，考虑复杂因子。

(对于估算，我倾向于使用PMP中提供的几种工具：专家判断，三点估算，参数估算等，如果需求还处于较模糊的阶段，我觉得可以使用Scrum里的dog point进行估算。)

(从我带的项目来看，大部分没有经过训练的程序员，是排斥自己做估算的，他们宁愿接受别人给他们做任务估算。除了前面谈到对估算意义的误解之外，我想“害怕付责任”也是一个很大的因素。他们害怕给出估算后，却无法在估算量内完成，给自己和项目组带来麻烦。)

9.3.1.3 建议的估算操作要点

》分部分，分类型估算

在比较不同部分，不同类型的需求项时，很难保持客观的标准。因此，估算时对每个主题域应该分开估算，对于每个主题域下相同类型的需求项也可以对比估算。

》采用基于权重的估算方法(类似scrum里的dog point)

9.4 基线划定与管理

9.4.1 划定基线

在划定基线时需要注意一些实际问题，比如安排3个人，5周的迭代，并不一定能完成15个人周的标准工作量，因为每个人的产能是不一样的。因此，建议把这个因素剥离开，为每个开发人员维护产能系数表。

9.4.2 管理基线

在项目开发过程中，有两个重要的变化因素，会对预先的计划产生破坏：

》需求变更：在整个开发过程中，需求都会发生变化；这些变化应该更新到BackLog中，不应该直接影响基线。对于变更的处理，可以参阅第十章 变更管理操作实务。

》迭代过程未完成：从项目管理的角度，不希望每次迭代结束时还有未完成的任务，但从需求管理的角度，这种现象又必须要处理。

基于以上两个现象，每次基线的制定都应该是动态的。

9.5 小结

谈到基线，总会想起“抛弃Work Down，迎接Value Add”，也就是说，对于整个项目而言，我们很难将需要完成的任务完整的列下来，然后一个个地去Work Down，基于这点，我们将通过一次次迭代，为客户实现Value Add。