《用户故事与敏捷方法》阅读笔记2（2024.11.15）

第5章：用户故事的编写

1. 用户故事的定义：

   • 用户故事是一种简洁的需求表达方式，旨在描述一个特定用户群体的需求。格式为：
     作为[角色]，我想要[功能]，从而能够[目的]。
   • 该格式帮助开发团队理解需求背后的目的，而不仅仅是实现一个功能。

2. 编写高质量用户故事的要点：

   • 简洁与清晰：用户故事应该简洁明了，避免过多的技术细节，强调功能对用户的价值。
   • 需求导向：聚焦于用户需求，而不是技术实现。开发团队要理解用户需求背后的业务目标。
   • INVEST原则：一个好的用户故事应该具备以下特性：
     • I（Independent，独立）：用户故事可以独立完成，不依赖于其他故事。
     • N（Negotiable，可谈判）：故事的实现方式是可以讨论和调整的。
     • V（Valuable，有价值）：每个故事都应该能为用户或客户创造价值。
     • E（Estimable，可估算）：故事的工作量应该可以估算。
     • S（Small，小）：用户故事应该足够小，能在一个迭代周期内完成。
     • T（Testable，可测试）：故事应该具有明确的验收标准，能够进行验证。

第6章：用户故事的拆解与分解

1. 拆解的必要性：

   • 较大的用户故事（Epic）需要拆解成较小的子故事（Story），以便开发团队可以更容易地规划、估算和实现。
   • 拆解不仅使工作更易于管理，还可以提高团队的工作效率和交付能力。

2. 拆解策略：

   • 按功能拆解：将一个复杂的功能分解成多个子功能，逐步实现。
   • 按用户角色拆解：根据不同的用户角色拆解功能，关注不同角色的需求。
   • 按数据拆解：拆解基于不同数据类型或数据处理流程的需求。
   • 按优先级拆解：从最重要、最急需的功能开始拆解，确保高优先级的需求优先被完成。

3. 拆解后的关键考虑：

   • 拆解后的用户故事应依然具备完整性和可交付性，避免拆解过度导致无法实现的“小而琐碎”的任务。

第7章：用户故事的估算

1. 估算的目的：

   • 估算帮助团队确定工作量，进行合理的迭代计划，并为项目提供时间管理和进度控制依据。

2. 常见的估算方法：

   • 故事点：使用相对的复杂性来为每个用户故事分配估算值。通常采用一个斐波那契数列（如1、2、3、5、8等）来表示故事的复杂性。
   • 理想工作日：将每个故事的工作量估算为完成所需的“理想工作日”数，即排除外部干扰的情况下，完成任务需要多少天。
   • 规划扑克：团队成员使用扑克卡片（每张卡片上写有数字）来集体估算用户故事。通过讨论和共识，达成估算。
   • T-shirt sizes：用类似T恤尺寸（S、M、L、XL）来表示工作量的大小，适用于初步规划阶段，帮助快速估算。

3. 估算的挑战与注意事项：

   • 估算永远是一个粗略的过程，必须随着项目的进展不断调整。团队应该保持灵活，定期回顾和调整估算结果。

第8章：用户故事的优先级排序

1. 优先级排序的目的：

   • 确保团队始终集中精力在最具价值、最重要的用户故事上，实现增量交付和高效的客户价值输出。

2. 优先级排序方法：

   • MoSCoW方法：
     • Must：必须做的需求，若不做将导致项目失败。
     • Should：应该做的需求，重要但不至于影响项目成功。
     • Could：可以做的需求，若做了会增加价值，但不是必须的。
     • Won't：当前版本不做的需求，团队需明确哪些需求被排除。
   • Kano模型：通过将需求分为基本需求（必需的），期望需求（客户期望的），和兴奋需求（令人惊喜的），来帮助团队优先考虑那些能显著提升客户满意度的功能。
   • 价值与复杂度矩阵：将用户故事放入一个二维矩阵中，横轴表示复杂度，纵轴表示价值。团队应优先处理高价值、低复杂度的故事。

3. 与客户沟通的重要性：

   • 在敏捷项目中，优先级排序并非一劳永逸。需求和优先级会随着客户反馈和市场环境的变化而变化，因此，团队应与客户保持持续沟通，定期审视和调整优先级。