读书笔记《敏捷项目管理》第十二章范围与采购管理_项目管理中采购管理和范围管理的关系-CSDN博客

本文链接：https://blog.csdn.net/Shair911/article/details/100143857

在这里插入图片描述

敏捷项目范围管理的不同之处

范围管理
- 产品范围（Product Scope）：一个产品包含的全部特性和需求
- 项目范围（Prodect Scope）：开发一个产品所需要的全部工作
敏捷项目
- 允许变更项目范围
- 项目范围的变更是合理和有益
- 非常支持变更
传统项目与敏捷项目范围管理对比

传统项目范围管理方法	敏捷项目范围管理方法
项目团队试图在项目初期确定并整理出完整的范围，而此时团队对产品知之甚少	在项目初期，你搜集高层次的需求，分解并进一步细化近期需要实现的需求。在整个项目过程中，随着团队对客户需求和项目实际情况认知的提升,需求会逐步集中和完善
组织将需求定义阶段之后的范围变更完全视为负面	在项目进行中，组织认为变更是一种积极的完善产品的方式项目后期的变更往往是最有价值的变更，因为此刻你对产品的理解最深
当干系人确定需求之后，项目经理严格控制并抵制需求更变	变更管理是敏捷过程固有的一个部分每次冲刺期，你可以重新评估范围，并有机会纳入新的需求产品负责人对新需求的重要性和优先级进行评估，并将它们加入产品待办列表（Product Backlog）中
变更成本随着时间不断增加，同时实施变更的能力下降	项目所需的资源和进度在项目初期是固定的具有高优先级的新特性并不一定会对整体预算和进度产生影响，它们只是会排挤最低优先级的特性迭代式开发允许每个冲刺期的变更产生
项目普遍存在范围膨胀（Scope Bloat），即由于担心中期变更而纳入一些不必要的产品特性	你确定范围的依据是产品特性对项目愿景、发布目标和冲刺目标的直接支持程度开发团队优先实现最有价值的特性，并确保包含这些特性的产品尽快交付价值相对较低的特性或许永远不被实现

如何在敏捷项目中管理范围

理解项目范围
- 参考路线图
范围变更概述
- 以下渠道可获得关于产品特性的新想法：
  - 用户社区反馈
  - 遇见新的市场机会或威胁的业务干系人
  - 高管层和资深经理
  - 开发团队
  - Scrum 主管
  - 产品负责人
管理范围变更
- 询问需求的关键问题，来评估新需求是否属于项目、发布或者冲刺中的一部分
  - a. 新需求是否与产品愿景相符？
    - 是：加入【产品待办列表】和【产品路线图】
    - 否：备选为一个单项的项目
  - b.新需求是否与当前的发布目标相符？
    - 是：可作为当前【发布计划】的备选需求
    - 否：留在【产品待办列表】，由后续版本实现
  - c.新需求是否与当前冲刺目标相符？
    - 是：且冲刺尚未开始，可加入当前【冲刺待办列表】
    - 否：留在【产品待办列表】，由后续版本实现
- 评估新需求的工作量
  - 开发团队负责此项工作
- 新需求和产品待办列表比较优先级，根据优先级，将其加入产品待办列表
敏捷工件在范围管理中的角色

工件	确立范围时的角色	范围变更时的角色
愿景声明：产品最终目标的定义	以愿景声明为基准，判断哪些特性应纳入当前项目的范围	当有人提出了新的需求，哪些需求必须与项目愿景声明相符
产品路线图：构成产品愿景的产品特性的整体视图	产品范围是产品路线图的组成部分。这种特性级的需求有助于业务会谈中阐述实现产品愿景的意义	当新需求出现时，请及时更新产品路线图。它形象地展示了新需求在项目中被采纳的过程
发布计划：一个易达到的中期目标，包含最小的可上市的特性集	发布计划包含了当前发布的范围。你或许希望按主题（需求的逻辑分组）来规划你的发布	将属于当前发布的新特性加入到发布计划中。如果新的用户故事并不属于当前发布，那么就可以将其留在产品待办列表中，后续发布处理
产品待办列表：关于所有产品的已知需求的完整清单	如果一个需求在范围中，它就会被登记在产品待办列表中	产品待办列表包含了所有的范围变更。在产品待办列表上，新的、高优先级的特性会使得那些原本优先级相对较低的特性的排序继续降低
冲刺待办列表：当前冲刺范围内的用户故事和工作任务	冲刺待办列表包含了当前冲刺范围内的用户故事	冲刺待办列表确定了冲刺所认可的范围。当开发团队在冲刺计划会议上承诺了冲刺目标后，只有他们才可以修改冲刺待办列表

敏捷项目采购管理的不同之处

传统采购管理与敏捷项目采购管理的对比

采用传统方法的采购管理	采用敏捷方法的采购管理
项目经理和组织对采购过程负责	自管理开发团队在确定采购清单的过程中扮演更重要的角色
与服务供应商签订的合同常常要求提供确定的需求、详实的文档、全方位的项目计划和基于瀑布型生命周期的其他传统的可交付成果	敏捷项目的合同关注每次冲刺结束后对可工作产品功能的评估，而不会依赖那些对交付高质量产品可能并没有贡献的固定的交付成果和文档
买卖双方间的合同谈判有时极具挑战性。谈判活动常常是很紧张的，甚至在项目启动前就可以损害买卖双方间的关系	从采购过程开始起，敏捷项目团队就专注于维护买卖双方间积极的合作关系
因为新的供应商必须设法理解上一家供应商大量尚未完工的工作，所以在项目启动后更换供应商会消耗大量成本和时间	供应商在每次冲刺结束后提供完整的、可工作的功能。如果供应商在项目中期变更，新的供应商可以立即为下一次冲刺开发需求，从而避免了漫长且昂贵的过渡过程