PMI PMP: 敏捷、Scrum 与混合交付 — 学习指南

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

属于 PMP — 学习指南. 使用经过验证的答案练习： PMI 考试中心, 或参加限时模拟考试： ExamRoll.io.

Scrum 角色、仪式与工件

Scrum 之所以刻意采用精简的角色结构，是因为责任分散是复杂交付项目的主要失败模式之一。产品负责人 (Product Owner) 负责做什么和为什么做：他们定义价值、排定待办列表的优先级，并持有接受或拒绝增量的权力。Scrum Master 负责流程如何顺利运行：他们是一位服务型领导，负责移除障碍、指导敏捷实践，并保护团队免受干扰。开发人员 (Developers)（指整个交付团队，不仅仅是编码人员）负责如何做：他们自组织地将待办列表项在每个 Sprint 中转化为可工作的增量。

这些角色必须由真实、投入的人来担任。一个不投入或缺席的产品负责人是敏捷交付中最具破坏性的模式之一——没有他们实时的优先级排序和验收，Sprint 评审会就会沦为状态汇报会议，而非价值验证活动，反馈循环被拉长，团队也会逐渐偏离方向，开始构建错误的东西。当面对一个缺席的 PO 时，正确的做法是向项目发起人汇报升级，并重新确立该角色的职责，而不是让 Scrum Master 永久性地代理决策。

核心仪式构成了一个闭环的反馈循环：

• Sprint 规划会议 (Sprint Planning)
  • 目的：协商 Sprint 目标和预测交付内容
  • 频率：Sprint 开始时
  • 主要产出物：Sprint 待办列表
• 每日站会 (Daily Standup)
  • 目的：同步进度、发现障碍
  • 频率：每日，限时 15 分钟
  • 主要产出物：当日调整后的计划
• Sprint 评审会议 (Sprint Review)
  • 目的：与干系人一同检视增量
  • 频率：Sprint 结束时
  • 主要产出物：反馈、更新后的产品待办列表
• Sprint 回顾会议 (Sprint Retrospective)
  • 目的：检视流程本身
  • 频率：Sprint 结束时
  • 主要产出物：具体的改进措施

各项工件——产品待办列表 (Product Backlog)、Sprint 待办列表 (Sprint Backlog) 和增量 (Increment)——都各自附有一个承诺：分别是产品目标、Sprint 目标和完成的定义。正是这些承诺，防止了 Scrum 沦为“迭代式瀑布开发”。

待办列表管理和用户故事

产品待办列表是一个动态的、有序的列表——而不是一份在项目开始时就冻结的规格说明书。产品负责人与团队协作维护它，不断对列表项进行优化，以确保待办列表顶部的任务是小型的、被充分理解的、并且是随时可以拉取去做的。一个常见的节奏是，在每个 Sprint 中花费团队 5-10% 的精力进行待办列表梳理 (backlog refinement)。

用户故事遵循我们熟悉的格式：作为一名 [角色]，我想要 [功能]，以便 [获益]。获益部分和功能部分同等重要——它让团队能够提出替代解决方案，也让 PO 在优先级变化时能够决定这个故事是否还值得做。

验收标准 (Acceptance criteria) 是 PO 用来接受一个故事的可观察、可测试的条件。它们与“完成的定义”不同：验收标准是针对特定故事的（例如，登录界面在五次失败尝试后是否锁定？），而“完成的定义”是对每个故事都通用的（例如，它是否经过了代码审查、测试、文档化、并部署到预发布环境？）。

当一个干系人在项目中途提出新的需求时——即使这个需求与之前的工作很相似——PO 也不应该脱口而出给出一个交付日期。正确的响应是，将该请求作为一个候选的待办列表项记录下来，与团队一起估算其大小（也许可以使用参考故事作为相对估算的锚点），然后根据它相对于现有项目的价值将其放入待办列表。以往的相似性可以加速估算，但不能绕过优先级排序的讨论。

DoR、DoD 与迭代规划

就绪的定义 (Definition of Ready) 是进入 Sprint 的一道准入门槛。一个故事在满足以下条件时才算就绪：它足够小，可以在一个 Sprint 内完成；有清晰的验收标准；已识别出已知的依赖项；并且团队已经理解它。强制执行 DoR 可以防止团队拉取那些不成熟的工作，避免这些工作在 Sprint 中期因问题悬而未决而停滞。

完成的定义 (Definition of Done) 是完成工作的产出门槛。它是共享的、不可协商的清单，它将“我们完成了编码”转变为“这是一个潜在可交付的增量”。一个健全的 DoD 通常包括：自动化测试通过、代码已审查、安全扫描无问题、文档已更新，以及——至关重要的是——满足了性能和可观测性等非功能性需求。让运维和 QA 参与定义 DoD，可以防止出现增量在 Sprint 评审中“看起来能用”，但在生产环境的真实负载下崩溃的模式。如果在 Sprint 结束后，运维人员提出了性能问题，并且相关数据已存在于日志中，成熟的响应方式是，将该问题带入待办列表梳理会议，将性能阈值添加到 DoD 中，并创建新的待办列表项来弥补这一差距——而不是以“不在范围内”为由将其驳回。

MVP、发布规划与增量交付

最小可行产品 (Minimum Viable Product) 是能让团队用真实用户来检验一个关键假设的最小连贯功能集。其目的是学习，而不仅仅是交付。发布规划则在此基础上进行：给定一个由 MVP 和后续增量版本组成的路线图，团队以速率 (velocity) 为大致指导，预测哪些功能将在哪个版本中落地。

增量交付为组织赢得了选择权——即基于证据而非观点来改变方向的能力。敏捷方法专门设计用来防止那种在向用户展示任何东西之前，一直等待一个“完整”版本发布的反模式。

估算、故事点和速率

故事点衡量的是相对工作量、复杂度和不确定性，而不是持续时间。对于某个特定团队而言，一个 5 点的故事大约是一个 1 点的故事的五倍工作量。速率（每个 sprint 完成的点数）是在几个 sprint 中根据经验得出的，用于预测范围，而不是做出日历承诺。

将故事点视为固定的天数是一个严重的陷阱，原因有几个。首先，它破坏了抽象性：如果 1 点 = 1 天，团队就会直接用天数进行估算，并通过虚报来满足截止日期。其次，它消除了不确定性信号——一个 13 点的故事不仅仅是“耗时长”，它还具有风险，而这种风险应该触发任务分解。第三，它让管理层可以把数字武器化（“你们说了 40 点，为什么只完成了 32 点？”），这会驱动团队产生“藏一手”的行为。正确的用法是：速率趋势 + backlog 大小 → 概率性发布预测，并以范围的形式进行沟通。

管理障碍、中断和工作流

Scrum Master 最具体的工作就是移除障碍。当团队成员默默挣扎时——也许是太骄傲或太新手而不敢提出——团队负责人应该直接介入，了解障碍，并帮助解决或上报。忽视每日站会的目的会让这种模式恶化；不稳定的站会出席率会造成知识孤岛、隐藏阻塞问题，并让小问题演变成进度风险。出席是不可协商的，因为这个仪式的价值在于同步信息，而不是报告状态。

临时中断——那些绕过 backlog 的“紧急”请求——同样具有腐蚀性。它们会侵蚀 sprint 目标，使预测失效，并让利益相关者觉得这个流程是可以被绕过的。正确的处理方式是将新请求引导给 PO，由 PO 决定它们是否值得取消当前 sprint（很少见）或应放入未来的 sprint（通常情况）。

对于测试或其他专业领域成为瓶颈的混合团队，通过看板 (Kanban boards) 和燃尽图/燃起图 (burndown/burnup charts) 进行工作流可视化可以暴露这个限制因素。如果团队发现某个工具可以解决测试瓶颈，项目经理不应单方面批准或拒绝——他们应该协同评估该提议，检查组织治理（采购、安全），与 PO 沟通对 backlog 的影响，然后再做决定。条件反射式的批准跳过了尽职调查；条件反射式的拒绝则忽视了团队的专业知识。

回顾会议与持续改进

回顾会议形成了闭环。一次好的回顾会议会产生一到两个具体的、有负责人跟进的改进项——而不是一个发泄会。尽早将运维和 QA 人员带入回顾会议，可以防止典型的交接失败，即团队只为 sprint 结束时的演示进行优化，而不考虑生产环境的实际情况。持续改进是确保速率真实、完成的定义（DoD）有意义、以及在产品整个生命周期中保持团队高度敬业的机制。

实践问题：用例场景

场景： Priya Nair 是一家金融科技公司的“LumenPay”移动钱包团队的 Scrum Master。该团队以两周为一个 sprint 周期，成员包括六名开发人员、一名 QA 工程师和一名 UX 设计师。在过去的三个 sprint 中，产品负责人 (Product Owner) Marcus Reeves 以其零售合作伙伴关系主管的职责冲突为由，只参加了一次 sprint 计划会议，且没有参加任何 sprint 评审会议。来自合规和欺诈运营部门的利益相关者已开始直接通过电子邮件向开发人员发送优先级冲突的请求。在过去的两个 sprint 中，团队在总共 82 个故事点中遗留了 34 个。项目发起人，即产品副总裁 Anita Chen，开始质疑团队的速率。

挑战： Priya 必须在不越过其服务型领导的角色（即自己做出产品决策）的前提下，恢复产品负责人的参与度，并阻止 backlog 的碎片化。

推荐方法：

1. 记录过去三个 sprint 中 PO 缺席造成的具体影响——遗留的故事点、模糊的验收标准、未解决的 backlog 项目，以及绕过 PO 的直接利益相关者请求数量——以建立一个基于事实的论据。
2. 首先与 Marcus 进行一对一沟通，分享数据并直接询问他是否能投入该角色每周所需的 10-15 小时，或者该角色是否需要被重新分配或拆分。
3. 将记录的证据正式上报给 Anita Chen，并提出两个选择：将 PO 角色重新分配给有精力的人，或者协商减少 Marcus 在零售合作伙伴关系方面的职责。
4. 指导开发团队将所有来自利益相关者的请求重定向到 product backlog，而不是临时接受它们，并强调只有 PO 才能重新排定优先级。
5. 一旦确认了能投入精力的 PO，就举办一次 backlog 梳理工作坊，以重新确定优先级基线、清理验收标准，并为下一次迭代重设 sprint 目标。
6. 建立一份工作协议，明确规定 PO 必须出席计划会议、评审会议以及每个 sprint 至少两次的梳理会议。

为何这样有效： 将此职位空缺问题上报给发起人可以保持角色完整性——Scrum Master 绝不能成为代理产品负责人，因为这会永久性地掩盖组织问题，并损害基于价值的优先级排序。将上报内容建立在具体指标上，可以使谈话聚焦于交付成果而非个人问题，而将利益相关者的请求重新引导至 backlog 则恢复了 Scrum 所依赖的单一事实来源原则。

← 团队领导力与资源管理 · 所有领域 · 范围、需求与变更控制 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →