# 工作量评估方法
本文档介绍持续迭代项目中的需求工作量评估方法，帮助团队准确估算开发工作量。
# 📊 主流评估方法对比
| 方法 | 适用场景 | 精度 | 耗时 | 推荐度 |
|---|---|---|---|---|
| 故事点估算 | 敏捷迭代 | 中 | 低 | ⭐⭐⭐⭐⭐ |
| 计划扑克 | 团队估算 | 中高 | 中 | ⭐⭐⭐⭐⭐ |
| T 恤尺码法 | 初期粗估 | 低 | 极低 | ⭐⭐⭐⭐ |
| 三点估算法 | 不确定性高 | 中高 | 中 | ⭐⭐⭐⭐ |
| 类比估算 | 有历史数据 | 中 | 低 | ⭐⭐⭐⭐ |
| 功能点分析 | 传统项目 | 高 | 高 | ⭐⭐⭐ |
# 🎯 推荐方法：故事点估算法
# 📋 什么是故事点
故事点（Story Points） 是一种相对估算单位，用于衡量用户故事的复杂度、工作量、风险、不确定性的综合指标。
故事点 = 复杂度 + 工作量 + 风险 + 不确定性
1
# 🔢 估算尺度（斐波那契数列）
| 点数 | 工作量 | 说明 | 示例 |
|---|---|---|---|
| 1 | 极小 | 1-2 小时，简单修改 | 修改按钮文字 |
| 2 | 小 | 半天内，单一功能 | 新增一个表单字段 |
| 3 | 中等 | 1-2 天，常规功能 | 新增一个 CRUD 页面 |
| 5 | 较大 | 3-5 天，涉及多模块 | 集成第三方 API |
| 8 | 大 | 1-2 周，复杂功能 | 新增一个完整小模块 |
| 13 | 很大 | 2-3 周，高复杂度 | 涉及架构调整,核心功能重构等 |
| 21+ | 过大 | 需要拆分 | 史诗级需求,需要技术攻关 |
# 🃏 计划扑克估算法
# 会议流程
┌─────────────────────────────────────────────────────────────────┐
│ 计划扑克估算会议 │
│ 时长：1-2 小时/迭代 │
└─────────────────────────────────────────────────────────────────┘
参与者：PO + 开发团队 + Scrum Master
【估算流程】
1. PO 讲解用户故事（5 分钟/故事）
2. 团队提问澄清（5 分钟/故事）
3. 每人私下选择故事点牌
4. 同时亮牌
5. 如有差异，讨论原因
6. 重新估算直至收敛
7. 记录最终故事点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 估算牌面值
┌───┬───┬───┬───┬───┬───┬────┬────┬────┐
│ 0 │ ½ │ 1 │ 2 │ 3 │ 5 │ 8 │ 13 │ 20 │
├───┼───┼───┼───┼───┼───┼────┼────┼────┤
│ ? │ ☕ │ ∞ │ │ │ │ │ │ │
└───┴───┴───┴───┴───┴───┴────┴────┴────┘
? = 不清楚 ☕ = 需要休息 ∞ = 太大无法估算
1
2
3
4
5
6
2
3
4
5
6
# 📝 操作步骤
# 步骤 1：建立基准故事
选择团队熟悉的 2-3 个已完成故事作为基准：
## 基准故事示例
### 基准故事 A（3 点）
**标题：** 用户信息编辑页面
**工作内容：**
- 新增用户信息编辑表单
- 表单验证（必填、格式）
- 保存和取消功能
- 成功后跳转
**实际耗时：** 1.5 天
---
### 基准故事 B（5 点）
**标题：** 微信登录集成
**工作内容：**
- 微信 OAuth2.0 接入
- 用户信息获取
- 账号绑定逻辑
- 异常处理
**实际耗时：** 4 天
---
### 基准故事 C（8 点）
**标题：** 订单导出功能
**工作内容：**
- 多条件筛选
- Excel 导出（多 Sheet）
- 异步任务处理
- 邮件通知
**实际耗时：** 7 天
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 步骤 2：需求澄清
PO 讲解用户故事：
- 用户故事描述
- 验收标准
- 业务价值
- 优先级
团队提问澄清：
- 技术实现方式
- 依赖关系
- 潜在风险
- 不确定性因素
# 步骤 3：独立估算
每人私下选择故事点牌：
- 基于基准故事对比
- 考虑复杂度、工作量、风险
- 不受他人影响
# 步骤 4：讨论差异
如果估算差异大（如有人出 3 点，有人出 8 点）：
- 请出最高点和最低点的人说明理由
- 讨论各自考虑的因素
- 澄清误解或遗漏
- 重新估算直至收敛
# 步骤 5：记录结果
| 用户故事 | 复杂度 | 工作量 | 风险 | 不确定性 | 故事点 |
|---|---|---|---|---|---|
| 用户登录 | 2 | 2 | 1 | 1 | 3 |
| 微信支付 | 5 | 5 | 3 | 3 | 8 |
| 数据导出 | 3 | 5 | 2 | 2 | 5 |
| 报表统计 | 5 | 8 | 3 | 5 | 13 |
# 👕 T 恤尺码估算法
# 适用场景
- 项目初期粗估
- 产品路线图规划
- 需求优先级排序
# 尺码对照表
| 尺码 | 故事点 | 工作量 | 说明 |
|---|---|---|---|
| XS | 1-2 | < 1 天 | 非常简单 |
| S | 3 | 1-2 天 | 简单 |
| M | 5 | 3-5 天 | 中等 |
| L | 8-13 | 1-3 周 | 复杂 |
| XL | 20+ | > 3 周 | 非常复杂（需拆分） |
# 操作示例
## 需求粗估
| 需求 | T 恤尺码 | 备注 |
|------|----------|------|
| 用户注册 | S | 标准功能 |
| 微信支付 | L | 需要资质申请 |
| 数据报表 | XL | 需要拆分 |
| 短信通知 | M | 有现成 SDK |
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
# 📐 三点估算法（PERT）
# 理论基础
源自 PERT（Program Evaluation and Review Technique）技术
期望值 E = (乐观 O + 4 × 最可能 M + 悲观 P) ÷ 6
标准差 σ = (P - O) ÷ 6
1
2
3
2
3
# 实际操作
| 估算项 | 乐观 (O) | 最可能 (M) | 悲观 (P) | 期望值 (E) |
|---|---|---|---|---|
| 用户模块 | 3 天 | 5 天 | 10 天 | (3+20+10)/6 = 5.5 天 |
| 支付模块 | 5 天 | 8 天 | 15 天 | (5+32+15)/6 = 8.7 天 |
| 报表模块 | 8 天 | 12 天 | 20 天 | (8+48+20)/6 = 12.7 天 |
# 优点
- ✅ 考虑不确定性
- ✅ 给出范围而非单点
- ✅ 适合风险评估
# 📚 类比估算法
# 理论基础
基于历史数据的类比推理
新项目工作量 = 类似历史项目工作量 × 调整系数
1
# 操作步骤
- 查找历史类似需求
- 记录实际工作量
- 识别差异因素
- 应用调整系数
- 得出估算结果
# 示例
## 历史数据参考
### 类似需求：支付宝支付（已完成）
**实际工作量：** 8 故事点，6 天
### 新需求：微信支付
**相似点：**
- 都是第三方支付
- 都需要 OAuth 流程
- 都有回调处理
**差异点：**
- 微信需要公众号配置（+1 天）
- 团队对微信更熟悉（-1 天）
**估算结果：** 8 故事点，6 天
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# ⚠️ 影响工作量的因素
# 评估维度
┌─────────────────┐
│ 工作量评估 │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 技术因素 │ │ 业务因素 │ │ 团队因素 │
├───────────────┤ ├───────────────┤ ├───────────────┤
│ • 技术复杂度 │ │ • 需求清晰度 │ │ • 团队经验 │
│ • 集成难度 │ │ • 业务规则 │ │ • 人员稳定性 │
│ • 性能要求 │ │ • 合规要求 │ │ • 协作效率 │
│ • 安全要求 │ │ • 用户数量 │ │ • 工具熟练度 │
│ • 技术债务 │ │ • 变更频率 │ │ • 知识储备 │
└───────────────┘ └───────────────┘ └───────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 评估检查清单
## 技术复杂度检查
- [ ] 是否涉及新技术？
- [ ] 是否需要第三方集成？
- [ ] 是否有性能要求？
- [ ] 是否有安全要求？
- [ ] 是否有技术债务需要处理？
## 业务复杂度检查
- [ ] 需求是否清晰？
- [ ] 业务规则是否复杂？
- [ ] 是否涉及多部门协作？
- [ ] 是否有合规要求？
- [ ] 变更频率如何？
## 团队能力检查
- [ ] 团队是否有相关经验？
- [ ] 是否需要培训？
- [ ] 人员是否稳定？
- [ ] 工具是否熟悉？
- [ ] 是否有可用资源？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 📊 估算记录模板
## 迭代 X - 需求估算表
| 用户故事 | 估算点 | 实际点 | 偏差率 | 备注 |
|----------|--------|--------|--------|------|
| 用户登录 | 3 | 3 | 0% | 准确 |
| 微信支付 | 8 | 13 | +62% | 第三方文档不全 |
| 数据导出 | 5 | 5 | 0% | 准确 |
| 报表统计 | 13 | 8 | -38% | 复用已有组件 |
**迭代速度：** 29 点（估算）vs 29 点（实际）
**准确度：** 85%
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
# ✅ 最佳实践
# 估算原则
- 团队估算 - 避免个人偏见
- 相对估算 - 用故事点而非小时
- 持续校准 - 定期回顾调整
- 考虑风险 - 包含不确定性因素
- 记录历史 - 积累估算数据
# 常见误区
| 误区 | 问题 | 建议 |
|---|---|---|
| 领导指定工时 | 忽略团队意见 | 团队共同估算 |
| 追求 100% 准确 | 估算不是承诺 | 接受合理偏差 |
| 忽略技术债务 | 低估工作量 | 包含重构时间 |
| 不考虑风险 | 过于乐观 | 使用三点估算 |
| 不记录历史 | 无法改进 | 建立估算数据库 |
# 🛠️ 工具推荐
# 估算工具
| 工具 | 类型 | 特点 |
|---|---|---|
| Jira | 项目管理 | 内置故事点估算 |
| Trello + 扑克插件 | 看板 | 轻量级计划扑克 |
| Planning Poker Online | 在线工具 | 远程团队适用 |
| Excel/表格 | 手工 | 灵活定制 |
# 度量指标
| 指标 | 公式 | 目标 |
|---|---|---|
| 估算准确度 | 1 - |实际 - 估算|/估算 | > 80% |
| 迭代速度 | 完成故事点/迭代 | 稳定 |
| 速度偏差 | (最大速度 - 最小速度)/平均 | < 20% |
# 📚 理论支持
# 敏捷估算理论
| 理论 | 来源 | 核心观点 |
|---|---|---|
| 计划扑克 | James Grenning (2002) | 群体智慧，减少锚定效应 |
| 故事点估算 | Extreme Programming | 相对估算优于绝对估算 |
| 宽带德尔菲 | RAND Corporation | 专家群体估算更准确 |
| PERT 技术 | 美国海军 (1958) | 三点估算处理不确定性 |
# 参考书籍
- 《敏捷估算与规划》- Mike Cohn
- 《用户故事地图》- Jeff Patton
- 《Scrum 精髓》- Kenneth S. Rubin
- 《软件估算：揭示黑艺术》- Steve McConnell
# 🎯 DarkM 项目实施建议
# 推荐方案
估算方法：故事点 + 计划扑克
估算尺度：斐波那契数列 (1,2,3,5,8,13,21)
估算时机：迭代计划会
参与者：PO + 全体开发团队
记录方式：估算表 + 实际跟踪
改进机制：迭代回顾会分析偏差
1
2
3
4
5
6
2
3
4
5
6
# 实施步骤
- 建立基准故事库（第 1 个迭代）
- 需求澄清（迭代计划会）
- 计划扑克估算
- 记录与跟踪
- 持续改进（迭代回顾会）
# 预期效果
- ✅ 估算准确度逐步提升至 80%+
- ✅ 迭代速度趋于稳定
- ✅ 团队对需求理解更一致
- ✅ 减少加班和延期风险
# 🔗 相关文档
最后更新： 2022-12-15
← 方法论选择 搭建 Git 服务器 →