08 进度管理2026-06-25 新建4-42 如何防止范围蔓延核心定义范围蔓延Scope Creep未经控制的项目范围扩大表现为需求不断增加、功能持续叠加导致进度延迟、成本超支。范围蔓延的常见原因原因说明预防对策客户需求不断增加“顺便做个小功能”严格执行变更控制流程边界不清什么该做、什么不该做没说清楚范围说明书明确除外责任镀金团队主动增加更好的功能坚持做且只做该做的无变更控制变更随口一说就改所有变更必须书面评估审批干系人管理不善各方各说各话建立沟通机制统一出口预防范围蔓延的五大策略┌─────────────────────────────────────────────────────┐ │ 1. 清晰的范围说明书明确边界 │ │ 2. 完善的WBS100%原则不遗漏不多做 │ │ 3. 严格的变更控制流程4.6整体变更控制 │ │ 4. 定期范围核实5.5确认范围阶段验收 │ │ 5. 干系人参与和沟通让所有人知道边界在哪 │ └─────────────────────────────────────────────────────┘⚡关键认知范围蔓延不是客户坏而是PM没守住边界。好的PM会说可以但需要评估影响后走变更流程。4-43 范围蔓延该怎么办已发生蔓延的应对步骤步骤行动说明1停止蔓延立即冻结当前范围不再接受新的顺便需求2评估影响量化已蔓延范围对进度/成本/质量的影响3记录问题在问题日志中登记作为经验教训4重新基线如果蔓延已既成事实提交变更请求重新建立基准5强化控制加强后续变更控制防止再次发生考试应对策略情景题套路客户/发起人要求增加功能PM应该❌ 直接拒绝 → 影响关系❌ 直接答应 → 范围蔓延✅ “我理解这个需求让我先评估对范围/进度/成本的影响然后提交变更请求给CCB审批”4-44 滚动式开发核心定义滚动式规划Rolling Wave Planning对近期工作详细规划对远期工作粗略规划随项目推进逐步细化。滚动式规划的特点时间轴 ────────────────────────────────────────────────► 近期当前迭代 中期下几个迭代 远期后续阶段 ┌─────────────────┬──────────────────┬──────────────────┐ │ 详细规划 │ 粗略规划 │ 方向性规划 │ │ 工作包分解 │ 控制账户层面 │ 里程碑级别 │ │ 资源/日期确定 │ 估算范围 │ 大致时间窗口 │ └─────────────────┴──────────────────┴──────────────────┘ 详细 ◄──────────────────────────────────────── 粗略适用场景场景说明不确定性高的项目无法一次性看清全貌敏捷/混合型项目自然匹配迭代交付研发/创新项目需求随探索逐渐清晰长期项目远期确实无法精确预估与规划包的关系规划包Planning Package控制账户下暂未分解的工作滚动式规划把规划包逐步细化为工作包的过程⚡高频考点滚动式规划≠没有计划而是渐进明细的计划。规划包在WBS中但不是工作包等工作内容明确了再分解。4-45 紧前关系绘图法PDM核心定义PDMPrecedence Diagramming Method用节点表示活动用箭线表示逻辑关系绘制项目进度网络图。四种依赖关系类型英文表示含义举例FSFinish-to-Start完成-开始A完成B才能开始浇筑混凝土→拆模板SSStart-to-Start开始-开始A开始B才能开始开始设计→开始采购FFFinish-to-Finish完成-完成A完成B才能完成子系统测试→总装测试完成SFStart-to-Finish开始-完成A开始B才能完成夜班开始→白班结束极少用⚡最高频考点FS 最常用占90%SF 几乎不用。PDM 图示┌───┐ ┌───┐ ┌───┐ │ A │──────────│ B │──────────│ C │ └───┘ FS └───┘ FS └───┘ ┌───┐ ┌───┐ │ D │══════════│ E │ SS同时开始 └───┘ └───┘ ┌───┐ │ F │══════════┐ └───┘ ▼ ┌───┐ │ G │ FF同时完成 └───┘4-46 滞后量和提前量核心定义概念英文含义图示滞后量Lag前序活动完成后等待一段时间才能开始后序A ────‖──── B提前量Lead前序活动尚未完成提前开始后序重叠A ────╲──── B滞后量Lag混凝土浇筑 ──────── 等待28天 ──────── 拆模板 │ Lag │ └────────────────────────────────┘用途等待前序成果固化如混凝土凝固、油漆干燥考试标识“等待X天后”、“养护期”、“干燥时间”提前量Lead设计 ────────────────────────── 采购 ╲───────────────────────╱ 提前2周开始快速跟进用途进度压缩让后续活动提前开始与快速跟进关系提前量是快速跟进的技术实现考试标识“提前X天开始”、“重叠进行”⚡高频考点提前量 负的滞后量。Lag 增加工期Lead 缩短工期但增加风险。4-47 进度计划上制定进度计划的输入进度管理计划方法论活动清单 活动属性做什么项目进度网络图PDM逻辑关系活动资源需求谁来做资源日历何时有空活动持续时间估算做多久范围基准边界约束关键路径法CPM关键路径项目中持续时间最长的路径决定了项目的最短工期。关键路径特征 - 总浮动时间Total Float 0 - 任何延迟都会直接导致项目延期 - 项目可以有多个关键路径风险更高 - 关键路径可能随进度推进而变化关键路径计算三要素要素说明计算最早开始 ES活动最早能开始的时间顺推ES 工期 EF最早完成 EF活动最早能完成的时间顺推最晚开始 LS不影响项目完工的最晚开始逆推LF - 工期 LS最晚完成 LF不影响项目完工的最晚完成逆推总浮动 TF活动可延迟的最大时间TF LS - ES LF - EF⚡关键公式顺推取最大多个前置活动时取最大的EF作为当前ES逆推取最小多个后续活动时取最小的LS作为当前LF4-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 资源平滑对比维度资源平衡Leveling资源平滑Smoothing核心目的解决资源过载需求供应资源使用量均匀化减少波动约束条件可能违反原定时间必须在总浮动时间内对关键路径✅ 可能改变❌ 不改变对工期可能延长不延长考试关键词资源不足、资源冲突总浮动时间、调整但不延期四大进度调整技术全景对比技术成本风险工期何时用资源平滑不加不加不变有浮动时间想优化资源分布资源平衡不加不加可能资源不足/过载必须解决冲突快速跟进不加显著↑缩短预算有限风险可接受赶工增加少量↑缩短预算充足时间紧迫赶工的关键认知赶工 增加额外资源 额外资源的五种形式 1. 增加人手 ← 多一个人干活 2. 加班 ← 同一批人多干也是额外资源 3. 外包 ← 临时找外部团队 4. 增加设备 ← 多一台机器并行 5. 批准超时 ← 授权周末/夜间施工⚡考试陷阱加班 赶工不是快速跟进因为加班 增加工时资源 增加成本。快速跟进不增加资源只改变逻辑关系。常见错误陷阱正解加班快速跟进 ×加班增加工时资源赶工。快速跟进不增资源只改顺序资源平滑可以解决资源过载 ×平滑只在浮动时间内微调解决不了真的不够用资源平滑和资源平衡一回事 ×平衡解决冲突(可能延长)平滑削峰填谷(不延长)赶工只指加人 ×加班、加设备、外包都是赶工都是增加资源优先赶工最快 ×先资源平滑(无损)→平衡→快速跟进→最后赶工4.51 敏捷下的进度管理核心定义敏捷进度管理不依赖甘特图和关键路径而是通过短迭代 持续反馈来管理进度。核心理念固定时间范围可变。传统 vs 敏捷进度管理维度传统瀑布敏捷计划方式一次规划整个项目滚动式只详细规划当前迭代核心工具甘特图、CPM、里程碑燃尽图、看板、迭代计划估算单位人天/小时故事点Story Point进度可见性里程碑评审每日站会、迭代评审范围灵活性固定范围调整时间/成本固定时间范围可变核心约束铁三角锁定时间盒Timebox锁定核心概念故事点Story Point不是时间单位是相对工作量复杂度不确定性的综合度量。特点说明相对估算不是这个功能要8小时是这个功能复杂度是那个的2倍团队自主每个团队的故事点不可跨团队比较参考基准通常选一个1点的故事作为锚定如一个简单的登录页面斐波那契数列常用1、2、3、5、8、13、20、40、100来估算⚡考试陷阱故事点 ≠ 小时。一个故事点在不同团队可能对应不同时间取决于团队速度。速度Velocity速度 一个迭代中团队完成的故事点总和 三迭代平均速度 (Iteration1 Iteration2 Iteration3) / 3 用途 - 预测还能做多少剩余故事点 / 速度 剩余迭代数 - 规划下一个迭代的容量上个迭代的速度 下个迭代的上限⚡速度定律速度不是绩效指标不能用速度在不同团队间比较只能用于自己团队的预测。时间盒Timebox┌───────────────────────────────────┐ │ Sprint通常2周 │ │ │ │ 固定时长 固定团队 ────────► 范围可变 │ │ │ │ 到时间就停没做完的延到下个迭代 │ └───────────────────────────────────┘三大核心工具燃尽图Burndown Chart剩余工作量 │ │ ●── │ ╲ │ ╲ 理想线对角线 │ ╲ 实际线有波动 │ ●── │ ╲__ │ ╲______● └──────────────────────────► 时间 Sprint开始 Sprint结束线含义对角线理想燃尽每天均匀完成实际线在理想线上方落后完成得比计划慢实际线在理想线下方超前完成得比计划快线突然掉得很快移除范围不是完成得快是少做了⚡关键考点燃尽图看的是趋势不是绝对值。线快速下降不一定是好事可能是范围被砍了。燃起图Burnup Chart完成量 │ ╱──── 范围可能变化 │ ╱ │ ╱ │ ╱ │ ╱───── 实际完成 │ ╱ │ ╱ └──────────────────────────► 时间vs 燃尽图燃起图优势燃尽只看剩余燃起同时展示范围变化完成量燃尽中范围变化不明显燃起中范围线变化一眼可见看板Kanban BoardTodo Doing Done ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Story G │ │ Story D │ │ Story A │ │ Story H │ │ Story E │ │ Story B │ │ Story I │ │ │ │ Story C │ │ │ │ │ │ Story F │ └─────────┘ └─────────┘ └─────────┘ WIP 限制 3WIP在制品限制每个 Doing 列最多同时进行 N 个任务。超过就停先完成旧任务再拉新任务。核心价值是限制并行度加速流动。迭代规划流程Sprint Planning迭代计划会 │ ├── 1. PO 讲做什么从 Product Backlog 取最高优先级 ├── 2. 团队估算故事点 ├── 3. 团队承诺能做多少基于上次速度 └── 4. 拆分为任务形成 Sprint Backlog │ ▼ Daily Scrum每日站会15分钟 - 昨天做了什么今天做什么有什么障碍 │ ▼ Sprint Review评审会 - 向干系人演示完成的增量获取反馈 │ ▼ Sprint Retrospective回顾会 - 团队内部复盘什么做得好什么要改进常见错误陷阱正解故事点小时 ×故事点是相对估算单位不是时间速度越高团队越好 ×速度是预测工具不是绩效KPI燃尽图直线下降完美 ×可能范围被砍了要结合完成量判断敏捷没有计划 ×每个Sprint都有详细计划只是不做全项目的一次性计划看板板子 ×看板的核心是WIP限制不是物理板子4.52 看板与大核心实践核心定义看板Kanban通过可视化工作流、限制在制品、管理流动速度来优化交付节奏。不是一次性变革是渐进式改进。看板的首要原则从你现在做的事情开始——不推翻现有流程用看板来逐步获取洞察和改进。看板的六大核心实践┌─────────────────────────────────────────────────────────┐ │ 看板六实践 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ① 可视化 │ │ ② 限制WIP │ │ ③ 管理流动 │ │ │ │ 工作流 │ │ 在制品数量 │ │ 持续交付 │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ④ 明确策略 │ │ ⑤ 反馈循环 │ │ ⑥ 协作改进 │ │ │ │ 流程规则 │ │ 持续优化 │ │ 实验性演化 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘逐条详解#实践英文核心怎么做①可视化工作流Visualize Workflow看不见的就管不了画看板列Todo→Doing→Done每张卡代表一个工作项②限制在制品Limit WIP并行是效率的杀手每列设WIP上限如Doing≤3多了就停先做完再拉新③管理流动Manage Flow速度≠效率流动效率追踪周期时间Lead Time消除瓶颈和等待④明确策略Make Policies Explicit模糊扯皮明确定义Done、“Ready”、准入规则、退出规则⑤实施反馈循环Feedback Loops不反馈盲飞站会、看板会议、交付评审、运营评审⑥协作改进Improve Collaboratively改进是持续实验小步实验→验证→推广或回滚数据驱动不拍脑袋实践 ① 可视化工作流Todo(5) 分析中(2) 开发中(3) 测试中(2) Done ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ │ │ ● │ │ │ │ ● ● │ │ ● │ │ │ │ │ │ │ │ ● │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ 5件 2件 3件 2件 5件 ↑WIP2 ↑WIP3 ↑WIP2瓶颈一目了然开发中积压3件测试中只有2件→开发比测试快形成积压。实践 ② 限制 WIP最核心为什么 WIP 限制最重要 多任务并行 ──► 频繁切换 ──► 每件都慢 ──► 整体交付延迟 WIP 限制 ──► 专注完成 ──► 单件流动快 ──► 整体交付加速WIP 过高WIP 限制合理每个人同时做3-4件事每个人专注1-2件事每件事都进展中每件事快速已完成交付周期长交付周期短瓶颈不可见瓶颈立刻暴露⚡考试陷阱WIP 限制的原因不是人太忙而是并行度越高单件完成越慢。利特尔法则周期时间 WIP / 吞吐率。实践 ③ 管理流动核心指标指标含义计算周期时间Cycle Time从开始做到做完的时间Done时间 - Doing开始时间前置时间Lead Time从提出需求到交付的全时间Done时间 - Todo进入时间吞吐率Throughput单位时间完成的工作项数量完成数 / 时间段累积流图CFD工作项 │ │ ╱ │ ╱ ← Done上升在交付 │╱ ╱ │ ╱╱ ← Doing带宽在制品 │╱ ╱ ╱──╱──────────── ← Todo进入需求 └────────────────────► 时间⚡CFD 解读Done 和 Doing 之间的区域宽度 ↑ WIP 增加 瓶颈形成。常见错误陷阱正解看板只是贴满便签的白板 ×看板六大实践便签只是可视化工具核心是 WIP 限制WIP 限制越大越好 ×WIP越小流动越快关键是找到平衡点看板和 Scrum 不能兼用 ×Scrumban 结合了 Scrum 的迭代和看板的流动管理周期时间越短越要再加人 ×先找瓶颈、消除浪费加人是最后手段4.53 敏捷发布规划核心定义敏捷发布规划Release Planning在产品路线图指导下确定哪个版本发布哪些功能、何时发布。位于迭代规划之上产品规划之下。洋葱圈规划模型┌──────────────────────────────────┐ │ 战 略Strategy │ ← 公司愿景2-5年 │ ┌────────────────────────────┐ │ │ │ 产品组合Portfolio │ │ ← 投资优先级1-3年 │ │ ┌──────────────────────┐ │ │ │ │ │ 产品路线图Product │ │ │ ← 功能主题6-12月 │ │ │ ┌────────────────┐ │ │ │ │ │ │ │ 发布Release │ │ │ │ ← 版本规划2-3月 │ │ │ │ ┌──────────┐ │ │ │ │ │ │ │ │ │ 迭代 │ │ │ │ │ ← Sprint1-4周 │ │ │ │ │ ┌──────┐ │ │ │ │ │ │ │ │ │ │ │ 每日 │ │ │ │ │ │ ← Daily1天 │ │ │ │ │ └──────┘ │ │ │ │ │ │ │ │ │ └──────────┘ │ │ │ │ │ │ │ └────────────────┘ │ │ │ │ │ └──────────────────────┘ │ │ │ └────────────────────────────┘ │ └──────────────────────────────────┘ 越往外圈 → 越战略/抽象/长期 越往内圈 → 越战术/具体/短期圈层规划对象时间跨度谁来定灵活性战略愿景、目标2-5年高管/CEO最抽象产品组合投资方向、资源分配1-3年PMO/组合经理产品功能主题、路线图6-12月Product Owner发布版本功能集、发布时间2-3月PO 团队迭代Sprint 目标、PBIs1-4周全体团队每日当天任务1天开发人员最具体⚡高频考点洋葱圈从外到内——战略→组合→产品→发布→迭代→每日。离圆心越近越concrete离越远越abstract。敏捷发布规则#规则说明1固定时间可变范围发布日期固定不固定的是这个版本里做多少功能2MOSCOW 优先级Must have必须有→ Should have应该有→ Could have可以有→ Won’t have这次不要3最小可发布增量每个发布必须是一个完整可用、能独立交付的增量4速度驱动估算用最近几轮迭代的平均速度预测发布能容纳多少故事点5持续整理 BacklogPO 持续对 Product Backlog 排序、细化、拆分6发布燃尽图跟踪发布层面的进度横轴迭代数纵轴剩余故事点发布规划三步法步骤 1确定发布目标与日期 └── 回答这个版本要解决什么问题什么时候上线 步骤 2选择并估算 Backlog 条目 └── 按 MOSCOW 排序估算故事点用速度计算容量 步骤 3制定发布计划 └── 分派功能到各迭代检查依赖和风险发布燃尽图剩余故事点 │ │ ●── │ ╲ │ ╲ │ ╲ 实际完成 │ ●── │ ╲__ │ ╲●── │ ╲──● └─────────────────────────► 迭代 Iter1 Iter2 Iter3 Iter4 横轴 迭代不是天 纵轴 剩余故事点⚡区别迭代燃尽图横轴是天发布燃尽图横轴是迭代。考的就是这个横轴的区别。常见错误陷阱正解发布规划每个迭代做一次 ×发布会跨多个迭代发布规划在项目初期做随迭代调整洋葱圈最内层是迭代 ×最内层是每日Daily迭代是倒数第二层发布一定要做完所有Must Have ×时间到了就发没做完的Must Have推到下一个发布发布燃尽图横轴是天 ×发布燃尽图横轴是迭代迭代燃尽图横轴才是天4.54 敏捷进度燃尽图核心定义燃尽图Burndown Chart跟踪迭代内剩余工作量的可视化工具。横轴时间天纵轴剩余工作量故事点或小时核心是看趋势不是看某一天的值。燃尽图的标准读法剩余工作量故事点/小时 │ │ ●── 理想线完美匀速 │ ╲ │ ╲ │ ╲_______ 实际线 │ ╲___ │ ╲────● └───────────────────────────► 时间天 Day1 Day3 Day5 Day7 Day9 理想线从初始估计到零每天均匀完成 实际线每天更新剩余量正常会有波动六大典型模式模式图示特征意味着什么PM 该做什么正常线围绕理想线波动进度基本健康继续观察落后线始终在理想线上方完成速度低于预期分析原因可能需要加速或调整范围超前线始终在理想线下方完成速度快于预期可以拉入更多 Backlog陡降线突然垂直下降范围被移除不是完成得快检查谁移除了什么记录影响陡升线突然上跳范围被增加确认变更是否走流程平坦连续几天不变没有完成任何任务排查障碍卡住了正常 落后 陡降范围移除 │╲ │●── │●── │ ╲ │ ╲ │ ╲ │ ╲ │ ╲__ │ ╲__ │ ╲___ │ ╲──● │ ╲ ← 突然掉 └───────► └───────► │ ╲● ↑ 不是做得快⚡最高频陷阱线突然陡降 ≠ 团队超常发挥范围被砍了考试必考这个判断。故事点燃尽 vs 任务小时燃尽维度故事点燃尽任务小时燃尽纵轴单位故事点人时小时更新时机故事完成时Done每天更新剩余工时精度相对粗只看故事是否完成更细能看到进行中的进展0→100问题故事不Done就不减有0→100效应每天有进展就减更平滑适用PO/干系人看进度趋势团队内部日常管理燃尽图 vs 燃起图燃尽图Burndown燃起图Burnup看剩余多少看完成了多少一条线理想实际两条线完成线范围线范围变化不明显范围变化一眼可见适合迭代级跟踪适合发布级跟踪常见错误陷阱正解线陡降团队效率高 ×范围被移除不要高兴太早线一直在理想线上方正常 ×持续在线上方落后需要干预只看最后一天的值 ×燃尽图的核心价值是趋势不是绝对值燃尽图燃起图 ×燃尽看剩余燃起看完成范围变化故事点燃尽和任务小时燃尽一样 ×故事点是0/1制(完成才减)任务小时每天递减#考点一句话1范围蔓延预防清晰范围严格变更阶段验收干系人沟通2滚动式规划近期详细/远期粗略渐进明细规划3PDM四种关系FS最常用SF几乎不用4Lag vs LeadLag等待时间Lead提前/重叠-时间5关键路径最长路径最短工期TF06顺推逆推顺推取最大逆推取最小7CPM vs CCMCPM只看逻辑CCM资源约束缓冲管理8资源平衡 vs 平滑平衡可能改关键路径平滑不改9赶工 vs 快速跟进赶工加资源加成本快速跟进并行加风险10进度压缩选择预算够→赶工风险可接受→快速跟进本章常见考试陷阱陷阱正解所有活动都可以赶工 ×有些活动有物理限制如混凝土凝固时间不能压缩快速跟进没有风险 ×快速跟进显著增加风险需要更多协调关键路径只有一条 ×项目可以有多个关键路径风险更高资源平衡不延长工期 ×资源平衡可能延长工期因为它改变了活动开始时间提前量就是负的滞后量 √这是对的但考试常考这个关系CPM和CCM是一样的 ×CPM不考虑资源CCM考虑资源约束浮动时间可以为负 ×负浮动已经延期必须压缩或赶工
08 进度管理
08 进度管理2026-06-25 新建4-42 如何防止范围蔓延核心定义范围蔓延Scope Creep未经控制的项目范围扩大表现为需求不断增加、功能持续叠加导致进度延迟、成本超支。范围蔓延的常见原因原因说明预防对策客户需求不断增加“顺便做个小功能”严格执行变更控制流程边界不清什么该做、什么不该做没说清楚范围说明书明确除外责任镀金团队主动增加更好的功能坚持做且只做该做的无变更控制变更随口一说就改所有变更必须书面评估审批干系人管理不善各方各说各话建立沟通机制统一出口预防范围蔓延的五大策略┌─────────────────────────────────────────────────────┐ │ 1. 清晰的范围说明书明确边界 │ │ 2. 完善的WBS100%原则不遗漏不多做 │ │ 3. 严格的变更控制流程4.6整体变更控制 │ │ 4. 定期范围核实5.5确认范围阶段验收 │ │ 5. 干系人参与和沟通让所有人知道边界在哪 │ └─────────────────────────────────────────────────────┘⚡关键认知范围蔓延不是客户坏而是PM没守住边界。好的PM会说可以但需要评估影响后走变更流程。4-43 范围蔓延该怎么办已发生蔓延的应对步骤步骤行动说明1停止蔓延立即冻结当前范围不再接受新的顺便需求2评估影响量化已蔓延范围对进度/成本/质量的影响3记录问题在问题日志中登记作为经验教训4重新基线如果蔓延已既成事实提交变更请求重新建立基准5强化控制加强后续变更控制防止再次发生考试应对策略情景题套路客户/发起人要求增加功能PM应该❌ 直接拒绝 → 影响关系❌ 直接答应 → 范围蔓延✅ “我理解这个需求让我先评估对范围/进度/成本的影响然后提交变更请求给CCB审批”4-44 滚动式开发核心定义滚动式规划Rolling Wave Planning对近期工作详细规划对远期工作粗略规划随项目推进逐步细化。滚动式规划的特点时间轴 ────────────────────────────────────────────────► 近期当前迭代 中期下几个迭代 远期后续阶段 ┌─────────────────┬──────────────────┬──────────────────┐ │ 详细规划 │ 粗略规划 │ 方向性规划 │ │ 工作包分解 │ 控制账户层面 │ 里程碑级别 │ │ 资源/日期确定 │ 估算范围 │ 大致时间窗口 │ └─────────────────┴──────────────────┴──────────────────┘ 详细 ◄──────────────────────────────────────── 粗略适用场景场景说明不确定性高的项目无法一次性看清全貌敏捷/混合型项目自然匹配迭代交付研发/创新项目需求随探索逐渐清晰长期项目远期确实无法精确预估与规划包的关系规划包Planning Package控制账户下暂未分解的工作滚动式规划把规划包逐步细化为工作包的过程⚡高频考点滚动式规划≠没有计划而是渐进明细的计划。规划包在WBS中但不是工作包等工作内容明确了再分解。4-45 紧前关系绘图法PDM核心定义PDMPrecedence Diagramming Method用节点表示活动用箭线表示逻辑关系绘制项目进度网络图。四种依赖关系类型英文表示含义举例FSFinish-to-Start完成-开始A完成B才能开始浇筑混凝土→拆模板SSStart-to-Start开始-开始A开始B才能开始开始设计→开始采购FFFinish-to-Finish完成-完成A完成B才能完成子系统测试→总装测试完成SFStart-to-Finish开始-完成A开始B才能完成夜班开始→白班结束极少用⚡最高频考点FS 最常用占90%SF 几乎不用。PDM 图示┌───┐ ┌───┐ ┌───┐ │ A │──────────│ B │──────────│ C │ └───┘ FS └───┘ FS └───┘ ┌───┐ ┌───┐ │ D │══════════│ E │ SS同时开始 └───┘ └───┘ ┌───┐ │ F │══════════┐ └───┘ ▼ ┌───┐ │ G │ FF同时完成 └───┘4-46 滞后量和提前量核心定义概念英文含义图示滞后量Lag前序活动完成后等待一段时间才能开始后序A ────‖──── B提前量Lead前序活动尚未完成提前开始后序重叠A ────╲──── B滞后量Lag混凝土浇筑 ──────── 等待28天 ──────── 拆模板 │ Lag │ └────────────────────────────────┘用途等待前序成果固化如混凝土凝固、油漆干燥考试标识“等待X天后”、“养护期”、“干燥时间”提前量Lead设计 ────────────────────────── 采购 ╲───────────────────────╱ 提前2周开始快速跟进用途进度压缩让后续活动提前开始与快速跟进关系提前量是快速跟进的技术实现考试标识“提前X天开始”、“重叠进行”⚡高频考点提前量 负的滞后量。Lag 增加工期Lead 缩短工期但增加风险。4-47 进度计划上制定进度计划的输入进度管理计划方法论活动清单 活动属性做什么项目进度网络图PDM逻辑关系活动资源需求谁来做资源日历何时有空活动持续时间估算做多久范围基准边界约束关键路径法CPM关键路径项目中持续时间最长的路径决定了项目的最短工期。关键路径特征 - 总浮动时间Total Float 0 - 任何延迟都会直接导致项目延期 - 项目可以有多个关键路径风险更高 - 关键路径可能随进度推进而变化关键路径计算三要素要素说明计算最早开始 ES活动最早能开始的时间顺推ES 工期 EF最早完成 EF活动最早能完成的时间顺推最晚开始 LS不影响项目完工的最晚开始逆推LF - 工期 LS最晚完成 LF不影响项目完工的最晚完成逆推总浮动 TF活动可延迟的最大时间TF LS - ES LF - EF⚡关键公式顺推取最大多个前置活动时取最大的EF作为当前ES逆推取最小多个后续活动时取最小的LS作为当前LF4-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 资源平滑对比维度资源平衡Leveling资源平滑Smoothing核心目的解决资源过载需求供应资源使用量均匀化减少波动约束条件可能违反原定时间必须在总浮动时间内对关键路径✅ 可能改变❌ 不改变对工期可能延长不延长考试关键词资源不足、资源冲突总浮动时间、调整但不延期四大进度调整技术全景对比技术成本风险工期何时用资源平滑不加不加不变有浮动时间想优化资源分布资源平衡不加不加可能资源不足/过载必须解决冲突快速跟进不加显著↑缩短预算有限风险可接受赶工增加少量↑缩短预算充足时间紧迫赶工的关键认知赶工 增加额外资源 额外资源的五种形式 1. 增加人手 ← 多一个人干活 2. 加班 ← 同一批人多干也是额外资源 3. 外包 ← 临时找外部团队 4. 增加设备 ← 多一台机器并行 5. 批准超时 ← 授权周末/夜间施工⚡考试陷阱加班 赶工不是快速跟进因为加班 增加工时资源 增加成本。快速跟进不增加资源只改变逻辑关系。常见错误陷阱正解加班快速跟进 ×加班增加工时资源赶工。快速跟进不增资源只改顺序资源平滑可以解决资源过载 ×平滑只在浮动时间内微调解决不了真的不够用资源平滑和资源平衡一回事 ×平衡解决冲突(可能延长)平滑削峰填谷(不延长)赶工只指加人 ×加班、加设备、外包都是赶工都是增加资源优先赶工最快 ×先资源平滑(无损)→平衡→快速跟进→最后赶工4.51 敏捷下的进度管理核心定义敏捷进度管理不依赖甘特图和关键路径而是通过短迭代 持续反馈来管理进度。核心理念固定时间范围可变。传统 vs 敏捷进度管理维度传统瀑布敏捷计划方式一次规划整个项目滚动式只详细规划当前迭代核心工具甘特图、CPM、里程碑燃尽图、看板、迭代计划估算单位人天/小时故事点Story Point进度可见性里程碑评审每日站会、迭代评审范围灵活性固定范围调整时间/成本固定时间范围可变核心约束铁三角锁定时间盒Timebox锁定核心概念故事点Story Point不是时间单位是相对工作量复杂度不确定性的综合度量。特点说明相对估算不是这个功能要8小时是这个功能复杂度是那个的2倍团队自主每个团队的故事点不可跨团队比较参考基准通常选一个1点的故事作为锚定如一个简单的登录页面斐波那契数列常用1、2、3、5、8、13、20、40、100来估算⚡考试陷阱故事点 ≠ 小时。一个故事点在不同团队可能对应不同时间取决于团队速度。速度Velocity速度 一个迭代中团队完成的故事点总和 三迭代平均速度 (Iteration1 Iteration2 Iteration3) / 3 用途 - 预测还能做多少剩余故事点 / 速度 剩余迭代数 - 规划下一个迭代的容量上个迭代的速度 下个迭代的上限⚡速度定律速度不是绩效指标不能用速度在不同团队间比较只能用于自己团队的预测。时间盒Timebox┌───────────────────────────────────┐ │ Sprint通常2周 │ │ │ │ 固定时长 固定团队 ────────► 范围可变 │ │ │ │ 到时间就停没做完的延到下个迭代 │ └───────────────────────────────────┘三大核心工具燃尽图Burndown Chart剩余工作量 │ │ ●── │ ╲ │ ╲ 理想线对角线 │ ╲ 实际线有波动 │ ●── │ ╲__ │ ╲______● └──────────────────────────► 时间 Sprint开始 Sprint结束线含义对角线理想燃尽每天均匀完成实际线在理想线上方落后完成得比计划慢实际线在理想线下方超前完成得比计划快线突然掉得很快移除范围不是完成得快是少做了⚡关键考点燃尽图看的是趋势不是绝对值。线快速下降不一定是好事可能是范围被砍了。燃起图Burnup Chart完成量 │ ╱──── 范围可能变化 │ ╱ │ ╱ │ ╱ │ ╱───── 实际完成 │ ╱ │ ╱ └──────────────────────────► 时间vs 燃尽图燃起图优势燃尽只看剩余燃起同时展示范围变化完成量燃尽中范围变化不明显燃起中范围线变化一眼可见看板Kanban BoardTodo Doing Done ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Story G │ │ Story D │ │ Story A │ │ Story H │ │ Story E │ │ Story B │ │ Story I │ │ │ │ Story C │ │ │ │ │ │ Story F │ └─────────┘ └─────────┘ └─────────┘ WIP 限制 3WIP在制品限制每个 Doing 列最多同时进行 N 个任务。超过就停先完成旧任务再拉新任务。核心价值是限制并行度加速流动。迭代规划流程Sprint Planning迭代计划会 │ ├── 1. PO 讲做什么从 Product Backlog 取最高优先级 ├── 2. 团队估算故事点 ├── 3. 团队承诺能做多少基于上次速度 └── 4. 拆分为任务形成 Sprint Backlog │ ▼ Daily Scrum每日站会15分钟 - 昨天做了什么今天做什么有什么障碍 │ ▼ Sprint Review评审会 - 向干系人演示完成的增量获取反馈 │ ▼ Sprint Retrospective回顾会 - 团队内部复盘什么做得好什么要改进常见错误陷阱正解故事点小时 ×故事点是相对估算单位不是时间速度越高团队越好 ×速度是预测工具不是绩效KPI燃尽图直线下降完美 ×可能范围被砍了要结合完成量判断敏捷没有计划 ×每个Sprint都有详细计划只是不做全项目的一次性计划看板板子 ×看板的核心是WIP限制不是物理板子4.52 看板与大核心实践核心定义看板Kanban通过可视化工作流、限制在制品、管理流动速度来优化交付节奏。不是一次性变革是渐进式改进。看板的首要原则从你现在做的事情开始——不推翻现有流程用看板来逐步获取洞察和改进。看板的六大核心实践┌─────────────────────────────────────────────────────────┐ │ 看板六实践 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ① 可视化 │ │ ② 限制WIP │ │ ③ 管理流动 │ │ │ │ 工作流 │ │ 在制品数量 │ │ 持续交付 │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ ④ 明确策略 │ │ ⑤ 反馈循环 │ │ ⑥ 协作改进 │ │ │ │ 流程规则 │ │ 持续优化 │ │ 实验性演化 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘逐条详解#实践英文核心怎么做①可视化工作流Visualize Workflow看不见的就管不了画看板列Todo→Doing→Done每张卡代表一个工作项②限制在制品Limit WIP并行是效率的杀手每列设WIP上限如Doing≤3多了就停先做完再拉新③管理流动Manage Flow速度≠效率流动效率追踪周期时间Lead Time消除瓶颈和等待④明确策略Make Policies Explicit模糊扯皮明确定义Done、“Ready”、准入规则、退出规则⑤实施反馈循环Feedback Loops不反馈盲飞站会、看板会议、交付评审、运营评审⑥协作改进Improve Collaboratively改进是持续实验小步实验→验证→推广或回滚数据驱动不拍脑袋实践 ① 可视化工作流Todo(5) 分析中(2) 开发中(3) 测试中(2) Done ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ ● ● │ │ │ │ ● │ │ │ │ ● ● │ │ ● │ │ │ │ │ │ │ │ ● │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ 5件 2件 3件 2件 5件 ↑WIP2 ↑WIP3 ↑WIP2瓶颈一目了然开发中积压3件测试中只有2件→开发比测试快形成积压。实践 ② 限制 WIP最核心为什么 WIP 限制最重要 多任务并行 ──► 频繁切换 ──► 每件都慢 ──► 整体交付延迟 WIP 限制 ──► 专注完成 ──► 单件流动快 ──► 整体交付加速WIP 过高WIP 限制合理每个人同时做3-4件事每个人专注1-2件事每件事都进展中每件事快速已完成交付周期长交付周期短瓶颈不可见瓶颈立刻暴露⚡考试陷阱WIP 限制的原因不是人太忙而是并行度越高单件完成越慢。利特尔法则周期时间 WIP / 吞吐率。实践 ③ 管理流动核心指标指标含义计算周期时间Cycle Time从开始做到做完的时间Done时间 - Doing开始时间前置时间Lead Time从提出需求到交付的全时间Done时间 - Todo进入时间吞吐率Throughput单位时间完成的工作项数量完成数 / 时间段累积流图CFD工作项 │ │ ╱ │ ╱ ← Done上升在交付 │╱ ╱ │ ╱╱ ← Doing带宽在制品 │╱ ╱ ╱──╱──────────── ← Todo进入需求 └────────────────────► 时间⚡CFD 解读Done 和 Doing 之间的区域宽度 ↑ WIP 增加 瓶颈形成。常见错误陷阱正解看板只是贴满便签的白板 ×看板六大实践便签只是可视化工具核心是 WIP 限制WIP 限制越大越好 ×WIP越小流动越快关键是找到平衡点看板和 Scrum 不能兼用 ×Scrumban 结合了 Scrum 的迭代和看板的流动管理周期时间越短越要再加人 ×先找瓶颈、消除浪费加人是最后手段4.53 敏捷发布规划核心定义敏捷发布规划Release Planning在产品路线图指导下确定哪个版本发布哪些功能、何时发布。位于迭代规划之上产品规划之下。洋葱圈规划模型┌──────────────────────────────────┐ │ 战 略Strategy │ ← 公司愿景2-5年 │ ┌────────────────────────────┐ │ │ │ 产品组合Portfolio │ │ ← 投资优先级1-3年 │ │ ┌──────────────────────┐ │ │ │ │ │ 产品路线图Product │ │ │ ← 功能主题6-12月 │ │ │ ┌────────────────┐ │ │ │ │ │ │ │ 发布Release │ │ │ │ ← 版本规划2-3月 │ │ │ │ ┌──────────┐ │ │ │ │ │ │ │ │ │ 迭代 │ │ │ │ │ ← Sprint1-4周 │ │ │ │ │ ┌──────┐ │ │ │ │ │ │ │ │ │ │ │ 每日 │ │ │ │ │ │ ← Daily1天 │ │ │ │ │ └──────┘ │ │ │ │ │ │ │ │ │ └──────────┘ │ │ │ │ │ │ │ └────────────────┘ │ │ │ │ │ └──────────────────────┘ │ │ │ └────────────────────────────┘ │ └──────────────────────────────────┘ 越往外圈 → 越战略/抽象/长期 越往内圈 → 越战术/具体/短期圈层规划对象时间跨度谁来定灵活性战略愿景、目标2-5年高管/CEO最抽象产品组合投资方向、资源分配1-3年PMO/组合经理产品功能主题、路线图6-12月Product Owner发布版本功能集、发布时间2-3月PO 团队迭代Sprint 目标、PBIs1-4周全体团队每日当天任务1天开发人员最具体⚡高频考点洋葱圈从外到内——战略→组合→产品→发布→迭代→每日。离圆心越近越concrete离越远越abstract。敏捷发布规则#规则说明1固定时间可变范围发布日期固定不固定的是这个版本里做多少功能2MOSCOW 优先级Must have必须有→ Should have应该有→ Could have可以有→ Won’t have这次不要3最小可发布增量每个发布必须是一个完整可用、能独立交付的增量4速度驱动估算用最近几轮迭代的平均速度预测发布能容纳多少故事点5持续整理 BacklogPO 持续对 Product Backlog 排序、细化、拆分6发布燃尽图跟踪发布层面的进度横轴迭代数纵轴剩余故事点发布规划三步法步骤 1确定发布目标与日期 └── 回答这个版本要解决什么问题什么时候上线 步骤 2选择并估算 Backlog 条目 └── 按 MOSCOW 排序估算故事点用速度计算容量 步骤 3制定发布计划 └── 分派功能到各迭代检查依赖和风险发布燃尽图剩余故事点 │ │ ●── │ ╲ │ ╲ │ ╲ 实际完成 │ ●── │ ╲__ │ ╲●── │ ╲──● └─────────────────────────► 迭代 Iter1 Iter2 Iter3 Iter4 横轴 迭代不是天 纵轴 剩余故事点⚡区别迭代燃尽图横轴是天发布燃尽图横轴是迭代。考的就是这个横轴的区别。常见错误陷阱正解发布规划每个迭代做一次 ×发布会跨多个迭代发布规划在项目初期做随迭代调整洋葱圈最内层是迭代 ×最内层是每日Daily迭代是倒数第二层发布一定要做完所有Must Have ×时间到了就发没做完的Must Have推到下一个发布发布燃尽图横轴是天 ×发布燃尽图横轴是迭代迭代燃尽图横轴才是天4.54 敏捷进度燃尽图核心定义燃尽图Burndown Chart跟踪迭代内剩余工作量的可视化工具。横轴时间天纵轴剩余工作量故事点或小时核心是看趋势不是看某一天的值。燃尽图的标准读法剩余工作量故事点/小时 │ │ ●── 理想线完美匀速 │ ╲ │ ╲ │ ╲_______ 实际线 │ ╲___ │ ╲────● └───────────────────────────► 时间天 Day1 Day3 Day5 Day7 Day9 理想线从初始估计到零每天均匀完成 实际线每天更新剩余量正常会有波动六大典型模式模式图示特征意味着什么PM 该做什么正常线围绕理想线波动进度基本健康继续观察落后线始终在理想线上方完成速度低于预期分析原因可能需要加速或调整范围超前线始终在理想线下方完成速度快于预期可以拉入更多 Backlog陡降线突然垂直下降范围被移除不是完成得快检查谁移除了什么记录影响陡升线突然上跳范围被增加确认变更是否走流程平坦连续几天不变没有完成任何任务排查障碍卡住了正常 落后 陡降范围移除 │╲ │●── │●── │ ╲ │ ╲ │ ╲ │ ╲ │ ╲__ │ ╲__ │ ╲___ │ ╲──● │ ╲ ← 突然掉 └───────► └───────► │ ╲● ↑ 不是做得快⚡最高频陷阱线突然陡降 ≠ 团队超常发挥范围被砍了考试必考这个判断。故事点燃尽 vs 任务小时燃尽维度故事点燃尽任务小时燃尽纵轴单位故事点人时小时更新时机故事完成时Done每天更新剩余工时精度相对粗只看故事是否完成更细能看到进行中的进展0→100问题故事不Done就不减有0→100效应每天有进展就减更平滑适用PO/干系人看进度趋势团队内部日常管理燃尽图 vs 燃起图燃尽图Burndown燃起图Burnup看剩余多少看完成了多少一条线理想实际两条线完成线范围线范围变化不明显范围变化一眼可见适合迭代级跟踪适合发布级跟踪常见错误陷阱正解线陡降团队效率高 ×范围被移除不要高兴太早线一直在理想线上方正常 ×持续在线上方落后需要干预只看最后一天的值 ×燃尽图的核心价值是趋势不是绝对值燃尽图燃起图 ×燃尽看剩余燃起看完成范围变化故事点燃尽和任务小时燃尽一样 ×故事点是0/1制(完成才减)任务小时每天递减#考点一句话1范围蔓延预防清晰范围严格变更阶段验收干系人沟通2滚动式规划近期详细/远期粗略渐进明细规划3PDM四种关系FS最常用SF几乎不用4Lag vs LeadLag等待时间Lead提前/重叠-时间5关键路径最长路径最短工期TF06顺推逆推顺推取最大逆推取最小7CPM vs CCMCPM只看逻辑CCM资源约束缓冲管理8资源平衡 vs 平滑平衡可能改关键路径平滑不改9赶工 vs 快速跟进赶工加资源加成本快速跟进并行加风险10进度压缩选择预算够→赶工风险可接受→快速跟进本章常见考试陷阱陷阱正解所有活动都可以赶工 ×有些活动有物理限制如混凝土凝固时间不能压缩快速跟进没有风险 ×快速跟进显著增加风险需要更多协调关键路径只有一条 ×项目可以有多个关键路径风险更高资源平衡不延长工期 ×资源平衡可能延长工期因为它改变了活动开始时间提前量就是负的滞后量 √这是对的但考试常考这个关系CPM和CCM是一样的 ×CPM不考虑资源CCM考虑资源约束浮动时间可以为负 ×负浮动已经延期必须压缩或赶工
