Workload Calculator

---
name: workload-calculator
description: "软件项目工时估算助手，使用三点估算(PERT)、T-shirt sizing或功能点分析(FPA)等方法，将需求拆解为工作包，计算出乐观、最可能和悲观工时，并提供项目总工时、标准差和置信区间等结果。当用户需要估算开发工时、评估项目工作量、做三点估算、T恤尺码估算、功能点分析、Sprint规划、报价工时拆分，或询问“这个功能要多久”、“评估一下工作量”等关键词或场景时触发。"
license: MIT
---

# Effort Estimator — 软件项目工时估算

基于三点估算 (PERT)、T-shirt Sizing、功能点分析 (FPA) 三大方法论，帮助团队对软件项目进行科学的工时估算，输出乐观值、最可能值、悲观值及风险区间。

## Quick Start

1. **用户提供需求描述** → Agent 识别功能模块并拆分工作包 (WBS)
2. **选择估算方法** → 根据项目阶段和信息粒度，选用合适的方法
3. **逐项估算** → 对每个工作包给出 O/M/P 三值
4. **汇总输出** → 生成估算报告（含风险分析和置信区间）

可使用计算工具辅助：
```bash
python3 scripts/estimate_calculator.py --method pert --tasks '[{"name":"用户登录","O":2,"M":3,"P":8}]'
```

---

## 方法选择指南

| 场景 | 推荐方法 | 原因 |
|------|---------|------|
| 早期可研、预算粗估 | T-shirt Sizing | 信息少，快速对齐量级 |
| Sprint 规划、迭代估算 | 三点估算 (PERT) | 粒度适中，有置信区间 |
| 合同报价、大型项目招标 | 功能点分析 (FPA) | 最严谨，行业可比 |
| 团队有历史数据 | 三点估算 + 历史校准 | 结合经验修正 |

---

## 方法一：三点估算 (PERT / Three-Point Estimation)

### 核心公式

| 指标 | 公式 | 含义 |
|------|------|------|
| 期望值 E | (O + 4M + P) / 6 | 加权平均工时 |
| 标准差 σ | (P − O) / 6 | 估算不确定性 |
| 方差 V | σ² | 用于汇总多任务 |
| 项目总期望 | ΣE | 各任务期望之和 |
| 项目总标准差 | √(ΣV) | 各任务方差之和再开方 |

其中：
- **O** (Optimistic)：乐观估计 — 一切顺利时的最短用时
- **M** (Most Likely)：最可能估计 — 正常情况下的用时
- **P** (Pessimistic)：悲观估计 — 遇到困难时的最长用时

### 置信区间

| 置信水平 | 区间 | 适用场景 |
|----------|------|----------|
| 68.3% | E ± 1σ | 内部粗估 |
| 90% | E ± 1.645σ | 项目规划 |
| 95% | E ± 2σ | 对外报价 |
| 99.7% | E ± 3σ | 合同承诺 |

### 使用步骤

1. **拆分 WBS**：将需求拆到可独立估算的最小单元（建议每个 ≤ 5 人日）
2. **三值估算**：对每个工作包，分别给出 O / M / P（单位统一：人时或人日）
3. **计算单任务期望与标准差**
4. **汇总项目级指标**：总期望 = ΣE，总标准差 = √(Σσ²)
5. **输出置信区间**：根据风险偏好选择置信水平

### O/M/P 估算经验法则

- O 不应 < M 的 30%（过于乐观意味着忽略了必要步骤）
- P 不应 > M 的 5 倍（过于悲观说明需求理解不清，应先澄清）
- 如果 O ≈ M ≈ P，说明任务非常确定，或估算者未认真考虑风险
- P/O 比值（展幅比）反映不确定性：< 2 低风险，2-4 中风险，> 4 高风险

---

## 方法二：T-shirt Sizing

### 尺码定义参考表

| 尺码 | 典型范围 (人日) | 典型故事点 | 适用场景 |
|------|----------------|-----------|----------|
| XS | 0.25 – 0.5 | 1 | 配置修改、文案调整、简单 bug 修复 |
| S | 0.5 – 2 | 2 – 3 | 单组件开发、简单 API、UI 微调 |
| M | 2 – 5 | 5 – 8 | 完整功能模块、中等复杂度 API |
| L | 5 – 15 | 13 – 21 | 跨模块功能、需要联调 |
| XL | 15 – 40 | 34 – 55 | 子系统级开发、需架构设计 |
| XXL | 40+ | 89+ | 需拆分为多个迭代，不建议作为单个估算单元 |

### 从 T-shirt 转三点估算

当需要更精确的数值时，可将 T-shirt 尺码转换为三点估算：

| 尺码 | O (人日) | M (人日) | P (人日) |
|------|---------|---------|---------|
| XS | 0.25 | 0.5 | 1 |
| S | 0.5 | 1 | 2.5 |
| M | 2 | 3.5 | 7 |
| L | 5 | 10 | 20 |
| XL | 15 | 25 | 50 |
| XXL | 40 | 70 | 150 |

### 使用步骤

1. **团队对齐**：确认各尺码含义（上表为参考，团队可自定义）
2. **独立评估**：每人独立给出尺码，避免锚定效应
3. **讨论差异**：差异超过 2 个尺码时必须讨论
4. **达成共识**：取团队共识值
5. **转换数值**（可选）：用上表转为 O/M/P 三值

---

## 方法三：功能点分析 (Function Point Analysis, FPA)

### 五类功能组件

| 组件类型 | 缩写 | 定义 | 示例 |
|----------|------|------|------|
| 内部逻辑文件 | ILF | 应用维护的逻辑数据组 | 用户表、订单表 |
| 外部接口文件 | EIF | 应用引用但不维护的数据组 | 第三方汇率数据 |
| 外部输入 | EI | 从外部进入系统的数据处理 | 表单提交、API POST |
| 外部输出 | EO | 生成并发送到外部的数据 | 报表生成、导出 |
| 外部查询 | EQ | 简单的数据检索+展示 | 列表查询、详情页 |

### 复杂度权重矩阵

| 组件类型 | 低 | 中 | 高 |
|----------|-----|-----|-----|
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |

### 复杂度判定规则

**ILF / EIF 复杂度**（基于 DET 数据元素类型 和 RET 记录类型）：

| | DET 1-19 | DET 20-50 | DET 51+ |
|---|---------|-----------|---------|
| RET 1 | 低 | 低 | 中 |
| RET 2-5 | 低 | 中 | 高 |
| RET 6+ | 中 | 高 | 高 |

**EI 复杂度**（基于 DET 和 FTR 引用文件类型数）：

| | DET 1-4 | DET 5-15 | DET 16+ |
|---|---------|----------|---------|
| FTR 0-1 | 低 | 低 | 中 |
| FTR 2 | 低 | 中 | 高 |
| FTR 3+ | 中 | 高 | 高 |

**EO / EQ 复杂度**（基于 DET 和 FTR）：

| | DET 1-5 | DET 6-19 | DET 20+ |
|---|---------|----------|---------|
| FTR 0-1 | 低 | 低 | 中 |
| FTR 2-3 | 低 | 中 | 高 |
| FTR 4+ | 中 | 高 | 高 |

### 功能点转工时

未调整功能点 (UFP) 计算完成后，需要：

1. **计算调整因子 VAF**（可选，IFPUG 4.3+ 已弃用，但仍有团队使用）
   - 14 个通用系统特征 (GSC)，每项 0-5 分
   - VAF = 0.65 + 0.01 × Σ(GSC)
   - 调整后功能点 AFP = UFP × VAF

2. **功能点转人时**
   - 行业基准：8-15 人时/功能点（取决于语言和团队成熟度）

   | 技术栈 | 人时/功能点 | 说明 |
   |--------|-----------|------|
   | 低代码/成熟框架 | 4 – 8 | 有大量可复用组件 |
   | Python/JS/现代Web | 8 – 12 | 主流开发效率 |
   | Java/C# 企业级 | 10 – 15 | 含架构和规范开销 |
   | 嵌入式/C/C++ | 15 – 25 | 调试和测试成本高 |
   | 遗留系统维护 | 20 – 30 | 理解和回归成本 |

### 使用步骤

1. **识别功能组件**：列出所有 ILF, EIF, EI, EO, EQ
2. **评定复杂度**：对每个组件判定低/中/高
3. **计算 UFP**：各组件 × 对应权重后求和
4. **选择转换系数**：根据技术栈选人时/功能点比率
5. **计算总工时**：UFP × 转换系数
6. **加入缓冲**：建议加 15-30% 的管理和风险缓冲

---

## 估算修正因子检查清单

估算完成后，检查以下因素是否已纳入：

### 技术因素
- [ ] 技术栈熟悉度（团队是否有经验？不熟悉 +30-50%）
- [ ] 技术债务（遗留代码质量差？+20-40%）
- [ ] 第三方依赖（API 不稳定？文档缺失？+10-30%）
- [ ] 性能/安全要求（有特殊非功能需求？+15-25%）

### 团队因素
- [ ] 团队规模（> 5 人时沟通成本显著增加，+5%/人）
- [ ] 人员流动风险（有成员可能离开？+15-25%）
- [ ] 并行项目（团队在多个项目间切换？+20-30%）
- [ ] 新成员上手（有新人加入？前 2 周效率降 50%）

### 流程因素
- [ ] 需求稳定性（需求可能变更？+20-50%）
- [ ] 审批流程（需要多层审批？+10-20%）
- [ ] 部署复杂度（多环境、多区域部署？+10-15%）
- [ ] 合规要求（有审计、合规流程？+15-30%）

### 常被低估的工作
- [ ] 代码审查 (Code Review)：+10-15%
- [ ] 单元测试编写：+15-25%
- [ ] 集成测试 / E2E 测试：+10-20%
- [ ] 文档编写：+5-15%
- [ ] Bug 修复和回归：+10-20%
- [ ] 环境搭建和 DevOps：+5-10%
- [ ] 会议和沟通：+10-15%

---

## 估算输出模板

Agent 完成估算后，应按以下格式输出：

```
## 估算报告：[项目/功能名称]

### 估算方法：[三点估算 / T-shirt / FPA]

### 工作包拆分

| # | 工作包 | O (人日) | M (人日) | P (人日) | E (人日) | σ |
|---|--------|---------|---------|---------|---------|---|
| 1 | xxx    | x       | x       | x       | x.x     | x.x |
| 2 | xxx    | x       | x       | x       | x.x     | x.x |

### 汇总

- 总期望工时：X 人日
- 总标准差：X 人日
- 68% 置信区间：X – X 人日
- 90% 置信区间：X – X 人日
- 95% 置信区间：X – X 人日

### 修正因子
- [已考虑的因素及调整]

### 最终建议
- 内部规划用：X 人日（90% 置信）
- 对外报价用：X 人日（95% 置信）

### 风险提示
- [主要风险点和缓解建议]
```

---

## 计算工具

提供 `scripts/estimate_calculator.py` 脚本，支持三种估算方法的数值计算：

```bash
# 三点估算 (PERT)
python3 scripts/estimate_calculator.py --method pert \
  --tasks '[{"name":"登录模块","O":2,"M":3,"P":8},{"name":"支付模块","O":5,"M":10,"P":20}]'

# T-shirt 尺码转换
python3 scripts/estimate_calculator.py --method tshirt \
  --tasks '[{"name":"登录模块","size":"M"},{"name":"支付模块","size":"L"}]'

# 功能点分析
python3 scripts/estimate_calculator.py --method fpa \
  --components '[{"type":"ILF","complexity":"中","count":3},{"type":"EI","complexity":"低","count":5}]' \
  --hours-per-fp 10
```

---

## 参考文档

- IFPUG (International Function Point Users Group) CPM 4.3.1
- PMI PMBOK Guide — 第 6 版，6.4 估算活动持续时间
- Steve McConnell《Software Estimation: Demystifying the Black Art》
- Mike Cohn《Agile Estimating and Planning》