⚡

开发估算Skill development-estimation

开发估算技能用于在软件开发中，对时间、努力、成本或复杂性进行一致且可防御的估计。通过分诊、分解工作、处理风险和产生置信区间，适用于功能、项目、重构和错误回溯的规划与评估。关键词：估计、开发、项目管理、时间管理、风险分析、置信区间、项目规划、回溯估算。

项目管理 0 次安装 2 次浏览 更新于 3/25/2026

名称: 开发估算 描述: 用于估计功能、项目、重构和错误回溯的时间、努力、成本或复杂性。通过分诊、分解、风险处理和置信区间产生可防御的估计，具有清晰的假设和验证步骤。 版本: 1.1.0 标签:

  • 估计
  • 规划
  • 范围
  • 错误
  • 项目评审
  • 交付 所有者: 工程 最后更新: 2026-02-10

开发估算

目的

创建一致、可防御的估计，通过：

  • 分诊和澄清范围（特别是错误列表）
  • 将工作分解为可交付组件
  • 考虑测试、QA和发布开销
  • 识别风险和未知，并明确缓解措施
  • 产生基于置信的范围（P50/P80/P90）

优化用于审查现有项目或回溯并产生现实的交付预测。

何时使用

  • 估计功能或项目范围和交付时间线
  • 审查回溯并产生时间估计
  • 产生风险感知的估计与置信区间
  • 将问题列表转换为执行计划

避免使用当

  • 任务微不足道，直觉检查足够
  • 需求未知，发现是真正的工作
  • 您无法访问代码库或需求

所需输入

尽可能提供；估计质量取决于清晰度。

最低要求

  • 项目列表（错误/功能）与简短描述
  • 目标平台/环境（例如，iOS/Android/Web，暂存/生产）
  • 约束（截止日期，必须修复 vs 可滑动）

有帮助的

  • 复现步骤、日志、截图
  • 架构笔记或代码库访问
  • 部署管道和QA流程
  • 团队容量模型（工程师，专注小时/天，会议负载）
  • 完成定义（所需测试，QA签署，发布范围）

估计框架

始终先确认估计框架：

  • 努力：工程师-天或工程师-周
  • 日历：从容量派生（努力 / 吞吐量）
  • 成本：可选，需要费率假设
  • 复杂性：T恤尺寸或点数（仅当请求时）

默认容量模型

除非提供，否则假设：

  • 每个工程师每天有效构建时间5–6小时
  • 每个项目的评审和协调开销已包括
  • QA/发布开销作为假设明确说明

分诊评分标准（错误回溯）

对于每个错误，捕获：

复现

  • A: 总是
  • B: 有时 / 不稳定
  • C: 无法复现 / 不清晰

清晰度

  • A: 明确原因或明确修复路径
  • B: 部分（需要调查）
  • C: 未知（需要发现）

影响

  • 阻塞 / 高 / 中 / 低

修复类型

  • UI / 后端 / 基础设施 / 数据 / 依赖 / 配置 / 未知

风险标志

  • 并发 / 迁移 / 认证/安全 / 支付 / 第三方API
  • 性能 / 跨平台行为 / 状态持久性
  • 触及核心路径 / 未知爆炸半径

规则：如果复现=C或清晰度=C，包括发现切片。

工作流程

1) 定义范围和估计类型

  • 确认范围内外
  • 确认估计类型：努力、日历、成本、复杂性
  • 确认置信目标：P50 / P80（默认），可选P90
  • 确认约束：截止日期、必须修复项目、发布边界

2) 接收和标准化回溯

  • 去重复问题
  • 合并近重复并注明不确定性
  • 按子系统分组项目（认证、计费、UI、同步、基础设施）
  • 识别未知-未知区域（遗留区域、不稳定测试、差观测性）

3) 每个项目分解

使用此结构估计每个项目：

  • 分诊 / 复现
  • 调查 / 诊断（如果需要）
  • 实施
  • 测试（单元/集成/端到端，视情况而定）
  • 代码评审和迭代
  • QA验证
  • 发布 / 部署步骤（如果适用）

仅当工作预期在一天以下时使用小时；否则使用工程师-天。

4) 依赖关系和序列化

  • 识别依赖关系（内部模块、数据迁移、外部API、应用商店发布）
  • 标记阻塞和可并行流
  • 标记序列需求（必须在X之前落地）

5) 风险、未知和缓冲

维护未知寄存器：

  • 未知 → 发现任务 → 决策/验证方法 → 时间框

风险缓冲指导：

  • 低风险：+0–10%
  • 中等风险：+10–25%
  • 高风险：+25–50%
  • 未知密集：包括发现和重新估计门

6) 汇总总计和置信

产生：

  • 每个项目范围（最小/最可能/最大或P50/P80）
  • 按桶总计（必须/应该/好）
  • 总体置信：
    • P50：如果事情正常进行，可能
    • P80：现实承诺范围
    • P90：高风险交付的保守范围

7) 验证和重新估计计划

提供：

  • 最快验证步骤以减少不确定性（日志、复现工具、尖峰）
  • 重新估计检查点（在发现尖峰后，在第一部分后）

输出格式（必需）

A) 执行摘要

  • 范围声明（包括/排除）
  • 估计框架（努力 vs 日历 + 容量假设）
  • 总计估计：P50 / P80（和P90如果请求）
  • 关键风险和最大未知

B) 回溯估计表

对于每个项目：

  • ID / 标题
  • 桶（必须/应该/好）
  • 子系统
  • 分诊分数（复现/清晰度/影响）
  • 估计（P50/P80）
  • 风险标志
  • 笔记 / 假设

C) 按桶总计

  • 必须修复总计（P50/P80）
  • 应该修复总计（P50/P80）
  • 好有总计（P50/P80）

D) 假设和排除

  • 明确假设（环境访问、测试成熟度、发布节奏）
  • 明确排除（UX重新设计、性能大修、重构除非列出）

E) 风险和未知寄存器

  • 未知 → 发现计划 → 时间框 → 影响如果为真

F) 下一步

  • 前三项行动快速验证
  • 提议序列化 / 里程碑
  • 重新估计触发点

常见错误

  • 估计错误列表时当作已经很好指定
  • 跳过复现/分诊并低估诊断时间
  • 忽略测试、QA验证和发布开销
  • 混合努力和日历时没有容量模型
  • 夸大精度（单数估计没有置信）
  • 不区分必须修复和好有

快速参考

  • 参考模板：skills/development-estimation/references/estimate.md
  • 首选输出：P50/P80努力加上派生日历通过陈述容量
  • 默认单位：工程师-天（仅当子日任务时使用小时）

质量基准

好的估计是：

  • 对假设透明
  • 分解为组件
  • 风险感知并明确处理未知
  • 作为范围与置信级别交付
  • 配有验证和收紧范围的计划