estimation

估算

何时使用此技能

在以下情况下使用此技能：

• 估算任务 - 处理类比估算、参数估算、三点估算和专家判断等估算技术。为项目、功能和任务提供工作量、成本、工期和复杂度估算
• 规划或设计 - 需要估算方法方面的指导
• 最佳实践 - 希望遵循成熟的模式和标准

概述

使用经过验证的估算技术，系统地估算工作量、成本、工期和复杂度。支持针对项目、功能和任务的类比估算、参数估算、三点估算（PERT）和专家判断方法。

什么是估算？

估算是预测完成工作所需资源、时间和成本的过程。良好的估算需要平衡：

• 准确性：与实际结果的接近程度
• 精确性：估算结果的一致性
• 速度：生成估算所需的时间
• 沟通：对不确定性的共同理解

估算与承诺的区别

概念	定义	用途
估算	根据当前知识做出的最佳判断	规划、预测
承诺	承诺在指定日期前或预算内交付	合同、截止期限
目标	希望努力实现的结果	目标、目的

关键原则： 估算是包含不确定性的范围，而不是单点保证。

估算技术

类比估算（自上而下）

基于类似的历史工作进行估算：

步骤	操作
1	找出类似的已完成项目/功能
2	获取实际工作量/成本/工期
3	根据差异进行调整（复杂度、团队、技术）
4	应用调整系数

公式：

New Estimate = Historical Actual × Adjustment Factor

Example:
Similar project took 200 hours
New project is ~20% more complex
Estimate = 200 × 1.20 = 240 hours

适用场景： 早期阶段、细节有限、拥有历史数据的经验丰富团队

准确度： +/- 25-50%（有良好的历史数据时会提高）

参数估算

使用统计关系进行估算：

要素	说明
工作单位	可衡量的要素（屏幕、API、表）
生产率	根据历史数据得出的每单位工作量
数量	需要产出的单位数

公式：

Estimate = Quantity × Productivity Rate

Example:
10 API endpoints × 16 hours/endpoint = 160 hours

常见生产率指标：

工作类型	指标	典型范围
UI 屏幕	小时/屏幕	8-40 小时
API 端点	小时/端点	4-24 小时
数据库表	小时/表	4-16 小时
测试用例	小时/测试	0.5-4 小时
文档页面	小时/页	2-8 小时

适用场景： 可重复的工作、良好的历史数据、相似的技术

准确度： +/- 15-25%（使用经过校准的生产率时）

三点估算（PERT）

使用乐观、最可能和悲观值进行估算：

值	符号	定义
乐观	O	最佳情况，一切顺利
最可能	M	最有可能出现的结果
悲观	P	最差情况，问题出现

PERT 公式（加权平均）：

Expected = (O + 4M + P) / 6
Standard Deviation = (P - O) / 6

Example:
O = 5 days, M = 8 days, P = 17 days
Expected = (5 + 4×8 + 17) / 6 = 9 days
Std Dev = (17 - 5) / 6 = 2 days

置信区间：

置信度	计算方式	示例（E=9，SD=2）
68%	E ± 1 SD	7-11 天
95%	E ± 2 SD	5-13 天
99.7%	E ± 3 SD	3-15 天

适用场景： 不确定的工作、新技术、需要传达风险时

准确度： 明确提供不确定性范围

专家判断

基于专家集体知识进行估算：

宽带德尔菲法：

轮次	活动
1	专家独立估算
2	收集并分享匿名估算
3	讨论过高或过低的异常值，并分享理由
4	独立重新估算
5	重复上述过程，直到达成一致（或取平均值）

规划扑克（敏捷）：

步骤	操作
1	展示待估算事项
2	简短讨论（2-5 分钟）
3	每位团队成员私下选择卡片
4	同时亮出卡片
5	讨论异常值
6	重复投票，直到达成共识

常见量表：

量表类型	数值
斐波那契数列	1, 2, 3, 5, 8, 13, 21, 34, 55, 89
修改后的斐波那契数列	0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100
T 恤尺码	XS, S, M, L, XL, XXL
2 的幂	1, 2, 4, 8, 16, 32, 64

适用场景： 工作复杂、需要多种视角、团队达成一致

功能点分析

基于功能规模进行估算（适用于较大型系统）：

组件	描述	权重范围
外部输入	进入系统的数据	3-6
外部输出	离开系统的数据	4-7
外部查询	只读查询	3-6
内部文件	逻辑数据存储	7-15
外部接口	共享数据	5-10

流程：

1. 统计每种组件的数量
2. 划分复杂度（低／中／高）
3. 应用权重
4. 计算未调整功能点
5. 应用技术复杂度因子

适用场景： 大型项目、正式合同、行业基准对比

相对估算

故事点

用于衡量相对复杂度／工作量：

点数	相对规模	示例
1	微不足道	修正拼写错误、更改配置
2	简单	简单的错误修复、小功能
3	中等	标准功能、中等复杂度
5	复杂	多组件功能
8	非常复杂	集成工作、存在大量未知因素
13	史诗级	考虑拆分
21+	过大	必须拆分

基准： 选择一个理解透彻的故事作为参考（例如：“这是一个 3”）

速度： 每个迭代完成的故事点数（用于预测）

T 恤尺码估算

用于路线图规划的快速相对估算：

尺码	工作量范围	持续时间范围
XS	1-4 小时	< 1 天
S	0.5-2 天	1-2 天
M	2-5 天	3-5 天
L	1-2 周	1-2 周
XL	2-4 周	2-4 周
XXL	1-3 个月	过大，需要拆分

工作流

阶段 1：准备

步骤 1：明确范围

## Estimation Request

**Item:** [What's being estimated]
**Requester:** [Who needs the estimate]
**Purpose:** [Planning/budgeting/commitment]
**Deadline:** [When estimate is needed]
**Precision:** [ROM/Budget/Definitive]

### Scope Definition

- **In Scope:** [What's included]
- **Out of Scope:** [What's excluded]
- **Assumptions:** [Key assumptions]
- **Constraints:** [Known constraints]

步骤 2：选择估算技术

情况	推荐技术
项目早期阶段	类比估算 + T 恤尺码估算
需求详细	参数估算 + 三点估算
敏捷待办事项	故事点 + 规划扑克
新技术／新领域	专家判断 + 三点估算
合同／预算	功能点 + 参数估算

阶段 2：估算

步骤 1：分解工作

将工作拆分为可估算的单元（半天到 2 周的工作量）

步骤 2：应用技术

使用上述选定的技术

步骤 3：增加应急储备

## Contingency Calculation

| Risk Level | Contingency | When to Use |
|------------|-------------|-------------|
| Low | 10-15% | Well-understood, experienced team |
| Medium | 20-30% | Some unknowns, new team members |
| High | 40-50% | Significant unknowns, new technology |
| Very High | 75-100% | Research, innovation, first-of-kind |

步骤 4：验证

• 与类似工作进行合理性检查
• 与团队一起审查
• 检查是否有遗漏事项
• 验证假设

阶段 3：沟通

步骤 1：以范围表示

## Estimate Summary

**Effort:** 160-200 hours (confidence: 80%)
**Duration:** 4-5 weeks (with 2 developers)
**Cost:** $24,000-$30,000

**Key Risks:**
- API integration complexity unknown
- Dependency on third-party availability

步骤 2：记录假设

## Estimation Assumptions

1. Requirements are stable and complete
2. Team has 80% availability (20% overhead)
3. No major technology changes
4. Dependencies delivered on time
5. [Additional assumptions...]

**If assumptions change, estimate should be revisited.**

输出格式

叙述性摘要

## Estimation Summary

**Item:** [Feature/Project name]
**Date:** [ISO date]
**Estimator:** estimation-analyst
**Technique:** [Technique used]

### Estimate

| Dimension | Low | Expected | High | Confidence |
|-----------|-----|----------|------|------------|
| Effort | 120h | 160h | 220h | 80% |
| Duration | 4w | 5w | 7w | 80% |
| Cost | $18K | $24K | $33K | 80% |

### Basis of Estimate

- **Historical Reference:** [Similar past work]
- **Productivity Rate:** [If parametric]
- **Expert Input:** [Who contributed]

### Assumptions

1. [Assumption 1]
2. [Assumption 2]

### Risks Affecting Estimate

| Risk | Impact on Estimate |
|------|-------------------|
| [Risk 1] | +20% if occurs |
| [Risk 2] | +15% if occurs |

### Recommendations

1. [Next steps for refining estimate]
2. [When to re-estimate]

结构化数据（YAML）

estimation:
  version: "1.0"
  date: "2025-01-15"
  item: "User Dashboard Feature"
  estimator: "estimation-analyst"
  technique: "three_point"

  scope:
    description: "Interactive user dashboard with analytics"
    in_scope:
      - "Dashboard UI components"
      - "Data visualization"
      - "User preferences"
    out_of_scope:
      - "Backend analytics engine"
      - "Real-time updates"
    assumptions:
      - "API endpoints available"
      - "Design mockups complete"

  estimates:
    effort:
      optimistic: 120
      most_likely: 160
      pessimistic: 240
      expected: 166
      unit: "hours"
      std_deviation: 20
    duration:
      optimistic: 3
      most_likely: 4
      pessimistic: 6
      expected: 4.2
      unit: "weeks"
    cost:
      expected: 24000
      range_low: 18000
      range_high: 36000
      currency: "USD"

  confidence: 0.80
  contingency: 0.20

  breakdown:
    - component: "UI Components"
      effort: 60
      technique: "parametric"
      rate: "15h/component"
      quantity: 4
    - component: "Data Integration"
      effort: 40
      technique: "analogous"
      reference: "PROJ-123"
    - component: "Testing"
      effort: 40
      technique: "percentage"
      percentage: 0.25

  risks:
    - risk: "API complexity higher than expected"
      probability: 0.3
      impact_hours: 30
    - risk: "Design changes during development"
      probability: 0.2
      impact_hours: 20

  historical_comparison:
    similar_item: "Admin Dashboard"
    actual_effort: 180
    adjustment_factor: 0.9

分解表

## Effort Breakdown

| Component | Technique | Estimate | Contingency | Total |
|-----------|-----------|----------|-------------|-------|
| UI Components | Parametric | 60h | 12h | 72h |
| Data Integration | Analogous | 40h | 10h | 50h |
| Testing | % of Dev | 40h | 8h | 48h |
| Documentation | Parametric | 16h | 4h | 20h |
| **Subtotal** | | **156h** | **34h** | **190h** |
| Management Overhead | 10% | | | 19h |
| **Total** | | | | **209h** |

估算准确性

不确定性范围

随着项目推进，估算准确度会提高：

阶段	准确度范围
初始构想	0.25x - 4x
项目获批	0.5x - 2x
需求完成	0.67x - 1.5x
详细设计	0.8x - 1.25x
代码完成	0.9x - 1.1x

含义： 早期估算需要更大的范围；随着了解增多，逐步细化。

估算等级

等级	准确度	使用时机
ROM（数量级粗估）	-25% 至 +75%	初始预算
预算级	-10% 至 +25%	项目审批
确定级	-5% 至 +10%	执行基线

常见误区

误区	预防措施
单点估算	始终提供范围
过度乐观偏差	使用历史数据，并增加应急余量
锚定效应	在看到他人的估算前先进行估算
计划谬误	纳入现实的开销和风险
范围蔓延	记录假设，变更时重新估算
精确性表演	让精度与实际掌握的信息相匹配

集成

上游

• 需求 - 要估算的内容
• risk-analysis - 影响估算的风险
• stakeholder-analysis - 哪些人需要估算，以及所需的精度

下游

• 项目规划 - 资源分配、排期
• 预算编制 - 成本预测
• prioritization - 为价值／工作量分析提供成本输入

相关技能

• risk-analysis - 影响估算的风险
• prioritization - 将估算用于优先级排序
• decision-analysis - 权衡取舍决策
• value-stream-mapping - 估算流程改进工作量

版本历史

• v1.0.0（2025-12-26）：首次发布