📚 课程目录第2章项目规划与敏捷流程

项目规划与敏捷流程：任务分解、时间估算、里程碑、Sprint计划

需求确认之后，很多人第一反应就是「赶紧写代码」。但我的经验告诉我——规划没做好，后面全是坑。你想想看，一个项目连任务都没拆清楚，怎么敢拍胸脯说什么时候能交付？

这一章，我带你走一遍项目规划的核心环节。说白了，就是从「我们要做什么」到「我们怎么落地，多久干完」的过程。

  核心逻辑： 需求 → 任务分解（WBS） → 工作量估算 → 里程碑设定 → Sprint计划 → 迭代执行。每一步都影响着后续的节奏和风险。

2.1 任务分解：从用户故事到WBS

我个人习惯，拿到梳理好的用户故事后，第一件事就是做工作分解结构（WBS）。很多人觉得WBS是传统项目管理那套东西，跟敏捷不搭。其实不然——敏捷只是迭代节奏变了，该拆的活一点不能少。

任务分解讲究一个原则：MECE（相互独立，完全穷尽）。一个大的用户故事，得拆成若干个可独立交付、可独立测试的小任务。每个小任务最好控制在1-2天的工作量。为什么？你想想看，一个任务如果排了10天，中间出了任何问题，整个迭代都得翻车。

用户故事	WBS 任务分解	预估工时
用户登录能力	设计数据库表结构	0.5人天
	开发登录 API	1.5人天
	开发前端登录页面	1人天
	集成测试与联调	0.5人天

避坑经验： 我曾经有一个项目，任务分解做得太粗，一个任务排了5天。做到第3天发现方向错了，不仅这5天白费，还拖了整个Sprint的后腿。从那以后，超过3天的任务我强制要求再拆一层。

2.2 时间估算：故事点与规划扑克

时间估算，说白了就是回答一个问题：「这事多久能干完？」但你要是直接让开发报天数，十有八九会被骂。为什么？因为人的天性就是过于乐观和自我防御的矛盾体。

我推荐用故事点（Story Point）来估算。故事点不关心具体小时数，只关心相对大小。比如，定义一个「简单任务」为1点，那么一个「中等任务」可能是3点，一个「大任务」可能是8点。

  估算尺度的参考表（常用斐波那契数列）：

  1、2、3、5、8、13、21。超过21的任务，必须再拆分。

具体怎么估？我们用规划扑克（Planning Poker）。团队坐一起，针对每个用户故事，每人出牌（1/2/3/5/8...）。如果差距大，高点的人和低点的人各自解释理由，然后重新出牌，直到趋近一致。

小技巧： 我发现，用规划扑克不仅仅是为了得出一个数字。更重要的是，在出牌和讨论的过程中，团队把潜在风险暴露出来了。比如有人给8点，有人给3点。一问才知道，给8点的人担心一个外部接口不稳定，给3点的人觉得那个接口很稳。你看，这个讨论比数字本身值钱多了。

估算完故事点，再结合团队的Velocity（速率）——也就是一个Sprint能干完多少点——就能倒推出大概要几个Sprint。比如说，一个项目一共80个故事点，团队上两个Sprint各完成了20点，那你的Velocity就是20点/Sprint。预估完：80 ÷ 20 = 4个Sprint。

2.3 里程碑：关键节点与渐进式交付

里程碑是项目管理里最容易被忽视的。很多团队只设一个里程碑：上线。这不叫里程碑，叫赌命。

我的做法是：每个里程碑都是一个「有意义的可交付实体」。比如：

M1（第2周结束）： 用户注册与登录MVP可用（含后端API + 前端页面）
M2（第5周结束）： 核心业务功能可操作（含订单创建、支付回调）
M3（第8周结束）： 搜索与推荐功能上线（含数据埋点）
M4（第10周结束）： 性能优化与安全加固（含压力测试报告）

里程碑	阶段	关键交付物	验收条件
M1	基础能力	用户管理、登录界面	通过 3 个用户故事验收
M2	核心链路	下单、支付、通知	端到端流程跑通
M3	增强功能	搜索、推荐、数据看板	搜索准确率 > 85%
M4	上线前	性能报告、安全扫描报告	QPS ≥ 1000，无高危漏洞

注意： 里程碑不是拍脑袋定的。我建议留出10%-15%的缓冲时间。因为中途需求变更、线上事故、人员请假，这些都是常态。缓冲就是用来对付这些「不一定发生但一定会发生」的事的。

2.4 Sprint计划：固定节奏，灵活范围

Sprint是敏捷的节奏心脏。我个人偏好2周一个Sprint。太短（比如1周）容易让团队来不及反应；太长（比如4周）又会失去敏捷的「快速响应」价值。

Sprint计划会议的核心，就是回答两个问题：

这个Sprint我们要做什么？（从Product Backlog里挑出优先级最高的用户故事）
怎么把它做完？（把用户故事拆成任务，分配给具体的人）

具体步骤：

第一步： PO（产品负责人）介绍Sprint目标。比如「这个Sprint要打通支付流程」。
第二步： 团队评估能拿多少故事点进Sprint Backlog。参考Velocity，但不要满打满算。
第三步： 将用户故事拆为任务，每个任务明确负责人和预计工时。
第四步： 确认依赖关系和风险。比如前端依赖后端API，后端得提前半天交付。

  核心原则： Sprint期间不能随意变更范围。如果中途来了紧急需求，要么替换同等规模的低优任务，要么搁置到下个Sprint。千万不要在迭代中间随意追加——我见过太多团队因为这个做法，Sprint从未按时完成过。

避坑指南：我曾经带过一个团队，每次Sprint计划会都超2小时。大家都太乐观，把积压的Backlog一股脑往里塞。后来我强制：Sprint计划会限时1小时，超时不议，遗留的问题到明日站会再聊。反而效率提升了不少。

2.5 风险规划：提前识别，主动应对

项目规划如果你只关注任务和时间，那你只是个调度员。真正优秀的规划，一定包含风险预案。

我常用的风险清单模板：

技术风险： 新技术不熟悉、第三方服务不稳定
人员风险： 核心人员请假、沟通不畅
需求风险： 需求频繁变更、验收标准模糊
外部风险： 交付依赖方延期、政策变化

风险类型	具体描述	概率	影响	应对措施
技术风险	支付网关接口文档不完整	高	高	提前安排技术预研，准备备选方案
人员风险	核心后端人员请假	中	高	培养跨职能的备份人员
需求风险	业务方反复变更字段	高	中	明确变更窗口，超时变更下个迭代排期

提醒： 风险清单不是列出来就完了。我习惯在每日站会上花2分钟过一下，问「上周识别出来的XX风险，现在状态如何？」。把它变成团队的习惯，而不是文档里的摆设。

项目规划做到这一步，你手里应该有：

一份WBS任务清单，每项任务不超过3天
一份故事点估算表，搭配团队Velocity
一份里程碑计划，带缓冲时间
一份Sprint计划，包含目标和任务分配
一份风险清单，含应对方案

这些东西看起来多，但我可以负责任地说：一个花了3小时认真做规划的项目，至少能帮你省下30小时的返工时间。你品，你细品。