第21章 管理变更.ppt

1 第21章管理变更 2 需求开发与需求管理的分界 中程在线信息产业培训网 3 需求基线管理 为何需要 频繁的需求变更会破坏开发的节奏 使整个项目开发的进度陷入混乱和失控的状态 而且会变成一个 救火队 式的工作 整天都在处理突发事件 主要思想 将所有现在的 将来的需求进行优先级评估 然后分解成为不同的组 每次迭代都选择其中优先级最高的部分进行开发 然后在迭代完成之前 开发工作不响应变更 这些划入的需求项就是需求基线的组成部分 4 需求基线管理 操作思路 我们应该在分析的基础上 将需求整合成为用例或功能项 然后对其进行优先级 依赖性进行综合性评估优先级判断 业务人员确定业务决定 技术人员确定技术决策 满意度 不满意度 模型依赖性是指对于某些功能 在实现上有必须的依赖关系 即当某些功能没有实现时 另外的功能无法开始 这就需要对其进行调整 5 需求变更管理 需求变更是一定存在的 而需求变更管理并不是指逃避它 更不是说要避免它 它实际上是希望控制变更在基线内的需求不响应变更 为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应 了解需求变更的关键意图 新产生的工作量 从而良好地进行重新计划 以便能够有效地解决其对整个开发带来的麻烦 6 对待软件项目管理的组织必须确保做到以下几点 在提交提议的需求变更之前要对其进行仔细的评估 请合适的人员就需求变更做出周全合理的业务决策 将已批准的变更传达给受此影响的所有人员 项目以一致的方式将需求变更包含进来 采用一致的变更控制方法 就可以避免相关问题 避免开发工作的返工和浪费时间等情况的发生 7 变更控制委员会 变更控制委员会 有时也称为配置控制委员会 configurationcontrolboard CCB 已被证实是软件开发领域公认的最佳实践 McConnell1996 CCB是由人组成的团体 可以由一个小组担任 也可以由多个不同的小组担任 这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现 CCB也决定所报告的缺陷中哪些需要纠正 什么时候纠正 CCB可以评审和批准对项目中任何基线工作产品所做的变更 项目需求文档只是其中的一个样例 8 CCB的组成 CCB的成员应该能代表需要参与制定决策的所有小组 当然这些决策制定只能是在CCB的权力范围之内 可考虑从下面这些部门中选择CCB代表 项目或程序管理部门产品管理或需求分析部门开发部门测试或质量保证部门 市场或客户代表编写用户文档的部门技术支持或帮助部门配置管理部门 9 CCB规章 CCB规章描述了CCB的目的 权力范围 成员构成 运作规程和决策的制定过程等 Sorensen1999 CCB的权力范围规定了哪些决策由CCB决定 哪些决策则必须上报给高一级CCB或者由管理层来决定 1 制定决策决策制定过程的描述应该确定 CCB成员或主要角色的人数 这是制定决策的法定人数 所采用的决策规则是投票 少数服从多数 协商决定或其他方法 10 CCB规章 CCB主席是否可以否决CCB的集体决策 级别高的CCB或其他人是否必须认可CCB做出的决策 2 交流状态CCB做出决策之后 应该指派专人对变更数据库中的变更请求状态进行更新 3 重新协商原先的约定在接受一个重大的需求变更之前 为了适应这一变更 需要同管理部门和客户重新协商原先的约定 Humphrey1997 协商的内容可能包括 要求推迟产品交付时间 要求增派人手 或者要求推迟实现尚未实现的优先级较低的需求等 11 测量变更活动 选择测量方法时应该以您或管理层要回答的问题 以及力图要达到的目标为依据 测量变更活动是评估需求稳定性的一种方法 它也揭示了是否可能通过过程改进来减少以后的变更请求 应该考虑需求变更活动的以下几个方面 Paulketal 1995 接收 未作决定和已结束处理的变更请求的数量 变更的累计数量 包括增加 删除和修改的需求 每个部门所提议的变更请求数 已确定为基线需求后 每个需求中提议的变更和实现的变更的数目 处理和实现变更请求所投入的总工作量 正确实现每一个已批准的变更所经过的变更过程的反复次数 12 变更需要付出代价 影响分析 对软件实施大的功能增强 则需要进行影响分析 impactanalysis 但是 即使是小的变更请求 也可能潜伏着难以预料的复杂性 影响分析是需求管理的一个关键方面 Arnold和Bohner1996 通过对影响进行分析 可以准确地理解提议的变更所涉及到的问题 有助于项目团队就批准哪些提议做出周全合理的业务决策 影响分析通过对所提议的变更进行检查 确定可能必须创建 修改或废弃哪些部分 并估计与实现这些变更相关的工作量 13 影响分析的过程 影响分析有3个方面 1 理解进行变更可能涉及的问题 变更常常会产生大量的连锁反应 产品包括的功能太多会降低其性能 甚至会到令人难以接受的地步 2 确定如果团队将提议的变更包括到产品中 可能必须对哪些文件 模型和文档进行修改 3 确定实现变更所需执行的任务 并估计完成这些任务所需的工作量 注意 跳过影响分析并不能改变任务的规模 只会使规模令人感到惊奇 而软件方面令人惊奇却很少是好消息 14 影响分析报告模板 图是一个推荐的报告模板 表示对每个需求变更造成的潜在影响的分析结果 如果采用标准模板 CCB成员就可以轻松地找到他们所需的信息 作出合理的决策 15 需求的变化是永恒的 因而 对于需求变更应该正确对待 尽量将其负面影响降低 需求变更可能来自解决方案提供商 客户或产品供应商等外部因素 也可能来源于项目组内部 变更都是有代价的 应该评估一下变更的代价及其对项目的影响 在需求变更发生之前尽量减少需求变更 以将需求变更带来的风险降低到最低 切忌在项目设计之前试图消除需求变更 16 有效的需求变更过程 需求变更控制一般要经过变更申请 变更评估 决策 回复这四大步骤 如果变更被接受 还要增加实施变更和验证两个步骤 有时还会有取消变更的步骤 配置管理是管理需求的一个必要方面 基线是软件开发中的里程碑 其标志是有一个或多个软件配置项的交付 且已经经过正式技术评审而获得认可 17 需求变更的原因 因竞争 成本等因素 工期已经确定且极不合理 用户在需求期提不出需求 或用户的需求不明确 项目组对业务不熟悉 或者没有与用户密切结合 需求分析工作不细致 项目组没有很好地实施需求管理 18 需求变更的恶性循环 19 需求变更的因素 20 需求变更的代价 21 减少需求变更 22 需求变更的过程管理 认识到变更不可避免 为变更制订计划 确认需求基线 建立控制变更的唯一渠道 使用变更控制系统来捕获变更 分层次地管理变更 23 变更请求流程 24 分层次的需求变更 25 基于配置管理的需求管理 避免需求在未授权情况下变更 或在有潜在破坏性的情况下不受限制地随意变更 保护队需求文档的修正 方便对文档以前版本的检索或重建 支持系统以增量的方式改进基线 避免对文档的同时更新和冲突 26 基线管理 需求基线 requirementbaseline 是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合 基线 已经通过正式评审和批准的某规约或产品 它可以