name: 工作量计算器 description: “软件项目工时估算助手，使用三点估算(PERT)、T-shirt sizing或功能点分析(FPA)等方法，将需求拆解为工作包，计算出乐观、最可能和悲观工时，并提供项目总工时、标准差和置信区间等结果。当用户需要估算开发工时、评估项目工作量、做三点估算、T恤尺码估算、功能点分析、Sprint规划、报价工时拆分，或询问“这个功能要多久”、“评估一下工作量”等关键词或场景时触发。” license: MIT
工时估算器 — 软件项目工时估算
基于三点估算 (PERT)、T-shirt 尺码、功能点分析 (FPA) 三大方法论，帮助团队对软件项目进行科学的工时估算，输出乐观值、最可能值、悲观值及风险区间。
快速开始
- 用户提供需求描述 → Agent 识别功能模块并拆分工作包 (WBS)
- 选择估算方法 → 根据项目阶段和信息粒度，选用合适的方法
- 逐项估算 → 对每个工作包给出 O/M/P 三值
- 汇总输出 → 生成估算报告（含风险分析和置信区间）
可使用计算工具辅助：
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σ | 合同承诺 |
使用步骤
- 拆分 WBS：将需求拆到可独立估算的最小单元（建议每个 ≤ 5 人日）
- 三值估算：对每个工作包，分别给出 O / M / P（单位统一：人时或人日）
- 计算单任务期望与标准差
- 汇总项目级指标：总期望 = ΣE，总标准差 = √(Σσ²)
- 输出置信区间：根据风险偏好选择置信水平
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 |
使用步骤
- 团队对齐：确认各尺码含义（上表为参考，团队可自定义）
- 独立评估：每人独立给出尺码，避免锚定效应
- 讨论差异：差异超过 2 个尺码时必须讨论
- 达成共识：取团队共识值
- 转换数值（可选）：用上表转为 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) 计算完成后，需要：
-
计算调整因子 VAF（可选，IFPUG 4.3+ 已弃用，但仍有团队使用）
- 14 个通用系统特征 (GSC)，每项 0-5 分
- VAF = 0.65 + 0.01 × Σ(GSC)
- 调整后功能点 AFP = UFP × VAF
-
功能点转人时
- 行业基准：8-15 人时/功能点（取决于语言和团队成熟度）
技术栈 人时/功能点 说明 低代码/成熟框架 4 – 8 有大量可复用组件 Python/JS/现代Web 8 – 12 主流开发效率 Java/C# 企业级 10 – 15 含架构和规范开销 嵌入式/C/C++ 15 – 25 调试和测试成本高 遗留系统维护 20 – 30 理解和回归成本
使用步骤
- 识别功能组件：列出所有 ILF, EIF, EI, EO, EQ
- 评定复杂度：对每个组件判定低/中/高
- 计算 UFP：各组件 × 对应权重后求和
- 选择转换系数：根据技术栈选人时/功能点比率
- 计算总工时：UFP × 转换系数
- 加入缓冲：建议加 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 脚本，支持三种估算方法的数值计算：
# 三点估算 (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《软件估算：揭开黑盒艺术》
- Mike Cohn《敏捷估算与规划》