《敏捷估算与规划》- Agile Estimating and Planning
作者：Mike Cohn | 312页 | 7大部分23章
核心观点：估算与规划过程本身也必须是敏捷的。规划的目的不是在第一天就给出”正确的计划”，而是通过持续迭代地规划，找到”构建什么、何时交付、投入多少资源”这一产品开发根本问题的最优解。
一、为什么传统规划会失败（Part I：问题与目标）
1. 规划的目的与不确定性
- 规划的目的：找到产品开发根本问题的最优答案——做什么功能、投入多少资源、什么时间交付
- 规划的价值：降低风险、减少不确定性、支持可靠决策、建立信任、传递信息
- 好计划的标准：足够可靠，能作为产品和项目决策的依据
- 敏捷规划的特点：更关注”规划过程”而非”计划本身”；鼓励变化；计划易于变更；贯穿整个项目
不确定性之锥（Cone of Uncertainty）：项目早期的估算偏差可达 ±60%~160%；需求确定后仍有 ±15% 偏差。估算精度随项目推进逐步提高。
2. 传统规划失败的五大原因
| 原因 | 说明 |
|---|---|
| 基于活动而非功能 | 甘特图/WBS 关注活动完成，但客户只关心功能交付。活动完成不等于价值交付 |
| 多任务的隐性成本 | 团队成员同时处理多个任务，上下文切换导致效率下降，项目更晚交付 |
| 末位砍功能 | 功能按开发者认为最高效的顺序开发，时间不够时砍掉的不一定是最低价值的功能 |
| 忽视需求不确定性 | 按最初需求计划，但用户真实需求在项目过程中会变化，导致按时交付了错误的东西 |
| 估算=承诺 | 组织混淆估算是预测还是承诺，一旦给出估算就被迫承诺，导致估算失真 |
3. 敏捷方法的核心思想
- 团队角色：产品负责人（PO，负责愿景和优先级）、客户、用户、开发者、管理者
- 短迭代交付：按固定时间盒迭代，每个迭代交付可用软件，按业务优先级选择功能
- 用户故事：表达用户需求的基本单元
- 项目产生两类新知识：产品知识 + 项目知识，两者都用于完善计划
- 三层规划：发布规划（3-6个月）→ 迭代规划（1-4周）→ 每日规划（站会）
- 满意条件（Conditions of Satisfaction）：PO 对发布/迭代的验收标准，包括范围、进度、资源等
二、估算规模（Part II：Estimating Size）
核心原则：规模估算和时长估算必须分开。先估算”有多大”，再根据速率推算”要多久”。
4. 故事点（Story Points）
- 定义：用户故事相对规模的度量。10点故事是5点故事的两倍大/复杂/有风险
- 速率（Velocity）：团队每迭代完成的故事点总数
- 本质：故事点纯粹是规模估算，不是时间估算。项目时长 = 总故事点 ÷ 团队速率
- 优势：相对性估算，不需要换算成时间，天然适配敏捷的迭代节奏
5. 理想人天（Ideal Days）
- 理想时间 vs 流逝时间：美式橄榄球理想时间60分钟，实际流逝3小时以上。差异来自所有中断
- 定义：排除所有干扰后，完成一个故事需要的专注工作日数
- 优势：比故事点更容易向团队外人解释，更容易起步，更容易预测初始速率
- 实践建议：每个故事给一个整体的理想天估算，而不是按角色拆分（程序员X天、测试Y天）
6. 估算技术
- 投入回报递减：花更多时间估算不一定更准确。投入应与估算用途匹配
- 估算三法：
- 专家意见：最常用，但依赖个人经验
- 类比法：与已知规模的故事比较
- 分解法：拆成小部分分别估算再加总
- 规划扑克（Planning Poker）：每人持估算卡牌，同时出牌，讨论差异直到达成共识。有趣且高效
- 估算尺度：
- 近期需求（需可靠估算）：非线性尺度 1, 2, 3, 5, 8（斐波那契）或 1, 2, 4, 8
- 远期需求（暂不实现）：更大单位 13, 20, 40, 100
7. 重新估算
- 何时重估：仅当你认为故事的相对规模发生了变化时才重估
- 不要因为进度慢就重估：速率（Velocity）会自动修正估算偏差——这是速率的”均衡器”作用
- 部分完成的故事：不给部分积分。要么全部完成计入速率，要么不计入。可以拆成”已完成部分”和”剩余部分”两个新故事重新估算
8. 故事点 vs 理想天：如何选择
| 维度 | 故事点 | 理想天 |
|---|---|---|
| 跨职能行为 | ✅ 推动跨职能协作 | ❌ 容易按角色拆分 |
| 估算衰减 | ✅ 不会随团队技能提升而失效 | ❌ 需要重估 |
| 纯粹规模度量 | ✅ 是 | ⚠️ 是但不够纯粹 |
| 估算速度 | ✅ 通常更快 | ❌ 较慢 |
| 人际可比性 | ✅ 相对值，人与人可比 | ❌ “我的理想天≠你的理想天” |
| 对外解释 | ❌ 难解释 | ✅ 容易理解 |
| 起步难度 | ❌ 需要转变思维 | ✅ 容易上手 |
| 初始速率预测 | ❌ 难 | ✅ 容易 |
作者建议：优先选故事点。如果团队难以理解纯规模估算，先从理想天开始，再逐步引导切换到故事点。
三、为价值而规划（Part III：Planning For Value）
规划不只是按时交付，更是确保交付最有价值的东西。
9. 功能优先级的四大因素
- 财务价值：功能带来的收入/成本节约
- 开发成本：开发（及后续维护）的成本
- 学习与新知识：开发功能带来的产品/项目知识增量
- 风险消除：开发功能消除了多少不确定性和风险
方法：先按价值和成本排序，再根据学习和风险因素调整顺序。高风险高学习价值的项目可以提前做。
10. 财务优先级分析
- 价值来源四分类：
- 新收入：来自新客户
- 增量收入：现有客户购买更多
- 留存收入：防止客户流失到竞品
- 运营效率：降低运营成本
- 时间维度：通常预测未来2年即可，季度粒度足够
- 四种财务评估方法：
- 净现值（NPV）：未来现金流折现到今天的价值
- 内部收益率（IRR/ROI）：投资回报率
- 回收期（Payback Period）：多久收回投资
- 折现回收期（Discounted Payback）：考虑货币时间价值的回收期
今天的钱比未来的钱更值钱。比较不同时间的收益需要折现。
11. 需求优先级：Kano 分析与相对权重
Kano 模型：功能分为三类
| 类别 | 特征 | 举例 |
|---|---|---|
| 必备型（Must-have） | 有了理所当然，没有会极度不满 | 酒店要有床、浴室 |
| 线性型（More is better） | 越多越好，满意度线性增长 | 床的舒适度、房间大小 |
| 兴奋型（Exciter/Delighter） | 有了惊喜，没有也不会不满 | 健身器材上的电视、免费矿泉水 |
- 相对权重法：综合考虑实现收益、不实现惩罚、成本，算出单一优先级值
12. 拆分用户故事
何时拆分：
- 故事太大，装不下一个迭代
- 需要更精确的估算时（大故事估算精度低）
拆分方法：
- 按数据类型：不同的数据实体分开
- 按操作类型：CRUD 拆分（创建/读取/更新/删除）
- 按横切关注点：先做功能，安全/日志/错误处理做单独故事
- 按性能：先实现功能，性能优化做单独故事
- 按优先级：如果故事包含多个不同优先级的需求，按优先级拆
避免的坑：
- ❌ 不要把用户故事拆成开发任务（按工作步骤拆）
- ❌ 不要为了凑数把无关改动塞进大故事
- ⚠️ 小的 bug fix 可以合并处理
四、排期规划（Part IV：Scheduling）
13. 发布规划（Release Planning）
- 定义：覆盖比迭代更长周期的高层计划，通常3-6个月一次发布
- 最简公式：预期速率 × 迭代次数 = 可完成故事点数 → 据此选择故事
- 不需要精确到每个迭代做什么：规划前几个迭代即可，后面的随推进逐步明确
- 迭代过程：从PO的满意条件（范围/进度/资源）出发，不满足就调整条件重新规划
- 持续更新：每个迭代开始时更新发布计划
14. 迭代规划（Iteration Planning）
- 定义：单个迭代内的详细工作计划，大故事拆成任务
- 任务估算单位：理想小时
- 两种方法：
- 速率驱动：按历史速率选择故事，再拆任务
- 承诺驱动：团队承诺能完成多少，按容量选故事
15. 迭代长度选择
- 标准范围：1-4周，没有万能解
- 选择因素：发布周期长度、不确定性大小、获取反馈的难易度、优先级稳定度、迭代开销、紧迫感维持
- 避坑建议：不要把迭代对齐到月末——每三个月就会撞上季末，上市公司季末营收压力巨大
16. 估算速率（Velocity）
三种方法：
- 历史平均值：有历史数据时使用，但要考虑团队/项目/技术是否有重大变化
- 跑几个迭代再说：通常是最佳选择
- 任务分解预测：把几个故事拆成任务，看一个迭代能装多少（类似迭代规划过程）
速率估算应该给一个范围，反映内在的不确定性。参考不确定性之锥确定范围大小。
17. 不确定性缓冲（Buffering）
何时需要额外缓冲：
- 项目提前很久规划
- 有硬性截止日期且功能范围相对固定
- 外包项目
- 需求只停留在表面理解
- 预估错误的影响（财务或其他）很大
两种缓冲：
| 类型 | 做法 | 适用场景 |
|---|---|---|
| 功能缓冲（Feature Buffer） | 优先级排序后，承认部分功能可能交付不了。DSDM 建议30%工作量作为可选 | 抵御功能不确定性 |
| 进度缓冲（Schedule Buffer） | 在排期中加入反映不确定性的额外时间 | 抵御进度不确定性 |
- 功能缓冲和进度缓冲可以组合使用，通常组合更好——各自可以更小
- 要警惕帕金森定律（工作填满所有可用时间）和学生综合征（不到最后不开始）
18. 多团队项目规划
四大协调技术（按需引入，从简到繁）：
- 统一估算基准：所有团队用相同单位（故事点或理想天），并通过一组基准故事对齐单位含义
- 提前细化用户故事：多团队协作时需要更早把故事细化，通过PO的满意条件来明确
- 滚动前瞻规划（Rolling Lookahead）：提前看2-3个迭代，团队间协调近期工作
- 馈送缓冲（Feeding Buffers）：在团队依赖链中加入时间缓冲，防止A团队延期导致B团队延期
五、跟踪与沟通（Part V：Tracking and Communicating）
19. 监控发布计划
- 速率计算：全有或全无原则——故事完成才算全部点数，部分完成不计入
- 发布燃尽图（Release Burndown Chart）：纵轴剩余故事点/理想天，横轴迭代次数
- 不总是平滑的：估算不准、需求变更、范围增加都可能导致波动
- 甚至可能出现”燃烧上升”（burnup）：完成了工作但剩余工作量反而增加了（因为发现了更多工作或范围扩大）
- 净进度：燃尽图反映的是进度减去新增工作的净值
- 发布燃尽柱状图：区分计划内进度和范围变更，更有信息量但可能引发组织内争论
- 停车场图（Parking Lot Chart）：高层展示各主题的完成进度
20. 监控迭代计划
- 任务板（Task Board）：列是状态（待办/进行中/完成），团队成员移动任务卡片
- 不提前分配任务，谁有空谁领任务
- 迭代燃尽图：纵轴剩余小时数，横轴迭代天数
- 不建议跟踪实际投入小时：风险和成本通常超过收益
- 不计算个人速率：速率是团队指标，不是个人指标
21. 沟通计划与进度
- 三原则：频繁、诚实、双向
- 甘特图的正确用法：可以用来沟通计划，但不要下钻到功能以下，功能在整个迭代期间都标为”进行中”
- 速率沟通三值法：
- 最近一个迭代的速率（最新情况）
- 过去8个迭代的平均值（长期平均）
- 过去8个迭代中最低3个的平均值（最坏情况）
- 迭代结束摘要报告：既是当前信息的传播，也是未来的历史文档
六、为什么敏捷规划有效（Part VI）
22. 敏捷规划成功的原因
- 多层规划 + 频繁重规划：不是一次性的，而是持续的过程
- 基于功能而非任务：客户价值是规划单位
- 先估规模再推时长：规模和时长分离，更科学
- 小故事保持工作流动：每个迭代末清理在制品（WIP）
- 团队级进度度量：速率是团队指标，鼓励协作而非个人英雄
- 承认并规划不确定性：用缓冲、范围等方式管理不确定性
七、案例研究（Part VII：第23章）
虚构公司 Bomb Shelter Studios 的第一个敏捷项目，通过故事演示全书核心要点的实际应用。
关键概念速查
| 概念 | 一句话解释 |
|---|---|
| 不确定性之锥 | 项目早期估算偏差极大，随推进逐步收敛 |
| 故事点 | 相对规模单位，不对应时间 |
| 理想人天 | 无干扰的专注工作日 |
| 速率 | 团队每迭代完成的故事点 |
| 规划扑克 | 团队估算游戏，同时出牌避免锚定效应 |
| 满意条件 | PO对交付的验收标准 |
| 功能缓冲 | 预留部分功能作为可裁剪项 |
| 进度缓冲 | 预留额外时间应对不确定性 |
| 发布燃尽图 | 剩余工作量随迭代变化的图 |
| 滚动前瞻规划 | 提前看2-3个迭代协调工作 |
关联笔记
- 《Scrum敏捷软件开发》-Succeeding-with-Agile-Mike-Cohn — 同作者 Mike Cohn 的另一本经典，组织级 Scrum 转型
- 《代码整洁之道》-Clean Code-Robert-C-Martin — Robert C. Martin 是敏捷宣言签署者，本书也常被引用
- 《实现模式》-Implementation Patterns-Kent Beck — Kent Beck 是极限编程创始人，敏捷方法论奠基人之一
- 《程序设计实践》-The-Practice-of-Programming-Kernighan-Pike — 软件工程实践经典