05 - 任务与冲刺：需求切片 → 团队执行

任务系统是项目的"血液循环"——它在，团队有节奏；它不在，团队瘫痪。任务不是"工单"，是"决策的执行单元"。

一句话

任务系统 = 单一事实来源 + 实时进展 + 阻塞快速暴露——任何任务超过 3 天未动 = 必有阻碍。

任务的 3 层分解

Epic → Story → Task（INCOSE 实践）：

Epic（史诗，季度级）
   代表一个完整的业务能力
   例："支付系统上线"
   ↓
Story（故事，1-2 周）
   代表一个可独立交付的用户价值
   例："用户能通过微信支付完成支付"
   ↓
Task（任务，1-3 天）
   代表一个具体技术工作
   例："对接微信支付 SDK"

反模式：Epic 直接到 Task——失去"业务价值"中间层。

Issue 模板

每个 Story 必须包含：

markdown

## 标题
[明确具体的标题]

## 类型
- [ ] Bug
- [ ] Feature（功能）
- [ ] Tech Debt（技术债）
- [ ] Spike（调研）

## 优先级
- [ ] P0 紧急（24h 内）
- [ ] P1 高（本周）
- [ ] P2 中（本月）
- [ ] P3 低（本季度）

## 业务背景
[为什么做这个 + 业务影响]

## 用户故事
作为 [角色]
我想要 [功能]
以便于 [价值]

## 验收标准
- [ ] [验收 1]
- [ ] [验收 2]

## 技术约束
- 依赖 ADR-XXX
- 需要前置 Story 链接

## 设计稿 / 文档
[Figma 链接 / Notion 链接]

## 估算
[X 人天 或 X 故事点]

## 依赖
- 被 [Issue 链接] 阻塞
- 阻塞 [Issue 链接]

## 标签
[模块名] [优先级] [季度]

Task 模板（更简单）：

markdown

## 标题
[具体动作]

## 验收标准
- [ ] [可立即验证的标准]

## 估算
[X 人天 / 半天 / 2 小时]

## 父 Story
[Story 链接]

任务看板的 6 列

看板视图是任务进展的唯一显示：

┌──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│  Backlog │  To Do   │ In Prog  │ In Review│   QA     │   Done   │
│ (候选)   │ (本周做) │ (在做中) │ (评审中) │ (测试中) │ (已完成) │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘

关键规则：

Backlog → To Do：本 Sprint 决定要做
To Do → In Progress：开始动手
In Progress → In Review：提 PR
In Review → QA：Review 通过
QA → Done：QA 通过

WIP 限制（Work In Progress Limit）：

每个开发最多同时 2-3 个 In Progress
超过 = 必须先完成一个才能开新
这是防止"多任务切换"的关键

估算方法

T-shirt 估算（粗估）

XS: < 0.5 天
S:  0.5-1 天
M:  1-3 天
L:  3-7 天
XL: > 1 周（必须拆分）

适用：季度规划、需求优先级。

故事点 / Fibonacci（细估）

1   半天
2   1 天
3   2-3 天
5   1 周
8   2 周（警惕）
13  需要拆分
21  必须拆分

适用：Sprint 计划、Velocity 计算。

Planning Poker 流程

每个 Story 1 张卡
PM 念需求
每人独立选点数（不讨论）
公开看，如果差距大讨论
共识后记录

目的：让"看上去简单"的任务暴露真实复杂度（开发考虑依赖、技术债、测试等）。

Sprint 节奏（Scrum）

2 周 Sprint 标准流程

Sprint 第 1 天：Sprint Planning（2-4 小时）
   - PM 介绍优先级需求
   - 团队认领任务
   - 估算工作量
   - 确认 Sprint Goal

Sprint 第 2-9 天：执行
   - 每日 Standup（15 分钟）
   - Code Review（持续）
   - 沟通阻塞
   - 持续集成

Sprint 第 10 天：Sprint Review + Demo
   - 给利益相关者看 Demo
   - 收集反馈

Sprint 第 10 天：Sprint Retrospective
   - 团队复盘
   - "什么做对 / 什么做错 / 下次改什么"

反模式：Sprint 变成"工单流水线"

症状：Sprint 只是"分任务、做任务、交任务"，没有 Sprint Goal。

修复：每个 Sprint 有 1 个 Sprint Goal（"本 Sprint 完成核心订单流程"），所有任务对齐这个目标。

看板（Kanban）vs Sprint（Scrum）

维度	看板（Kanban）	冲刺（Sprint）
时间盒	无固定时间盒	2 周 / 4 周
节奏	持续流动	周期迭代
适用	维护 / 运维 / 持续支持	新产品 / 新功能
计划	持续进行	周期计划
度量	Cycle Time	Velocity
团队	通常成熟	各种
反馈周期	随时	Sprint 末

SE@Google 实践：大部分团队用看板，但有季度里程碑做节奏——结合两者的优点。

任务系统的反模式（6 种）

1. 任务是大杂烩

❌ "做支付系统" ✅ "对接微信支付 API" + "对接支付宝 API" + "退款逻辑"

2. 任务没有验收标准

结果：做完不知道对不对

3. 任务没有估算

结果：无法排期，无法评估负载

4. 任务一直 In Progress

结果：阻塞 / 失败 / 放弃都看不出来

5. 一个人同时 5 个 In Progress

结果：所有任务都慢（任务切换成本）

6. 不写 Issue Title

❌ "修一下"、"接口报错" ✅ "修复用户登录 500 错误（边界：空密码）"

跨团队任务协调

当一个改动涉及 3+ 个团队时：

1. 创建"协调 Issue"

一个人作为协调负责人
链接所有相关 Issue
协调 Issue 包含完整时间线

2. 协调会议（如果必要）

第一次：所有团队对齐方案
中期：进度同步
完成：清理 + 文档

3. 跨团队依赖管理

Issue A 依赖 Issue B
   ↓
B 必须先合并（标记为"阻塞"）
   ↓
A 才能开始
   ↓
Jira/Plane 自动跟踪

反模式：口头依赖 = 没依赖。必须链接。

看板与 Sprint 的工具栈

看板（小型）：

GitHub Projects
Trello
Notion 看板
Plane 开源版

Sprint（中型）：

Jira + Scrum 模板
Linear
Plane Cloud

跨团队协调（大型）：

Jira + Advanced Roadmaps（原 Portfolio）
自建仪表盘
飞书项目 / 钉钉项目

关键指标

Velocity（团队速率）

Sprint Velocity = 本 Sprint 完成的 Story 点数总和

用途：
- 预测下个 Sprint 能做多少
- 防止过度承诺（History 最大 Velocity 80%）
- 跟踪团队效率变化（不是让人加速，是看长期趋势）

Cycle Time

Cycle Time = Issue 从 "In Progress" 到 "Done" 的时间

用途：
- 找阻塞点（Cycle Time 突然变长 = 有阻碍）
- 跟 Velocity 互补（Velocity 是吞吐，Cycle Time 是延迟）

Burndown Chart

Sprint Burndown = 剩余工作量 vs 时间

用途：
- 一眼看出 Sprint 是否按计划
- 提早发现"完成不了"

任务优先级 vs 重要性

优先级（什么时候做）× 重要性（做了影响多大）= 决策矩阵

                高重要      低重要
高优先级      [做]         [做]
低优先级      [找时间做]   [不做]

反模式：只做"紧急的事"，不重视"重要的事"——3 个月后紧急的事没减少。

修复：每个 Sprint 强制 20% 留给"重要但不紧急"（如技术债、文档）。

Standup 模板（每日 15 分钟）

格式 A（轮流式）：

每人 1 分钟说 3 件事：
1. 昨天做了什么
2. 今天计划做什么
3. 有什么阻塞（需要谁帮忙）

格式 B（看板式）：

从右往左过看板，看每张卡：
- 卡停在某列 = 谁遇到阻碍
- 阻塞当场分配解决人
- Sprint Goal 进度如何

Standup 不是汇报工作！——是同步阻塞。如果变汇报，开错会了。

任务完成的"完成定义"（DoD）

"完成"的明确标准——避免"我觉得完成了但 PM 觉得没完成"：

【完成的定义 DoD】
- [ ] 代码已提交并通过 CI
- [ ] 单元测试覆盖（关键路径）
- [ ] Code Review 至少 2 人 Approve
- [ ] 验收标准全部勾选
- [ ] 文档更新（如有改动）
- [ ] 部署到测试环境验证通过
- [ ] 相关利益相关者验收
- [ ] 不留遗留 tech debt（除非有跟进 issue）

进入下一章

任务管理完成后，下一步：

06 代码与评审——把任务转成可合并的代码

作者：基于 SE@Google Ch22 (Coordination) + INCOSE C05 (Project Planning) + Jira/Plane 实践综合 最后更新：2026-06-28

05 - 任务与冲刺：需求切片 → 团队执行 ​

一句话 ​

任务的 3 层分解 ​

Issue 模板 ​

任务看板的 6 列 ​

估算方法 ​

T-shirt 估算（粗估） ​

故事点 / Fibonacci（细估） ​

Planning Poker 流程 ​

Sprint 节奏（Scrum） ​

2 周 Sprint 标准流程 ​

反模式：Sprint 变成"工单流水线" ​

看板（Kanban）vs Sprint（Scrum） ​

任务系统的反模式（6 种） ​

1. 任务是大杂烩 ​

2. 任务没有验收标准 ​

3. 任务没有估算 ​

4. 任务一直 In Progress ​

5. 一个人同时 5 个 In Progress ​

6. 不写 Issue Title ​

跨团队任务协调 ​

1. 创建"协调 Issue" ​

2. 协调会议（如果必要） ​

3. 跨团队依赖管理 ​

看板与 Sprint 的工具栈 ​

关键指标 ​

Velocity（团队速率） ​

Cycle Time ​

Burndown Chart ​

任务优先级 vs 重要性 ​

Standup 模板（每日 15 分钟） ​

任务完成的"完成定义"（DoD） ​

进入下一章 ​