序言
在面对庞大的需求文档时，采用僵化刻板的文档和精确语言或许并不是解决问题的最佳途径。问题的关键不在于复杂性，而在于简洁性。解决方案并非在前期详细定义细节，而是在及时响应、根据需求灵活开发。这一切并非仅仅依赖于文档，而更需要紧密的沟通。
用户故事的目标：
用户故事的目标在于更迅速、更高效地应对变化。在你还在辛苦编写需求文档时，竞争对手的系统可能已经上线运行。转变思维方式，不再过于谨慎地记录每个需求的细节，而是通过用户故事提供一种方法，使我们能够制定可估算的计划，并促进沟通。
需要注意的是，用户故事等非技术实践的实施可能并不复杂，但必须与技术手段如TDD、CICD、重构等结合，否则产生高质量的代码就只是空谈。国内对敏捷方法的关注不断增加，然而讨论更多的是关于Scrum这种管理概念框架，而对于如何减少技术负债、如何进行良好的单元测试等技术层面的话题则较为匮乏。对于从事软件开发的人员来说，这是一个不可轻视的问题。
第1章 概览
软件需求是一个沟通问题，任何一方垄断沟通都会导致项目受损。我们需要一种协同工作的方式，让双方都不占主导地位，共同面对情感和办公室政治导致的资源分配问题。
在用户看到软件的早期版本时，往往会提出新的点子，使我们无法在项目开始时完美规划所有必须完成的事情。解决方法不是在项目开始时试图做出全面的决策，而是将决策分散到项目过程中。为此，我们需要确保有一个信息获取的通道，而用户故事由此产生。
什么是用户故事？
用户故事代表一个独立的功能，即用户在一个单一环境中可能做的事情。它描述了对用户有价值的功能，由三个方面组成：card（书面描述）、conversation（对话，具体化细节）和confirmation（验收测试，确定完成时机）。card虽然是用户故事最显著的表现，但并非最重要，因为它代表用户需求而非记录需求。需求细节应在对话中获取，并在验收测试中得以记录。
什么是验收测试？
验收测试用于验证用户故事的实现是否符合客户团队的期望。测试工作应尽早进行，编写测试用例对于澄清预期和提醒可能被忽略的情况非常有用。由于用户故事的重心从文档转移到对话，重要的决策不再写在文档中，而是在自动化验收测试中捕获，频繁执行验证。
第2章 编写故事
一个优秀的故事应具备以下特点：
- 独立性： 尽量避免相互依赖，有利于排期。
- 可讨论性： 故事是可以讨论的，而非签署的合同或必须实现的需求。故事卡提醒我们要进行讨论，不需要包含所有相关细节。
- 对用户有价值： 最好由客户编写故事，以确保每个故事对用户有价值。
- 可估算性： 让开发人员能估算故事的大小，至少能猜一下。
- 小型化： 涉及复杂故事的拆分和简单故事的合并。拆分采用简单方法，如“创建”、“删除”、“修改”、“查询”来分解故事。
- 可测试性： 尽可能进行测试自动化，帮助早期发现问题。
第3章 用户角色建模
步骤概述：
-
头脑风暴角色：
- 团队通过头脑风暴，尽可能列出初始的用户角色集合。
- 鼓励创意，这个阶段的目标是收集尽可能多的潜在用户角色。
-
整理初始集合：
- 移动卡片的位置，以展示角色之间的关系。
- 这有助于团队更好地理解角色之间的相互作用和依赖关系。
-
整合和拆分：
- 试着整合、拆分或删除一些角色，以简化整个模型。
- 这可以避免角色过于复杂，使得管理和设计更加清晰。
-
提炼角色：
- 为每个角色定义特征，例如使用软件的频率、领域知识水平、计算机和软件的总体水平等。
- 特征有助于更好地理解每个用户角色的特定需求和期望。
-
虚构人物和极端人物：
- 对于重要的用户，创建虚构人物，确保他们能真正代表产品的目标用户。
- 考虑极端人物，例如，想象教皇如何使用软件，以获得新的灵感。
用户角色卡片样例：
-
角色名称： 求职者
-
特征：
- 使用软件频率：每天
- 领域知识水平：中等
- 软件和计算机水平：高
- 对当前软件熟悉程度：初级
- 软件使用目标：找到理想工作
-
角色名称： 雇主
-
特征：
- 使用软件频率：每周
- 领域知识水平：高
- 软件和计算机水平：中等
- 对当前软件熟悉程度：高级
- 软件使用目标：招聘合适的候选人
第4章 搜集故事
-
捕鱼比喻：
- 使用不同大小的“渔网”捕获不同大小的需求，形成对软件整体感觉。
- 需求会变化，有重要性和复杂度的差异。
- 了解需求的过程类似于捕鱼，需要灵活性和适应性。
-
传统过程与敏捷过程的区别：
- 传统过程强调在项目早期获取并写出所有需求。
- 敏捷过程承认不可能在单一阶段获取所有用户故事，需求随时间演变。
-
轻量、可持续的故事搜集方法：
- 用户访谈：提开放性问题，深入了解用户需求。
- 问卷调查：适用于大量用户关于特定问题的答案。
- 观察：观察用户使用软件，提高用户体验和生产力。
- 故事编写工作坊：结合头脑风暴和简单原型法，快速捕获故事。
-
故事编写工作坊示例：
- 选择用户角色（例如，求职者）。
- 从空白方框开始，为每个组件和交互编写故事。
- 通过深度优先方式，逐步展开与每个组件相关的故事。
- 问自己关于用户行为的问题，以找到可能遗漏的故事。
