08 进度管理

08 进度管理

2026-06-25 新建

4-42 如何防止范围蔓延

核心定义

范围蔓延（Scope Creep）：未经控制的项目范围扩大，表现为需求不断增加、功能持续叠加，导致进度延迟、成本超支。

范围蔓延的常见原因

预防范围蔓延的五大策略

┌─────────────────────────────────────────────────────┐ │ 1. 清晰的范围说明书（明确边界） │ │ 2. 完善的WBS（100%原则，不遗漏不多做） │ │ 3. 严格的变更控制流程（4.6整体变更控制） │ │ 4. 定期范围核实（5.5确认范围，阶段验收） │ │ 5. 干系人参与和沟通（让所有人知道边界在哪） │ └─────────────────────────────────────────────────────┘

⚡关键认知：范围蔓延不是客户"坏"，而是PM没守住边界。好的PM会说"可以，但需要评估影响后走变更流程"。

4-43 范围蔓延该怎么办

已发生蔓延的应对步骤

考试应对策略

情景题套路：客户/发起人要求增加功能，PM应该？

• ❌ 直接拒绝 → 影响关系
• ❌ 直接答应 → 范围蔓延
• ✅ “我理解这个需求，让我先评估对范围/进度/成本的影响，然后提交变更请求给CCB审批”

4-44 滚动式开发

核心定义

滚动式规划（Rolling Wave Planning）：对近期工作详细规划，对远期工作粗略规划，随项目推进逐步细化。

滚动式规划的特点

时间轴 ────────────────────────────────────────────────► 近期（当前迭代） 中期（下几个迭代） 远期（后续阶段） ┌─────────────────┬──────────────────┬──────────────────┐ │ 详细规划 │ 粗略规划 │ 方向性规划 │ │ 工作包分解 │ 控制账户层面 │ 里程碑级别 │ │ 资源/日期确定 │ 估算范围 │ 大致时间窗口 │ └─────────────────┴──────────────────┴──────────────────┘ 详细 ◄──────────────────────────────────────── 粗略

适用场景

与规划包的关系

• 规划包（Planning Package）：控制账户下暂未分解的工作
• 滚动式规划：把规划包逐步细化为工作包的过程

⚡高频考点：滚动式规划≠没有计划，而是渐进明细的计划。规划包在WBS中，但不是工作包，等工作内容明确了再分解。

4-45 紧前关系绘图法（PDM）

核心定义

PDM（Precedence Diagramming Method）：用节点表示活动，用箭线表示逻辑关系，绘制项目进度网络图。

四种依赖关系

⚡最高频考点：FS 最常用（占90%+），SF 几乎不用。

PDM 图示

┌───┐ ┌───┐ ┌───┐ │ A │──────────│ B │──────────│ C │ └───┘ FS └───┘ FS └───┘ ┌───┐ ┌───┐ │ D │══════════│ E │ SS（同时开始） └───┘ └───┘ ┌───┐ │ F │══════════┐ └───┘ ▼ ┌───┐ │ G │ FF（同时完成） └───┘

4-46 滞后量和提前量

核心定义

滞后量（Lag）

混凝土浇筑 ──────── 等待28天 ──────── 拆模板 │ Lag │ └────────────────────────────────┘

• 用途：等待前序成果固化（如混凝土凝固、油漆干燥）
• 考试标识：“等待X天后”、“养护期”、“干燥时间”

提前量（Lead）

设计 ────────────────────────── 采购 ╲───────────────────────╱ 提前2周开始（快速跟进）

• 用途：进度压缩，让后续活动提前开始
• 与快速跟进关系：提前量是快速跟进的技术实现
• 考试标识：“提前X天开始”、“重叠进行”

⚡高频考点：提前量 = 负的滞后量。Lag 增加工期，Lead 缩短工期但增加风险。

4-47 进度计划（上）

制定进度计划的输入

1. 进度管理计划（方法论）
2. 活动清单 + 活动属性（做什么）
3. 项目进度网络图（PDM，逻辑关系）
4. 活动资源需求（谁来做）
5. 资源日历（何时有空）
6. 活动持续时间估算（做多久）
7. 范围基准（边界约束）

关键路径法（CPM）

关键路径：项目中持续时间最长的路径，决定了项目的最短工期。

关键路径特征： - 总浮动时间（Total Float）= 0 - 任何延迟都会直接导致项目延期 - 项目可以有多个关键路径（风险更高） - 关键路径可能随进度推进而变化

关键路径计算三要素

⚡关键公式：

• 顺推取最大（多个前置活动时，取最大的EF作为当前ES）
• 逆推取最小（多个后续活动时，取最小的LS作为当前LF）

4-48 进度计划（下）

关键链法（CCM）

关键链 = 关键路径 + 资源约束

关键路径法（CPM）：只看逻辑关系，不考虑资源限制 关键链法（CCM）：考虑资源限制，调整后的最长路径 CCM特点： - 考虑资源稀缺性 - 移除活动间的安全缓冲（个体缓冲） - 在关键链末端集中设置项目缓冲（Project Buffer） - 在非关键链汇入处设置接驳缓冲（Feeding Buffer）

资源优化技术

⚡高频考点：资源平衡会延长工期（可能改变关键路径），资源平滑不会延长工期（只在浮动时间内调整）。

进度压缩技术对比

4-49 进度压缩技术

赶工（Crashing）

定义：通过增加资源（人力、设备、加班）来缩短关键路径上活动的持续时间。

成本斜率计算：

成本斜率 = (赶工成本 - 正常成本) / (正常时间 - 赶工时间) 选择赶工活动优先级： 1. 在关键路径上 2. 成本斜率最低（单位时间增加的成本最少） 3. 赶工后不会导致质量问题

赶工注意事项：

• 不是所有活动都能赶工（如浇筑混凝土需要时间凝固）
• 赶工可能导致效率下降（ Brooks 定律：加人不一定更快）
• 优先赶工成本斜率低的任务

快速跟进（Fast Tracking）

定义：将原来串行的活动改为并行或重叠，缩短总工期。

原计划：A ────────── B ────────── C（总工期30天） 10天 10天 10天 快速跟进：A ──────── B ╲───────── C（总工期20天） B和C重叠5天

风险：

• 返工风险增加（后续活动可能需要前序的完整成果）
• 需要更多协调和沟通
• 只适合风险可接受的活动

赶工 vs 快速跟进选择

4.50 资源平滑

核心定义

资源平滑（Resource Smoothing）：在总浮动时间内调整活动的开始和完成时间，使资源使用量趋于平稳，不改变关键路径，不延长项目工期。

资源平衡 vs 资源平滑

四大进度调整技术全景对比

赶工的关键认知

赶工 = 增加额外资源 额外资源的五种形式： 1. 增加人手 ← 多一个人干活 2. 加班 ← 同一批人多干，也是额外资源！ 3. 外包 ← 临时找外部团队 4. 增加设备 ← 多一台机器并行 5. 批准超时 ← 授权周末/夜间施工

⚡考试陷阱：加班 =赶工，不是快速跟进！因为加班 = 增加工时资源 = 增加成本。快速跟进不增加资源，只改变逻辑关系。

常见错误

4.51 敏捷下的进度管理

核心定义

敏捷进度管理不依赖甘特图和关键路径，而是通过短迭代 + 持续反馈来管理进度。核心理念：固定时间，范围可变。

传统 vs 敏捷进度管理

核心概念

故事点（Story Point）

不是时间单位，是相对工作量+复杂度+不确定性的综合度量。

⚡考试陷阱：故事点 ≠ 小时。一个故事点在不同团队可能对应不同时间，取决于团队速度。

速度（Velocity）

速度 = 一个迭代中团队完成的故事点总和 三迭代平均速度 = (Iteration1 + Iteration2 + Iteration3) / 3 用途： - 预测还能做多少（剩余故事点 / 速度 = 剩余迭代数） - 规划下一个迭代的容量（上个迭代的速度 = 下个迭代的上限）

⚡速度定律：速度不是绩效指标！不能用速度在不同团队间比较，只能用于自己团队的预测。

时间盒（Timebox）

┌───────────────────────────────────┐ │ Sprint（通常2周） │ │ │ │ 固定时长 + 固定团队 ────────► 范围可变 │ │ │ │ 到时间就停，没做完的延到下个迭代 │ └───────────────────────────────────┘

三大核心工具

燃尽图（Burndown Chart）

剩余工作量 │ │ ●── │ ╲ │ ╲ 理想线（对角线） │ ╲ 实际线（有波动） │ ●── │ ╲__ │ ╲______● └──────────────────────────► 时间 Sprint开始 Sprint结束

⚡关键考点：燃尽图看的是趋势，不是绝对值。线快速下降不一定是好事，可能是范围被砍了。

燃起图（Burnup Chart）

完成量 │ ╱──── 范围（可能变化） │ ╱ │ ╱ │ ╱ │ ╱───── 实际完成 │ ╱ │ ╱ └──────────────────────────► 时间

看板（Kanban Board）

Todo Doing Done ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Story G │ │ Story D │ │ Story A │ │ Story H │ │ Story E │ │ Story B │ │ Story I │ │ │ │ Story C │ │ │ │ │ │ Story F │ └─────────┘ └─────────┘ └─────────┘ WIP 限制 = 3

WIP（在制品）限制：每个 Doing 列最多同时进行 N 个任务。超过就停，先完成旧任务再拉新任务。核心价值是限制并行度，加速流动。

迭代规划流程

Sprint Planning（迭代计划会） │ ├── 1. PO 讲"做什么"（从 Product Backlog 取最高优先级） ├── 2. 团队估算（故事点） ├── 3. 团队承诺"能做多少"（基于上次速度） └── 4. 拆分为任务，形成 Sprint Backlog │ ▼ Daily Scrum（每日站会15分钟） - 昨天做了什么？今天做什么？有什么障碍？ │ ▼ Sprint Review（评审会） - 向干系人演示完成的增量，获取反馈 │ ▼ Sprint Retrospective（回顾会） - 团队内部复盘：什么做得好？什么要改进？

常见错误

4.52 看板与大核心实践

核心定义

看板（Kanban）：通过可视化工作流、限制在制品、管理流动速度来优化交付节奏。不是一次性变革，是渐进式改进。

看板的首要原则：从你现在做的事情开始——不推翻现有流程，用看板来逐步获取洞察和改进。

看板的六大核心实践

┌─────────────────────────────────────────────────────────┐ │ 看板六实践 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ① 可视化 │ │ ② 限制WIP │ │ ③ 管理流动 │ │ │ │ 工作流 │ │ 在制品数量 │ │ 持续交付 │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ④ 明确策略 │ │ ⑤ 反馈循环 │ │ ⑥ 协作改进 │ │ │ │ 流程规则 │ │ 持续优化 │ │ 实验性演化 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘

逐条详解

实践 ① 可视化工作流

Todo(5) 分析中(2) 开发中(3) 测试中(2) Done ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ │ │ ● │ │ │ │ ● ● │ │ ● │ │ │ │ │ │ │ │ ● │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ 5件 2件 3件 2件 5件 ↑WIP=2 ↑WIP=3 ↑WIP=2

瓶颈一目了然：开发中积压3件，测试中只有2件→开发比测试快，形成积压。

实践 ② 限制 WIP（最核心）

为什么 WIP 限制最重要？ 多任务并行 ──► 频繁切换 ──► 每件都慢 ──► 整体交付延迟 WIP 限制 ──► 专注完成 ──► 单件流动快 ──► 整体交付加速

⚡考试陷阱：WIP 限制的原因不是"人太忙"，而是"并行度越高，单件完成越慢"。利特尔法则：周期时间 = WIP / 吞吐率。

实践 ③ 管理流动

核心指标：

累积流图（CFD）：

工作项 │ │ ╱ │ ╱ ← Done（上升=在交付） │╱ ╱ │ ╱╱ ← Doing（带宽=在制品） │╱ ╱ ╱──╱──────────── ← Todo（进入=需求） └────────────────────► 时间

⚡CFD 解读：Done 和 Doing 之间的区域宽度 ↑ = WIP 增加 = 瓶颈形成。

常见错误

4.53 敏捷发布规划

核心定义

敏捷发布规划（Release Planning）：在产品路线图指导下，确定哪个版本发布哪些功能、何时发布。位于迭代规划之上，产品规划之下。

洋葱圈规划模型

┌──────────────────────────────────┐ │ 战 略（Strategy） │ ← 公司愿景，2-5年 │ ┌────────────────────────────┐ │ │ │ 产品组合（Portfolio） │ │ ← 投资优先级，1-3年 │ │ ┌──────────────────────┐ │ │ │ │ │ 产品路线图（Product） │ │ │ ← 功能主题，6-12月 │ │ │ ┌────────────────┐ │ │ │ │ │ │ │ 发布（Release） │ │ │ │ ← 版本规划，2-3月 │ │ │ │ ┌──────────┐ │ │ │ │ │ │ │ │ │ 迭代 │ │ │ │ │ ← Sprint，1-4周 │ │ │ │ │ ┌──────┐ │ │ │ │ │ │ │ │ │ │ │ 每日 │ │ │ │ │ │ ← Daily，1天 │ │ │ │ │ └──────┘ │ │ │ │ │ │ │ │ │ └──────────┘ │ │ │ │ │ │ │ └────────────────┘ │ │ │ │ │ └──────────────────────┘ │ │ │ └────────────────────────────┘ │ └──────────────────────────────────┘ 越往外圈 → 越战略/抽象/长期 越往内圈 → 越战术/具体/短期

⚡高频考点：洋葱圈从外到内——战略→组合→产品→发布→迭代→每日。离圆心越近越concrete，离越远越abstract。

敏捷发布规则

发布规划三步法

步骤 1：确定发布目标与日期 └── 回答：这个版本要解决什么问题？什么时候上线？ 步骤 2：选择并估算 Backlog 条目 └── 按 MOSCOW 排序，估算故事点，用速度计算容量 步骤 3：制定发布计划 └── 分派功能到各迭代，检查依赖和风险

发布燃尽图

剩余故事点 │ │ ●── │ ╲ │ ╲ │ ╲ 实际完成 │ ●── │ ╲__ │ ╲●── │ ╲──● └─────────────────────────► 迭代 Iter1 Iter2 Iter3 Iter4 横轴 = 迭代（不是天！） 纵轴 = 剩余故事点

⚡区别：迭代燃尽图横轴是天，发布燃尽图横轴是迭代。考的就是这个横轴的区别。

常见错误

4.54 敏捷进度燃尽图

核心定义

燃尽图（Burndown Chart）：跟踪迭代内剩余工作量的可视化工具。横轴=时间（天），纵轴=剩余工作量（故事点或小时），核心是看趋势，不是看某一天的值。

燃尽图的标准读法

剩余工作量（故事点/小时） │ │ ●── 理想线（完美匀速） │ ╲ │ ╲ │ ╲_______ 实际线 │ ╲___ │ ╲────● └───────────────────────────► 时间（天） Day1 Day3 Day5 Day7 Day9 理想线：从初始估计到零，每天均匀完成 实际线：每天更新剩余量，正常会有波动

六大典型模式

正常： 落后： 陡降（范围移除）： │╲ │●── │●── │ ╲ │ ╲ │ ╲ │ ╲ │ ╲__ │ ╲__ │ ╲___ │ ╲──● │ ╲ ← 突然掉 └───────► └───────► │ ╲● ↑ 不是做得快！

⚡最高频陷阱：线突然陡降 ≠ 团队超常发挥，=范围被砍了！考试必考这个判断。

故事点燃尽 vs 任务小时燃尽

燃尽图 vs 燃起图

常见错误

本章常见考试陷阱