# Tapd Story Score

> TAPD 需求评分子技能。对需求进行工时预估、规模评分（size，斐波那契）与业务价值（RICE）评分，并更新到需求文档中。 本技能作为 tapd-story-evaluation 的子技能被调用，不独立触发。

- Skill: `tencentblueking/tapd-story-score` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tencentblueking/tapd-story-score`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tencentblueking/tapd-story-score/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tencentblueking (https://skillmd.com/u/tencentblueking)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tencentblueking/tapd-story-score

---


# TAPD 需求评分

## 概述

对需求进行工时预估、规模评分（size，斐波那契）与业务价值（RICE）评分，并将评分结果
更新到需求文档中。评分基于需求文档的详细内容，从高级工程师视角进行客观估算。

> **size 与 business_value 解耦**：`size` 为**相对实现规模斐波那契分**（仅由 5 个规模维度决定），
> 回写 TAPD `size` 字段；RICE 综合分作为**业务价值**回写 TAPD `business_value` 字段，
> 两者完全解耦、互不赋值。

## 输入

| 参数 | 来源 | 说明 |
|------|------|------|
| 需求文档 | 主 skill 传入或本地文件路径 | 规范化的需求文档（Markdown） |
| 背景知识 | 主 skill 传入 | 项目技术栈、架构等参考信息 |
| 需求类型 | 主 skill 已决策，可选 | “运维操作”“文档编写”或“开发需求”；未提供时默认“开发需求” |
| 分类 ID | 主 skill 已读取，可选 | `stories_get.category_id`，仅用于结果追溯，不用于再次推断类型 |
| 分类原始值 | 主 skill 已读取，可选 | `story_category_get` 按分类 ID 查询到的 `Category.name`，仅用于结果说明，不用于再次推断类型 |

## 执行流程

### 1. 加载与检查

加载需求文档内容，检查以下评分产物是否**完整且可追溯**：
- 工时预估：`预估工时` 有值，且“工时估算”中包含 O、M、P、E 与估时依据；
- 规模评分：`规模（size）` 有值，且规模评分章节包含 5 个维度、`maxDim`、`avgDim` 与映射结果；
- 业务价值评分：`业务价值（RICE）` 有值，且 RICE 明细包含 Reach、Impact、Confidence、Effort 和综合分；
- 用户是否明确要求重新评估？

**判断逻辑**：
- 三类评分产物均完整，且未要求重新评估 → 流程结束，输出“已有完整评分数据，未重新评分”；
- 任一评分产物或其评分依据缺失，或用户要求重新评估 → 从步骤 2 开始完成一整轮 PERT、size 与业务价值（RICE）评分。不得只补填缺失字段，以免新的工时、size 与 RICE Effort 产生不一致。

### 2. 工时预估

> **执行前必读** `references/story-effort-baseline.md`

以**高级工程师**的角色对需求进行工时预估。

#### PERT 三点估算

1. 若调用方提供 `需求类型`，直接使用该值，不重新根据文本或分类原始值猜测类型；若未提供，设为“开发需求”。
2. 按需求类型选择对应基线：输入为“运维操作”时使用运维操作基线，输入为“文档编写”时使用文档编写基线，输入为“开发需求”或缺省时使用原有开发类逻辑；输出命中的基线和影响 M 的维度。
3. 逐项检查本类型的评估维度和适用的开发类调整因子，在基线 M 值基础上调整，结果取整至 0.5h。
4. 估算三点：
   - **O（最乐观）**：需求边界清晰、改动集中、无意外时的工时
   - **M（最可能）**：正常实现路径，调整因子修正后的基线中值
   - **P（最悲观）**：出现需求变更、隐性依赖、技术障碍时的工时
5. 计算 `E=(O+4M+P)/6`，四舍五入至 0.5h；同一轮评分以该 E 计算 `RICE 评分明细.Effort=E/8`。

向用户展示格式：

```
**工时预估**：Eh（高级工程师，含开发 + 自测 + Code Review）
- 需求类型：{type}（分类 ID：{category_id 或“未提供”}；分类原始值：{原始值或“未提供”}）
- 估时依据：{命中的类型基线及影响 M 的维度}
- 调整因子：{因子1}（+X%）、{因子2}（-Y%）…（无则填"无"）
- 最乐观：Oh / 最可能：Mh / 最悲观：Ph
- PERT：(O + 4×M + P) / 6 = Eh
```

#### 更新文档

将工时预估结果更新到需求文档的"基本信息"章节：

```yaml
预估工时: Eh
工时估算: {估时依据}；PERT（O=Oh / M=Mh / P=Ph / E=Eh）
```

同时更新"人力与工时"章节（如存在）：

```markdown
* 全量工作1位高级工程师完成工时预估：Eh（PERT 三点：O=Oh / M=Mh / P=Ph）
* 全量工作1位中级工程师完成工时预估：XX 人时（通常为高级工程师的 1.3-1.5 倍）
```

### 3. 规模评分（size）（斐波那契）

> **执行前必读** `../references/size-difficulty-standard.md`

按该标准对需求进行**相对实现规模**评分，产出回写 TAPD `size` 字段的斐波那契规模分。

1. 对 5 个规模维度（实现范围、技术复杂度、依赖、风险、验证成本）各评 1–5 分，
   评分依据复用 §2 PERT 已识别的基线与调整因子（**不含任何价值/用户影响维度**）。
2. 取 `maxDim`（最大值）与 `avgDim`（算术平均），按标准的"maxDim 锚定 + avgDim 校准"
   两步法映射为斐波那契 size（1/2/3/5/8/13…）。
3. 常规单需求 size 建议 ≤5；≥8 提示"建议评估拆分"，≥13"必须拆分"（与 ≤24 人时强约束对齐）。

向用户展示格式：

```
**规模（size，斐波那契）**：{斐波那契分}
- 实现范围：{n}/5 / 技术复杂度：{n}/5 / 依赖：{n}/5 / 风险：{n}/5 / 验证成本：{n}/5
- maxDim={max} / avgDim={avg} → size={斐波那契分}
```

#### 更新文档

将 规模评分（size）结果更新到需求文档的"基本信息"章节：

```yaml
规模（size）: [斐波那契分]（规模维度：范围/复杂度/依赖/风险/验证成本）
```

### 4. 业务价值（RICE）评分

> RICE 综合分作为**业务价值**写入需求文档，并回写 TAPD `business_value` 字段，**不赋值 size**（size 见 §3）。

参照 `../references/rice-scoring-standard.md` 中的 RICE 模型进行业务价值评分。

#### RICE 公式

**RICE Score = (Reach × Impact × Confidence) / Effort**

#### 参数评估

**Reach（触达）**：
- 评估该需求影响的用户数量或事件数
- 影响 100% 用户记为 100，50% 记为 50，依此类推
- 内部工具类需求按实际使用人数估算

**Impact（影响程度）**：
根据需求的业务价值和优先级确定：

| 等级 | 分值 | 适用场景 |
|------|------|---------|
| 解决 Bug | 10 | 修复线上问题、安全漏洞 |
| 高优先级 | 8 | 核心功能、用户强烈需要 |
| 中优先级 | 5 | 重要功能改进 |
| 低优先级 | 2 | 一般功能增强 |
| Nice to Have | 1 | 锦上添花的改进 |

**Confidence（信心指数）**：
根据需求的明确程度确定：

| 等级 | 百分比 | 适用场景 |
|------|--------|---------|
| 高信心 | 100% | 需求文档完善、技术方案明确、有用户调研支持 |
| 中信心 | 75% | 需求基本明确、用户体验/性能优化类 |
| 低信心 | 50% | 需求不够明确、属于探索性功能 |
| 极低信心 | 25% | 纯猜测用户需要 |

**Effort（开发工作量）**：
- 使用步骤 2 同一轮的 E
- 按每天 8 小时折算为人天，即 `RICE 评分明细.Effort=E/8`
- 例如：预估 E=40 人时 → Effort = 5 人天

#### 计算并记录

计算 RICE 得分并更新到需求文档的"基本信息"章节（作为业务价值）：

```yaml
业务价值（RICE）: [RICE得分]（Reach=[R], Impact=[I], Confidence=[C]%, Effort=[E]人天）
```

### 5. 保存更新

将更新后的需求文档保存到原文件路径。如果文档来源于 TAPD 而非本地文件，则保存到
`docs/reqs/` 目录下。

> **跨平台提示**：使用 Agent 内置的 `write_to_file` 工具保存文件，避免依赖
> 特定操作系统的 Shell 命令。

### 6. 输出评分结果

输出结构化的评分结果，供主 skill 继续处理：

```markdown
## 评分结果

**需求名称**：[名称]
**需求类型**：[运维操作 / 文档编写 / 开发需求]
**分类 ID**：[stories_get.category_id 或“未提供”]
**分类原始值**：[story_category_get 按分类 ID 查询到的 Category.name 或“未提供”]
**估时依据**：[命中的类型基线及影响 M 的维度]
**预估工时**：E 人时（E/8 人天）
**规模（size，斐波那契）**：XX（→ 回写 TAPD size 字段）
  - 实现范围: n/5
  - 技术复杂度: n/5
  - 依赖: n/5
  - 风险: n/5
  - 验证成本: n/5
  - maxDim=XX / avgDim=XX
  - 处置：size ≤5 为常规规模；size=8 建议评估拆分；size≥13 必须由主 skill 回拨重拆
**业务价值（RICE）**：XX（→ 回写 TAPD business_value 字段）
  - Reach: XX
  - Impact: XX
  - Confidence: XX%
  - Effort: E/8 人天
```

## 错误处理

| 错误场景 | 处理方式 |
|---------|---------|
| 需求文档内容不足以评估 | 标注"信息不足"，使用保守估算并说明假设 |
| 文件保存失败 | 将评分结果输出到控制台，提示用户手动更新 |

## 参考文件

| 文件 | 用途 | 何时读取 |
|------|------|---------|
| `../references/size-difficulty-standard.md` | 规模评分（size）标准（5 维度 → 斐波那契） | 执行 规模评分（size）前（必读） |
| `../references/rice-scoring-standard.md` | 业务价值（RICE）评分标准 | 执行 业务价值（RICE）评分前 |
| `references/story-effort-baseline.md` | 需求类型工时基线与调整因子 | 执行工时预估前（必读） |