如何在敏捷开发中编写优质用户故事

大约70%的技术项目会失败。几十年来，人们普遍认为项目失败是因为没有遵循最佳实践，或者团队缺乏所有必要的技能。然而，最佳实践、技能和能力的采纳在过去几十年中已经显著提升——那么为什么项目仍然会失败呢？

考虑到70%的软件项目因需求不佳而失败，这些失败带来的返工成本每年超过450亿美元。

问题在于——为什么会这样？答案有两个方面。首先，业务需求常常偏离了客户；其次，需求缺乏一个整体的参考框架，使得需求分析师无法从客户需求和战略出发，持续驱动并追踪需求，直至最终实现的解决方案。

要编写优质的需求或用户故事，请遵循以下步骤：

1. 尽可能多地定义人物角色，以代表系统的用户。这将帮助你始终聚焦于客户，并根据客户需求来驱动和追踪需求。人物角色由艾伦·库珀提出，用于定义系统的典型用户——即与系统互动的各类人群的示例。用户不必是或代表具体个人，也可以代表一个组织。
2. 确保你的用户故事遵循“三C”原则：

• 卡片 — 应写在索引卡或便利贴上
• 对话 — 从产品负责人处获取详细信息
• 确认 — 确保其正确实现，必须满足用户验收标准。

3. 拆分用户故事，使其大小合适，能够适配一个冲刺周期。 一些拆分故事的方法包括：

• 按工作流程步骤拆分
• 按输入/输出渠道拆分
• 按用户选项拆分
• 按人物角色/角色拆分
• 按数据范围拆分

4. 让每个用户故事都遵循INVEST原则：

敏捷INVEST口诀，由比尔·沃克提出，作为确保高质量产品待办事项（PBIs）的指导原则，通常以用户故事的形式书写。

• 独立：故事应尽可能独立。
• 可协商：故事不是合同。故事是对话的邀请。故事捕捉了所期望内容的本质。
• 有价值: 如果一个故事没有明显的价值，就不应该进行。
• 可估算的: 一个故事必须是可以估算或确定规模的，以便能够正确地优先排序。
• 小的: 对于两周的迭代，用户故事的平均工作量应为3到4天——总计！这包括将故事推进到“完成”状态所需的所有工作。用户故事越小，估算的准确性就越高！
• 可测试的: 每个故事都必须是可测试的，才能被视为“完成”。

• 编写用户故事的SMART目标和INVEST原则
• 主题 vs 巨大故事 vs 用户故事 vs 任务
• 产品待办事项列表中的DEEP是什么意思？
• 如何为Scrum项目编写产品愿景？
• 如何使用Scrum看板进行敏捷开发？
• 在Scrum中，谁负责创建产品待办事项或用户故事？
• 什么是敏捷估算？
• 敏捷中的故事点是什么？如何估算用户故事？
• 用户故事拆分——垂直切片 vs 水平切片