需求基线管理是需求管理活动中基础的一个,《软件需求佳实践》中有所阐述,结合实际工作梳理一下。 什么是“需求基线”?在某个特定版本中实现的功能性和非功能性的一组需求集合。引入需求基线后,意味着要采用分阶段或迭代的开发方式。这和敏捷开发中“风险前移”、“分阶段交付”、“小步快走”、“中途回顾”等理念是相契合的。 需求基线,通俗点说是把这些需求都划一根“线”,说明这些需求已经确定下来,添加新的需求和修改原有的需求都必须通过需求变更流程来操作。目的是为了防止需求的滥变给程序架构造成重大影响。 需求项划分应以业务驱动划分标准,因为业务主题,业务流程和业务活动相对于具体的软件需求而言是稳定的。划定基线应采用“早基线,晚冻结”的方式,具体细节可以在迭代中逐步完善。 『写需求基线』这个说法不恰当,需求基线不是写出来的,而是在需求规格说明书评审通过以后所形成的,具体的步骤是开发人员先完成需求规格说明书的写作,然后组织相关人员对需求进行评审,在评审通过以后纳入到配置库进行管理,形成需求基线。 动态文档:早基线,晚冻结 早基线:为了迟早启动开发,基线计划越早越好。 晚冻结:把文档看成是动态,并准备随时更改。 需求项优先级评定 优先级应先从业务角度划分优先级,要把它放到业务场景和业务流程中考虑。一般可分以下四级:关键需求项、重要需求项、有用需求项和一般需求项。 接下来要根据“技术可实现性”和“项目风险因素”角度考虑,对优先级进行调整。记住,在任何时候识别和处理风险都是重要的! 优先级是相对的,需要在同一级中两两进行比较,终结果是每个需求项有确定的序号。这对在今后在资源受,是取舍任务范围的重要依据。 工作量估算 估算是一种手段,而不是目标,我们追求的是管理的可控性,而不是估算结果的准确性。 不同阶段的估算误差是不一样的,但随之开发的深入,估算值将越来越趋近实际值。 需求定义阶段应安排一次估算,其结果比较粗糙。 需求分析阶段应再安排一次估算,此阶段的估算结果是划定基线、安排迭代计划的基础。 每次迭代开发完成后要填充实际进度数据,根据他调整估算值。 估算的核心思想可以归纳为“寻找计数单元,考虑复杂因子”两个步骤。 不同的开发阶段采用不同的计算单元,比如在定义阶段可以采用“业务事件”、“报表类型”和“接口”作为计算单元。 具体估算时,一是分类型进行估算,二是基于权重进行估算。 管理基线 在安排进度计划时,需要关注以下一些关键点: 划定基线时,优先级越高的需求项应放在较早的安排; 若一个需求项估算量过大,比如超过了3个“迭代人日”,必须进一步拆分需求项; 当开发人员人数较多,比如超过5个时,为了便于开发管理要划分多个开发小组,这时划分任务时要考虑人员分组的因素; 落到实地的进度计划,为了提高准确度要考虑人员产能系数的因素,可以根据其工作年限、工资水平或者人员等级水平等作为产能系数的依据; 在践行进度计划时要关注需求变更(单独一个主题)和迭代未完成任务。这两个因素会对已制定基线产生影响,需要在开发过程中动态调整需求基线,这和“中途回顾”的良好习惯相契合。