敏捷产品负责人

敏捷产品负责人 (Agile Product Owner)

为产品负责人提供的待办列表管理和 Sprint 执行工具包，包括用户故事生成、验收标准模式、Sprint 计划和速率跟踪。

---

目录

• 本技能的独特之处

• 用户故事生成工作流

• 验收标准模式

• Epic 拆分工作流

• Sprint 计划工作流

• 待办列表优先级排序

• 参考文档

• 工具

---

本技能的独特之处

• 符合实际的容量计算： Sprint 容量基于“速率 × 可用系数”，而非凭空猜测。

• 基于故事规模的验收标准： 验收标准（AC）的最小数量与故事点挂钩，避免大型项规格定义不足。

• 保持一致的加权优先级： 价值 40%、影响 30%、风险 15%、工作量 15%，使权衡过程透明化。

• 系统化的 Epic 拆分技术： 提供五种具体的拆分模式，防止故事过大。

• 将 INVEST 验证内置于工作流： 每个故事都包含验证步骤，而不仅仅是指导原则。

用户故事生成工作流

根据需求创建符合 INVEST 原则的用户故事：

1. 确定用户角色（谁能从该功能中获益）
2. 定义所需的操作或能力
3. 阐明交付的收益或价值
4. 使用 Given-When-Then 编写验收标准
5. 使用斐波那契数列估算故事点
6. 根据 INVEST 标准进行验证
7. 将其添加到待办列表并标注优先级
8. 验证： 故事通过所有 INVEST 标准；验收标准可测试

用户故事模板

作为 [用户角色],
我想要 [操作/能力],
以便于 [收益/价值]。

示例：

作为一名市场经理,
我想要将活动报告导出为 PDF,
以便于我能与没有系统访问权限的利益相关者分享结果。

故事类型

| 类型 | 模板 | 示例 |
|------|----------|---------|
| 功能 (Feature) | 作为 [用户角色], 我想要 [操作] 以便 [收益] | 作为用户，我想要过滤搜索结果，以便更快地找到项目 |
| 优化 (Improvement) | 作为 [用户角色], 我需要 [能力] 来 [目标] | 作为用户，我需要更快的页面加载速度，以便在不感到沮丧的情况下完成任务 |
| Bug 修复 (Bug Fix) | 作为 [用户角色], 当 [条件] 时，我期望 [行为] | 作为用户，我期望在刷新页面时购物车内容依然存在 |
| 支撑项 (Enabler) | 作为开发人员, 我需要 [技术任务] 以实现 [能力] | 作为开发人员，我需要实现缓存以支持快速响应 |

用户角色参考

| 用户角色 | 典型需求 | 场景 |
|---------|--------------|---------|
| 最终用户 | 效率、简洁、可靠 | 日常功能使用 |
| 管理员 | 控制、可见性、安全性 | 系统管理 |
| 高级用户 | 自动化、自定义、快捷方式 | 专家级工作流 |
| 新用户 | 指导、学习、安全性 | 入职引导 |

---

验收标准 (AC) 模式

使用 Given-When-Then 格式编写可测试的验收标准。

Given-When-Then 模板

Given [前提条件/上下文],
When [操作/触发条件],
Then [预期结果].

示例：

Given 用户已使用有效凭据登录,
When 他们点击“导出”按钮,
Then PDF 下载在 2 秒内开始。

Given 用户输入了无效的电子邮件格式,
When 他们提交注册表单,
Then 显示行内错误消息“请输入有效的电子邮件地址”。
Given 购物车中包含商品,
When 用户刷新浏览器,
Then 购物车内容保持不变。

验收标准检查清单

每个用户故事应包含以下类别的标准：

| 类别 | 示例 |
|----------|---------|
| 正常路径 (Happy Path) | Given 输入有效, When 提交, Then 显示成功消息 |
| 校验 (Validation) | 当必填字段为空时应拒绝输入 |
| 错误处理 (Error Handling) | API 失败时必须显示用户友好的消息 |
| 性能 (Performance) | 操作应在 2 秒内完成 |
| 无障碍 (Accessibility) | 必须仅通过键盘即可导航 |

按故事规模设定的最低标准

| 故事点数 | 最少 AC 数量 |
|--------------|------------------|
| 1-2 | 3-4 条标准 |
| 3-5 | 4-6 条标准 |
| 8 | 5-8 条标准 |
| 13+ | 拆分该故事 |

完整模板库请参阅 references/user-story-templates.md。

---

Epic 拆分工作流

将 Epic 拆分为可交付的 Sprint 规模的故事：

1. 定义 Epic 范围和成功标准
2. 识别受该 Epic 影响的所有用户角色
3. 列出每个角色所需的所有能力
4. 将能力分组为逻辑上的用户故事
5. 验证每个故事的点数 $\le 8$
6. 识别故事之间的依赖关系
7. 对故事进行排序以实现增量交付
8. 验证： 每个故事都能交付独立价值；所有故事覆盖 Epic 全范围

拆分技巧

| 技巧 | 使用时机 | 示例 |
|-----------|-------------|---------|
| 按工作流步骤 | 线性流程 | “结账” $\rightarrow$ “加入购物车” + “输入支付信息” + “确认订单” |
| 按用户角色 | 存在多种用户类型 | “仪表盘” $\rightarrow$ “管理员仪表盘” + “用户仪表盘” |
| 按数据类型 | 存在多种输入源 | “导入” $\rightarrow$ “导入 CSV” + “导入 Excel” |
| 按操作类型 | CRUD 功能 | “管理用户” $\rightarrow$ “创建” + “编辑” + “删除” |
| 正常路径优先 | 降低风险 | “功能” $\rightarrow$ “基础流程” + “错误处理” + “边缘情况” |

Epic 示例

Epic： 用户仪表盘

拆分结果：

Epic: 用户仪表盘 (总计 34 点)
├── US-001: 查看关键指标 (5 点) - 最终用户
├── US-002: 自定义布局 (5 点) - 高级用户
├── US-003: 将数据导出为 CSV (3 点) - 最终用户
├── US-004: 与团队共享 (5 点) - 最终用户
├── US-005: 设置警报 (5 点) - 高级用户
├── US-006: 按日期范围筛选 (3 点) - 最终用户
├── US-007: 管理员概览 (5 点) - 管理员
└── US-008: 启用缓存 (3 点) - 赋能项 (Enabler)

---

Sprint 计划工作流

规划 Sprint 容量并选择故事：

1. 计算团队容量 (速率 $\times$ 可用时间)
2. 与利益相关者审视 Sprint 目标
3. 从积压工作中选择故事
优先级排序后的 Backlog
4. 填充至容量的 80-85%（承诺项）
5. 添加挑战目标（额外 10-15%）
6. 识别依赖项和风险
7. 将复杂的故事拆分为任务
8. 验证： 承诺点数 ≤ 85% 容量；所有故事均包含验收标准

容量计算

Sprint 容量 = 平均速率 × 可用系数
示例：
平均速率：30 点
团队可用性：90%（一名成员部分缺勤）
调整后容量：27 点
承诺项：23 点 (27 的 85%)
挑战项：4 点 (27 的 15%)

可用系数

| 场景 | 系数 |
|----------|--------|
| 全员在岗，无休假 | 1.0 |
| 一名成员缺勤 50% | 0.9 |
| Sprint 期间有节假日 | 0.8 |
| 多名成员缺勤 | 0.7 |

Sprint 负载模板

Sprint 容量：27 点
Sprint 目标：[清晰、可衡量的目标]
承诺项 (23 点)：
[H] US-001: 用户仪表盘 (5 pts)
[H] US-002: 导出功能 (3 pts)
[H] US-003: 搜索过滤器 (5 pts)
[M] US-004: 设置页面 (5 pts)
[M] US-005: 帮助提示 (3 pts)
[L] US-006: 主题选项 (2 pts)
挑战项 (4 点)：
[L] US-007: 排序选项 (2 pts)
[L] US-008: 打印视图 (2 pts)

完整规划流程请参阅 references/sprint-planning-guide.md。

---

Backlog 优先级排序

使用价值和工作量评估对 Backlog 进行优先级排序。

优先级级别

| 优先级 | 定义 | Sprint 目标 |
|----------|------------|---------------|
| 紧急 (Critical) | 阻塞用户、安全问题、数据丢失 | 立即处理 |
| 高 (High) | 核心功能、关键用户需求 | 本次 Sprint |
| 中 (Medium) | 改进、增强功能 | 接下来的 2-3 个 Sprint |
| 低 (Low) | 锦上添花、微小改进 | 留在 Backlog |

优先级评估因素

| 因素 | 权重 | 关键问题 |
|--------|--------|-----------|
| 业务价值 | 40% | 对营收的影响？用户需求？战略一致性？ |
| 用户影响 | 30% | 影响多少用户？使用频率如何？ |
| 风险/依赖 | 15% | 技术风险？外部依赖？ |
| 工作量 | 15% | 规模？复杂度？不确定性？ |

INVEST 标准验证

在加入 Sprint 之前，验证每个故事：

| 标准 | 问题 | 通过条件... |
|-----------|----------|------------|
| Independent (独立) | 是否可以在没有其他未承诺故事的情况下开发？ | 无阻塞性依赖 |
| Negotiable (可协商) | 实现方案是否灵活？ | 存在多种可行方案 |
| Valuable (有价值) | 是否为用户或业务提供价值？ | 在 "以便于..." 中有明确收益 |
| Estimable (可估算) | 团队能否对其进行估算？ | 理解程度足以进行规模评估 |
| Small (小巧) | 是否能在一次 Sprint 中完成？ | ≤ 8 个故事点 |
| Testable (可测试) | 我们能否验证其已完成？ | 有明确的验收标准 |

---

参考文档

用户故事模板

references/user-story-templates.md 包含：

• 按类型划分的标准故事格式（功能、改进、Bug 修复、赋能项）

• 验收标准模式（Given-When-Then, Should/Must/Can）

• INVEST 标准验证清单

• 故事点估算指南（斐波那契数列）

• 常见的故事反模式及其修复方法

• 故事拆分技术

Sprint 规划指南

references/sprint-planning-guide.md 包含：

• Sprint 规划会议议程

• 容量计算公式

• Backlog 优先级排序框架 (WSJF)

• Sprint 仪式指南（每日站会、评审会、回顾会）

• 速率跟踪和燃尽图模式

• 完成定义 (DoD) 清单

• Sprint 指标与目标

---

工具

用户故事生成器

# 从示例 Epic 生成故事
python

根据容量规划 Sprint

生成内容：
符合 INVEST 原则的用户故事
Given-When-Then 格式的验收标准
故事点估算（斐波那契数列）
优先级分配
Sprint 负载（包含承诺项和挑战项）
输出示例

故事描述：
作为一名最终用户，我想查看关键指标和 KPI，
以便节省时间并提高工作效率。

验收标准：
1. 给定用户拥有访问权限，当其查看关键指标时，则应显示结果
2. 处理前应验证输入
3. 操作失败时必须显示清晰的错误消息
4. 响应时间应在 2 秒内
5. 必须支持键盘导航

INVEST 检查清单：
✓ 独立性 (Independent)
✓ 可协商性 (Negotiable)
✓ 有价值 (Valuable)
✓ 可估算 (Estimable)
✓ 小巧 (Small)
✓ 可测试 (Testable)

---

Sprint 指标
追踪 Sprint 健康状况和团队绩效。
关键指标
| 指标 | 公式 | 目标 |
|--------|---------|--------|
| 速率 (Velocity) | 完成点数 / Sprint | 稳定在 ±10% |
| 承诺可靠性 | 完成数 / 承诺数 | >85% |
| 范围变更 | Sprint 中途增加或删除的点数 | <10% |
| 结转项 (Carryover) | 未完成的点数 | <15% |
速率追踪

规划：承诺 24-26 points
``

• Scrum Master (project-management/scrum-master/) — 速率数据和 Sprint 仪式与待办列表管理相辅相成

• 产品经理工具包 (product-team/product-manager-toolkit/`) — RICE 优先级排序为待办列表排序提供依据