软件项目开发全流程 · 第 5 课 · 计划与估算：里程碑与排期
1、为什么"排期"总是崩
几乎每个项目都有同一个场景：计划表上写着"4 月上线"，到了 4 月，进度条停在 60%。
原因通常不是团队不努力，而是估算是拍脑袋的、排期是理想化的、风险是没算的。本课解决三个问题：
- 单个任务的时间，怎么估才不离谱？
- 一堆任务，怎么排出一条真正可行的路？
- 风险和缓冲，怎么留才不是自欺欺人？
2、估算的三种常见错误
错误一：只报"最好情况"。
"这个接口两天能写完。"——对，如果在没有任何打扰、没有任何意外、需求完全清楚的情况下。现实是这种理想状态几乎不存在。
错误二：把"工作量"当成"工期"。
你说 8 小时能写完，不代表明天就能交。因为：会议、评审、等环境、等依赖、改 bug、被插需求……一个人一天真正写代码的时间，往往不到一半。
错误三：把估算当承诺。
估算的本质是"基于当前信息的概率判断"，不是"保证"。把估算硬当 KPI 压下去，团队只会开始虚报工期，估算从此失去意义。
记住：估算不是要"准确"，而是要"透明"——把不确定性和假设摆出来，比给一个漂亮数字更重要。
3、估算法一：三点估算（PERT）
对每个任务估三个值：
- O（Optimistic） 乐观：一切顺利要多久
- M（Most likely） 最可能：正常情况下要多久
- P（Pessimistic） 悲观：处处不顺要多久
计算期望工期（简化版 PERT）：
期望 = （O + 4M + P） / 6
标准差 ≈ （P − O） / 6例子：某任务 O=2 天，M=4 天，P=12 天
- 期望 = (2 + 4×4 + 12) / 6 = 30/6 = 5 天
- 标准差 ≈ (12 − 2)/6 ≈ 1.67 天
比拍一个"4 天"好在哪？它逼你正视悲观情况。而且标准差的道理是：O 和 P 差得越远，说明你越不确定，那就该留更多缓冲（甚至先做个原型验证）。
4、估算法二：故事点与相对估算
绝对估算（"几天"）很难准，因为每个人的"一天"不一样。相对估算换个思路：不比"绝对时间"，只比"相对大小"。
故事点（Story Point） 是给每个任务打一个"大小分"，常用斐波那契数：1、2、3、5、8、13、21。
- 找一个大家都熟悉的最小任务，定为 1 点（基准）。
- 其它任务问："它比基准大几倍？"——"差不多两倍"就是 2，"大很多但不到 5 倍"就取 3 或 5。
- 为什么用斐波那契？因为它故意把数字拉开，逼你放弃"精确到小数点"的错觉，强调"大概是大是小"。
配套概念——团队速度（Velocity）：一个迭代（如两周）团队能完成多少点。比如速度是 20 点/迭代，那么"还剩 60 点的待办"，大概就需要 3 个迭代。
故事点的好处：它天然与个人速度解耦，从而减少了"估少了被骂、估多了被夸"的扭曲动机。
5、估算法三（规划扑克）：让估算变成团队共识
规划扑克（Planning Poker） 是最常用的团队估算玩法：
- 每个人发一副点数牌（1、2、3、5、8、13、21……）。
- 产品经理讲一个任务，讲清验收标准。
- 大家同时亮牌（不许互相看）。
- 如果点数差异大（比如有人出 2、有人出 13），让最小的和最大的各说理由。
- 讨论后重估，直到收敛到一致。
它的价值不在"算出准确数字"，而在把分歧摆到桌面上。出 13 的人往往知道一个别人不知道的坑——这个坑被说出来，就是最大的收获。
6、把任务排成一条路：依赖与关键路径
估算完单个任务，还要排顺序，因为任务之间有依赖。两种基本关系：
- 串行：A 做完才能做 B（总时长 = A + B）
- 并行：A、B 互不依赖，可同时做（总时长 = max(A, B)）
关键路径（Critical Path）：从开始到结束，最长的那条依赖链。它的长度决定了项目最短工期——关键路径上的任何拖延，都会 1:1 地拖延整个项目；非关键路径上拖延一点，可能不影响总工期。
举例：
需求(3天) → 设计(4天) → 开发(10天) → 测试(5天) → 上线(1天) ← 关键路径，合计 23 天
↑
文档(6天) ← 可并行，不占关键路径动手优化的重点永远在关键路径上。 给非关键路径加人，等于白花钱。
7、里程碑与缓冲
里程碑（Milestone） 是计划里几个"零工期"的关键节点，标志着阶段成果达成，例如：
- M1 需求基线确认
- M2 技术方案评审通过
- M3 核心功能可演示
- M4 测试通过 / 上线
里程碑要绑定可验收的标准（"评审通过"要有会议结论，"可演示"要真的有 demo），否则它只是日程表上的装饰。
缓冲（Buffer） 怎么留才科学？两个原则：
- 不要给每个任务偷偷加 20%（这叫"缓冲重复计算"，会让总计划虚胖）。
- 在项目层面统一留缓冲（如总工期的 15%~25%），由项目经理统筹调度。
为什么？ 因为每个人自己加的缓冲会互相叠加，导致"计划看起来很长但没人真的在赶"；而集中缓冲能让团队按真实估算推进，只在真正需要时动用储备。
一条经验：估算时诚实（不藏缓冲），计划时集中留缓冲。
8、从计划到看板：把排期变成可执行
排期不是画完甘特图就完事，还要让它每天能指导行动。最简单的落地方式是把任务变成三列看板：
待办（To Do） │ 进行中（Doing） │ 已完成（Done）规则：
- 限制"进行中"的数量（如每人不超过 2 个），防止多任务切换导致的效率损失。
- 每天同步一次：昨天做了什么、今天做什么、有什么阻塞（第 17 课展开）。
- 完成的定义（DoD）要写清楚：代码写完 ≠ 完成，要含评审、测试通过、可演示。
看板让"计划"从纸上的日期，变成每天都能看到、能调整的流动。
9、动手实验 🎯
任务：用三种方法给你的 WBS 做一次估算与排期。
- 从第 4 课的 WBS 里挑 5 个任务，对每个任务做三点估算，算出期望工期。
- 用故事点给这 5 个任务打相对分，找一个最小任务定为 1 点。
- 画一张简版依赖图，找出关键路径，算出项目最短工期。
回答两个问题：
- "如果只给一半时间，你会砍哪些任务？"（回到第 4 课优先级）
- "哪些并行任务有隐藏依赖？"（比如"联调"必须等对方接口）
- 设 3 个里程碑，每个写一条可验收标准。
- 给总工期留一个集中缓冲（如 20%），并说明理由。
做完这步，你就有了一份能站得住、也说得清假设的初版计划。
10、今天你带走的三句话
- 估算不是承诺：三点估算逼你正视悲观情况，故事点帮你甩开"绝对天数"的错觉。
- 优化的重点永远在关键路径上——它决定了项目最短工期。
- 任务级估算要诚实，项目级缓冲要集中留；别在每个人那里偷偷加 20%。
第一阶段到这里结束。我们已经完成了"想清楚该不该做、做成什么、怎么排"。下一课开始进入第二阶段：需求与设计——先学怎么把用户嘴里的"我想要"，变成团队手上一份清清楚楚的需求。