估算

核心问题：如何准确估算开发工期？故事点和理想人天有什么区别？

1. 估算方法

方法	说明	适用场景
故事点	相对估算，不直接对应时间	Sprint 规划
理想人天	假设没有打扰的工作天数	项目规划
Planning Poker	团队投票达成共识	需求评审
T-Shirt Size	S/M/L/XL 粗略估算	早期评估

估算方法解决的是不同层次的问题，选择取决于项目阶段与不确定性。

• 早期需求信息不足时，用 T-Shirt Size 等粗粒度估算，避免过早制造精度。
• 团队已有稳定的估算尺度和历史数据时，结合故事点与 Velocity 预测迭代交付能力。
• 面向明确的项目工期、成本或外部承诺时，理想人天不能直接等同于日历工期，需要说明估算对象、工作范围、风险假设与不确定性。
• 高不确定性任务优先识别未知因素，必要时安排 Spike 获取信息，再更新估算。

2. Planning Poker 实践

// Planning Poker 流程
// 1. PO 讲解用户故事
// 2. 团队成员提问澄清
// 3. 每人选择一张牌（故事点）
// 4. 同时亮牌
// 5. 估算差异大时讨论，重新投票
// 6. 达成共识

// 故事点斐波那契数列：1, 2, 3, 5, 8, 13, 21
// 故事点是团队内部的相对估算尺度，综合考虑工作量、技术复杂度和不确定性，
// 不存在跨团队通用的「故事点—代码行数—功能规模」映射。
// 各分值的具体含义通过团队历史故事校准，且应保持同一统计口径，
// 不同估算体系下的 Velocity 不能直接比较。
// 某个故事估算到 13 点时，应检查需求边界、未知因素与拆分可能性，
// 而不是机械地按分值决定是否拆分。

估算的前提是需求足够清晰。参与投票前先检查用户故事是否符合可估算性要求，见需求分析。

3. 速率（Velocity）计算

// 速率 = 团队每个 Sprint 完成的故事点数
// 用途：预测未来 Sprint 能完成多少工作

// 示例：
// Sprint 1: 完成 18 点
// Sprint 2: 完成 22 点
// Sprint 3: 完成 20 点
// 平均速率: 20 点/Sprint

// 假设总需求 100 点
// 预计需要: 100 / 20 = 5 个 Sprint

// 100 / 20 = 5 是简化预测，不是工期承诺。预测成立需要几个前提。
// 只统计按团队完成标准真正完成的工作，不把未完成工作按比例计入速率。
// 用多个近期 Sprint 观察波动，并结合团队容量、人员变化和工作类型判断。
// 历史速率稳定不代表未来速率稳定，人员、依赖、需求范围变化会降低预测价值。

速率如何用于 Sprint 容量评估，见敏捷开发中的 Sprint Planning 实践。

4. 估算偏差分析

偏差原因	解决方案
需求理解不充分	评审时多提问，明确验收标准
技术方案不确定	预研/Spike，先验证再估算
遗漏边界条件	使用 Checklist 检查
依赖外部团队	将依赖风险纳入估算
过于乐观	参考历史数据，使用三点估算法

// 三点估算法（PERT）
// PERT 加权估算值 = (乐观 + 4 × 最可能 + 悲观) / 6
// 示例：
// 乐观: 2 天
// 最可能: 3 天
// 悲观: 8 天
// PERT 加权估算值 = (2 + 4×3 + 8) / 6 = 3.33 天

估算的核心：估算不是承诺，而是预测。估算的目的是帮助团队做计划，而不是考核个人。允许偏差存在，重要的是持续改进估算的准确性。