story-definition

故事定义

帮助团队根据功能、史诗、需求或想法，定义清晰且可实现的用户故事。从已连接的工具中获取项目背景信息，应用结构化框架，并直接在项目跟踪工具中创建故事。

工作流

步骤 1 — 收集背景信息

在动笔前，先弄清楚需要拆解的内容。

如果已连接 ~~project tracker：

• 询问用户要在哪个项目或看板中开展工作
• 获取当前的史诗、标签和团队成员，以了解项目结构
• 检查现有待办列表，查找相关或重复的故事
• 获取任何关联的需求、规格说明或上级史诗作为背景信息
• 识别项目现有的惯例（标签分类、故事点数刻度、命名模式）

如果未连接项目跟踪工具：

• 请用户描述功能、史诗或需求
• 询问团队背景：由谁实现、使用什么技术栈，以及有哪些限制
• 询问他们遵循的故事格式惯例

始终询问：

• 这项工作要实现什么目标或成果？
• 是否存在已知限制（时间线、依赖项、技术限制）？
• 需要什么粒度？（史诗级、可纳入迭代、任务级）

步骤 2 — 分析并拆解

将输入拆解为逻辑清晰、可实现的单元。

拆解原则：

1. 垂直切片 — 每个故事都交付一小部分端到端价值，而不是水平分层。一个故事应涵盖实现某项特定行为所需的所有层（UI、API、DB）。
2. INVEST 标准 — 每个故事都必须满足：
   • Independent（独立）— 无需等待其他故事即可构建和交付（尽量减少依赖）
   • Negotiable（可协商）— 细节可以讨论，不是僵化的规格说明
   • Valuable（有价值）— 为用户、利益相关方或系统带来明确价值
   • Estimable（可估算）— 团队能够合理估算工作量
   • Small（小）— 可在单个迭代中完成（若规模过大，则进一步拆分）
   • Testable（可测试）— 有明确的条件可用于验证是否完成
3. 依赖关系映射 — 确认哪些故事会阻塞其他故事，并标记循环依赖
4. 风险优先排序 — 尽早提出高风险或高不确定性的故事，以便优先处理

故事规模过大时的拆分策略：

策略	适用场景	示例
按工作流步骤拆分	多步骤流程	“用户可以将商品加入购物车”与“用户可以结账”
按业务规则拆分	复杂验证	“基础验证”与“边缘情况处理”
按数据类型拆分	多种实体类型	“导入 CSV 联系人”与“导入 CSV 公司”
按接口拆分	多个入口点	“通过表单创建”与“通过 API 创建”
按操作拆分	完整 CRUD	“查看列表”与“编辑条目”与“删除条目”
按用户角色拆分	不同用户类型	“管理员可以配置”与“成员可以查看”
按正常路径/边缘情况拆分	复杂流程	“支付成功”与“支付失败时重试”

步骤 3 — 编写故事

每个故事都使用此格式。如果项目惯例中的字段名称不同，请相应调整。

Title: [Action-oriented, concise — starts with a verb or "As a..."]

User story:
As a [specific persona/role],
I want to [concrete action],
so that [measurable outcome or business value].

Acceptance criteria:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] [Additional criteria using Given/When/Then or plain checkboxes]

Definition of done:
- [ ] Code implemented and passing CI
- [ ] Unit/integration tests covering acceptance criteria
- [ ] Code reviewed and approved
- [ ] [Project-specific DoD items from team conventions]

Technical notes:
- Implementation hints, API contracts, data model changes
- Links to relevant specs, designs, or documentation
- Known risks or open questions to resolve during implementation

Size: [T-shirt (XS/S/M/L/XL) or story points — match project convention]
Priority: [P0-Critical / P1-High / P2-Medium / P3-Low]
Labels: [Use existing project labels when available]
Dependencies: [List story titles or IDs this story depends on]

写作质量检查清单——适用于每个故事：

• 标题在看板视图中易于快速浏览（少于 80 个字符）
• “以便”子句描述了实际成果，而不是重复陈述操作
• 验收标准可测试——不使用“应该运行良好”之类含糊的说法
• 每条验收标准只涵盖一种行为（拆分复合标准）
• 对实现者而言不明显的内容都附有技术说明
• 规模反映实际复杂度，而不只是代码量
• 不遗漏隐藏工作——如果故事需要迁移、配置更改或文档更新，都要明确列出

步骤 4 — 验证和整理

创建或呈现故事之前，先进行质量检查。

验证检查：

1. 覆盖范围 — 故事是否完整实现了整个功能/史诗？找出缺口。
2. 重叠 — 是否有两个故事在做相同的工作？合并或明确界限。
3. 依赖关系图 — 故事能否按可实施的顺序排列？标记循环依赖。
4. 迭代适配度 — 每个故事是否足够小，可在一个迭代中完成？标记需要进一步拆分的故事。
5. 可测试性 — QA 能否毫无歧义地验证每项验收标准？
6. 待办列表检查 — 如果已连接 ~~project tracker，请确认是否已有故事涵盖这项工作。

整理输出：

• 按史诗或功能区域对故事分组
• 按建议的实施顺序排列（先处理依赖项，再考虑优先级）
• 明确标记哪些故事已做好迭代准备，哪些需要进一步完善
• 汇总总范围：故事数量、预估总工作量、建议的迭代分配

步骤 5 — 在项目跟踪器中创建

如果已连接 ~~project tracker：

• 创建任何工单前先征得用户同意
• 先展示汇总表：

#	标题	规模	优先级	依赖项
1	...	S	P1	—
2	...	M	P1	#1

• 用户批准后，在已连接的工具中创建每个故事
• 按照讨论结果设置标签、负责人、迭代和父级史诗
• 在支持的情况下，设置故事间的依赖链接
• 反馈已创建工单的链接

如果未连接项目跟踪器：

• 按照上述结构化格式呈现故事
• 提供将内容导出为 Markdown 或格式化列表的选项，方便用户粘贴到自己的工具中

步骤 6 — 通知团队

如果已连接 ~~chat：

• 询问用户是否要通知团队有新故事创建
• 起草简洁的消息，概述创建的内容、故事数量、预估总工作量，以及看板/项目链接
• 仅在用户确认后发布

故事规模指南

使用项目现有的规模标准。如果没有，请建议采用以下其中一种：

T 恤尺码（推荐给刚开始估算的团队）：

规模	典型范围	示例
XS	配置变更、文案更新、单行修复	切换功能标志、修正拼写错误
S	单个组件、路径明确	添加表单字段、按已知模式新增 API 端点
M	多个组件、存在一些未知因素	新增 CRUD 功能、与文档齐全的 API 集成
L	涉及多个方面，需要设计决策	新增身份验证流程、包含数据转换的数据迁移
XL	通常应进一步拆分	完整的功能重新设计、新服务

斐波那契故事点（适用于使用速度跟踪的团队）：

点数	相对工作量
1	微不足道 — 数小时
2	较小 — 一天或更短
3	中等 — 几天
5	重大 — 大约一周的大部分时间
8	大型 — 整整一周，考虑拆分
13	非常大型 — 必须拆分

优先级框架

级别	标签	标准	行动
P0	严重	阻碍发布、安全问题、存在数据丢失风险	立即处理 — 当前迭代
P1	高	功能/史诗目标的核心内容，对用户影响大	下一个可用迭代
P2	中	有价值的改进，但不构成阻碍	待办列表 — 有资源时安排
P3	低	可有可无的优化、润色、小幅增强	待办列表 — 规划时重新评估

应避免的反模式

反模式	问题	修正方法
“实现功能 X”	未说明用户价值，没有验收标准	补充角色、结果和可测试的标准
水平拆分	先“构建 API”，再“构建 UI”——两者都完成前无法交付价值	垂直拆分——端到端实现一种行为
过大的用户故事	“作为用户，我希望获得完整的结账流程”——无法估算	按工作流步骤、操作或业务规则拆分
模糊的验收标准	“应该正常工作”——无法测试	使用 Given/When/Then，并明确具体输入和输出
遗漏依赖项	因未识别前置条件，用户故事无法完成	拆分时明确梳理依赖关系
过度设计	用户故事将“锦上添花”的细节与核心需求混在一起	将必需标准与增强项分开
复制粘贴角色	所有内容都写“作为用户”——缺少上下文	使用具体角色：管理员、成员、访客、API 使用者