P3-S1-需求管理策略与操作实务要点.pptVIP

需求管理策略与操作实务 基线管理Agenda 需求基线的源起与意义 为何需要：频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件 需求基线是实现里程碑管理的关键 需求基线是迭代开发的基础 典型的变更数量是每月1%~4%，但超过2%，“需求搅拌(churn)”现象就将成为最严重的风险 迭代开发的核心理念 以细小的、可管理的步骤开发软件产品：计划一小步，说明、设计和实现一小步，集成、测试和运行一小步 迭代是一次袖珍项目，采用是的瀑布模型开发方法 迭代不是任意的探路、不是只影响开发人员、不是不可预见的 迭代方法是业务优先级驱动的 需求管理项的关系 基线管理Agenda 基线管理的要点 Backlog中的需求组织方法 从Backlog中选取Baseline的方法?优先级 ?估算 ?项目中调整 其他：打破Baseline的时机 需求基线管理--操作思路 基础工作一：估算 估算的核心是找到计数点，再考虑复杂因子 不同阶段将采用不同的的计数点 估算应该是基于权重的 迭代结束时，其进度数据就是调整估算的基础，也是划定新Baseline的基础。 迭代内可以将估算和设计结合 估算演示 针对每个主题域进行 选择一个做为单位1，其他按权重进行估算 第一阶段估算 第二阶段估算 基础工作二：优先级 优先级是相对的，要在同一级中进行比较 优先级划分的三个角度：?BA/RA：业务重要性?Dev：技术依赖性 ?PM：风险 业务优先级的判断方法?满意度/不满意度模型?百元测试法?投票法 基础工作二：优先级 基于业务重要性划分优先级的基本原则?先找到最关键的业务事件，将其必备的业务活动(用例)标识为关键用例?再从剩下的业务事件中找到最重要的，将其必备的业务活动标识为重要用例?再从剩下的业务事件中找到有用的，将其必备的业务活动标识为有用用例?其他的业务事件中的所有用例都划为一般的?再将以上各个业务事件中非必备的业务活动分配到相应的优先级中 基线划分演示 先将Backlog中的任务分成四个等级 根据依赖关系和风险进行调整 然后根据工作量逐渐从高取到低 基线划分演示 基线管理Agenda 需求变更管理：核心思想 变更管理是目标是控制变更，而非避免变更 控制变更的目标是减少变更的影响，而达成这一目标需要由所有团队协作 需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计来减少变更的影响” 建立统一的渠道让客户意识到变更的成本，减少“来路不正”的变更，记录“变更的工作” 采用统一的平台来捕获、管理、控制变更是重要的最佳实践 CCB 造成混乱的多对多 变更控制委会员(CCB) CCB是业界的最佳实践，可以由一个小组或多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用 负责对项目中任何基线工作产品的变更做出决定 CCB的组成： 项目管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 市场或客户代表 用户文档部门 技术支持部门 配置管理部门 变更影响分析要点 选择正确的人进行评价 考虑业务影响度?对项目目标的价值贡献?影响的范围 考虑技术影响度 变更应及时通知所有涉及的人员 变更影响分析要点 业务影响分析：从业务角度对变更的合理性、优先级以及对原有需求的影响进行分析，以便决定是否将其纳入Backlog中；如果决定将其纳入Backlog，还需要确定其优先级。 技术影响分析：从技术角度对变更的影响范围、工作量进行分析，并且决定是拒绝、在后续迭代中进行响应，还是在本次迭代中对其进行响应。 项目影响分析：基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大的影响。 统一的变更管理平台 BugFree到 ClearQuest … 对变更进行分类是关键 变更管理与基线管理 变更通常是不打破基线的，而且从理论上是永远不打破基线的 这样就为变更影响分析赢得更多的时间，也能够更合合理、全面地进行评估 打破基线的情况通常是出现了影响生产的需求，或者对前面的假设产生了巨大影响的 基线管理Agenda 需求跟踪的基本概念 跟踪能力（联系）链使你能够跟踪一个需求使用期限的全过程 四类需求跟踪能力链 ? 需求跟踪是需求管理的高级内容 为什么要需求跟踪 审核：跟踪能力信息可帮助审核确保所有需求被应用 变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响 的系统元素 维护：可靠的跟踪能力信息使得维护时能够正确、完整地