需求分析

需求分析 — 书籍精读总结

1. Are Your Lights On?（你的灯亮着吗？） — Gerald Weinberg & Donald Gause

核心论点

Are Your Lights On? 的核心论点是：大多数问题的根源不在于找不到解决方案，而在于一开始就没有正确定义问题。 本书认为，问题定义是解决问题过程中最困难、也最容易被忽视的环节。在急于寻找解决方案之前，我们必须先问：问题是什么？这是谁的问题？问题从哪里来？我们真的想解决它吗？

主要原则与框架

第一部分：问题是什么？

“问题是期望与感知之间的差距。” 这是 Weinberg 和 Gause 的基础定义。问题不是客观事实——它存在于某人期望的状态和感知到的状态之间的差距中。
虚假问题 vs. 真实问题。 人们常常解决了错误的问题，因为他们接受了最先遇到的问题描述。作者建议读者不断追问”问题到底是什么？“，因为最初的问题框架几乎总是不完整或具有误导性的。
问题描述本身就是一个问题。 问题的表述方式会限制解决方案的空间。糟糕的问题框架会让好的解决方案变得不可见。

第二部分：问题到底是什么？

“不要把别人的解决方法当作问题定义。” 人们经常带着一个现成的解决方案来找你（“我们需要一个更大的数据库”），而实际问题可能完全不同（“我们无法快速找到客户记录”）。作者警告不要将提议的解决方案与根本问题混为一谈。
每个问题定义同时也是一个解决方案的陈述。 改变问题描述的措辞就会改变解决方案的空间。作者鼓励用多种不同的方式重新表述问题，以揭示隐藏的假设并打开新的思路。
“如果你太轻松地解决了他们的问题，他们永远不会相信你解决了他们真正的问题。” 这是一个社会心理学洞察：人们不信任那些对他们苦恼已久的问题给出的简单解决方案。即使解决方案是正确的，感知到的努力程度也很重要。

第三部分：这是谁的问题？

“如果这是他们的问题，就让它成为他们的问题。” 这是本书最著名的原则之一。并非每个问题都需要由你来解决。通常正确的做法是把问题交还给真正的问题拥有者。
“谁有这个问题？” 报告问题的人、受问题影响的人和必须解决问题的人，往往是三个不同的人。错误地识别利益相关者会导致白费力气和错误的解决方案。
“Billy Brighteyes” 的故事。 书中反复出现的一个例子：一个聪明的年轻工程师没有用工程手段来解决大楼电梯太慢的投诉，而是用社会洞察力——在大厅安装镜子，让人们在等待时有事可做，从而消除了”电梯太慢”这个感知问题。

第四部分：问题从哪里来？

“谁制造了这个问题？他们的动机是什么？” 问题不会凭空出现。某个人或某个系统产生了它们。理解问题的来源往往比研究问题的症状更能揭示问题的本质。
“归根结底，是人创造了问题。” 技术问题几乎总是可以追溯到人的决策、假设或疏忽。
“山间公路入口处的隧道”案例。 司机从阳光下驶入黑暗的隧道时会目眩。隧道入口处放置了一个标志”Are Your Lights On?”（你的灯亮着吗？）。这解决了安全问题——但又产生了新问题：人们忘记关灯导致电池耗尽。于是需要一个新标志：“Are Your Lights On?” 在隧道两端都适用——进入时提醒开灯，离开时提醒关灯。这个例子就是书名的由来，它说明了解决问题的方案往往会产生新的问题。

第五部分：我们真的想解决它吗？

“不是每个问题都需要解决方案，也不是每个解决方案都值得实施。” 作者提醒，解决问题的成本可能超过与问题共存的成本。
“如果你想不出至少三个可能理解错误的地方，说明你还不够理解这个问题。” 这个启发式方法迫使人们在投入解决方案之前更深入地审视问题。
道德维度。 有些问题之所以持续存在，是因为解决它们会给有权势的人带来不便。作者建议诚实地评估一个问题在给定的政治或组织环境中是否真的可以解决。

重要案例与隐喻

电梯/镜子的故事 — 证明了”真正的问题”（感知等待时间）并非”表述的问题”（电梯太慢）。
“Are Your Lights On?” 隧道标志 — 一个既是问题又是解决方案的短语，说明了问题定义的递归特性。
会议室温度问题 — 同一房间里不同的利益相关者对同样的温度有不同的感受，说明”问题”取决于你从谁的角度来看。

实用技巧

在尝试解决方案之前，至少用三种不同的方式重新表述问题。
问”这是谁的问题？“并确认你正在为正确的人解决问题。
问”这个问题从哪里来？“以追溯根本原因。
对你的问题理解进行”三个可能出错的地方”测试。
考虑什么都不做——确认问题是否值得解决。

常见陷阱

没有定义问题就急于寻找解决方案。
不加质疑地接受别人对问题的框架。
将提议的解决方案与实际问题混淆。
为错误的利益相关者解决问题。
未能预见你的解决方案会产生新的问题。

2. Specification by Example（实例化需求） — Gojko Adzic

核心论点

Specification by Example 认为，构建正确软件的最有效方式是使用具体的例子作为定义、验证和记录需求的主要载体。 这些由业务利益相关者、开发人员和测试人员协作编写的例子，会成为可执行的规格说明，充当”活文档”（Living Documentation）——因为它们通过自动化测试与运行中的系统进行验证，所以始终保持最新。

主要原则与框架

关键流程模式

Adzic 从全球 50 多个团队的案例研究中，总结了一套成功团队遵循的关键流程模式：

从目标推导范围。 从业务目标而非功能列表开始。先问”我们为什么需要这个？“再问”它应该做什么？“这可以防止构建不符合业务目标的功能。
协作定义规格。 规格说明不应由单一人员（业务分析师、产品负责人）编写。它们应在”三人组”（Three Amigos）——业务人员、开发人员和测试人员——之间的结构化对话中产生。每个角色带来不同的视角，能发现不同类型的错误。
用例子来说明。 抽象的需求（“系统应处理高并发”）被具体的例子取代（“当 10,000 个用户同时提交订单时，所有订单在 2 秒内处理完毕”）。具体的例子消除了模糊性。
精炼规格说明。 从工作坊中收集的原始例子需要被整理成清晰、精确的规格说明。去除冗余的例子，添加边界情况，收紧语言表述。
在不改变规格说明的前提下实现自动化验证。 规格说明（例子）通过自动化层与系统连接，但规格文本本身对非技术人员仍然可读。自动化层在规格说明的下方或后方，而不是嵌入其中。
频繁验证。 自动化规格说明应频繁运行（理想情况下每次提交都运行），以检测回归并确保活文档保持准确。
演进文档体系。 随着时间推移，可执行规格说明的集合将成为系统行为的权威文档。它取代了过时的 Word 文档和 Wiki，因为它保证是正确的——如果不正确，测试就会失败。

Living Documentation（活文档）

核心概念是 Living Documentation（活文档）：可执行的、与实际系统进行验证的文档。它保持准确，因为它是测试过程的副产品，而不是需要手动维护的独立产物。
活文档解决了一个长期存在的文档漂移问题——即书面规格与实际系统行为随时间推移而偏离。

Specification Workshop（规格说明工作坊）

规格说明工作坊（也称为”三人组会议”或 “Example Mapping 会议”）是业务、开发和测试协作定义例子的结构化会议。
其目的不是穷尽所有场景，而是建立共同理解并尽早暴露分歧。
输出是一组定义某个 Story 或功能预期行为的关键例子。

Key Examples vs. 全面测试套件

Specification by Example 并非穷尽测试。 为规格说明目的选择的例子应该是明确传达预期行为所需的最小集合。
穷尽的边界情况测试是测试人员的单独工作。

重要案例与故事

保险保费计算案例。 一个团队使用输入/输出表格来定义保险保费计算规格，业务专家和开发人员都能阅读和验证。这取代了一份无人阅读的 200 页需求文档。
“往返”案例。 成功采用 Specification by Example 的团队报告说，同一个产物同时充当需求、测试和文档——一次”往返”消除了重复工作。
“Given-When-Then” 格式。 虽然不是 Adzic 发明的，但本书大力推广了 Given-When-Then 结构（来自 BDD）作为表达例子的标准格式：Given [前置条件]，When [操作]，Then [预期结果]。
eBay 分类广告（Marktplaats）。 多个真实案例之一，团队采用 Specification by Example 后，缺陷和返工大幅减少。

实用技巧与工具

Example Mapping — 在规格说明工作坊中使用不同颜色的索引卡来表示规则、例子、问题和 Story。
Given-When-Then 格式来组织例子。
Concordion、FitNesse、Cucumber、SpecFlow — 书中提到的用于自动化可执行规格说明的工具。
将规格说明与代码一起放在版本控制中，使它们同步演进。
按功能领域组织规格说明，而非按 Sprint 或迭代，以创建可导航的文档结构。

常见陷阱

孤立编写规格说明 — 如果只有业务分析师写规格，共同理解就丧失了。
用过多的例子过度定义 — 规格说明应该是最小化和说明性的，而非穷尽的测试套件。
在规格说明中嵌入自动化细节 — 规格说明应保持对非技术人员可读；自动化管道应放在单独的层中。
不频繁运行规格说明 — 如果规格说明不在每次构建时验证，它们就会过时，失去活文档的价值。
将 Specification by Example 视为一种测试技术 — 它本质上是一种协作和沟通技术。测试是一个值得欢迎的副产品。
过度打磨规格说明语言 — 在工具和格式上花费过多时间，而忽略了真正重要的协作对话。

3. Exploring Requirements: Quality Before Design（探索需求：设计之前的质量） — Gerald Weinberg & Donald Gause

核心论点

Exploring Requirements 认为，需求本质上是模糊的，需求分析师的首要工作不是消除模糊性（这不可能），而是巧妙地管理它。 本书将需求收集呈现为一种探索——一个发现和协商的过程——而非机械的引导任务。质量必须在设计开始之前就内建到需求中，因为修复需求错误的成本随着项目推进呈指数增长。

主要原则与框架

需求的本质

“需求不是躺在那里等着被捡起来的。” 它们必须被主动探索、质疑和协商。用户往往不知道自己想要什么，直到他们看到自己不想要什么。
模糊性是根本挑战。 自然语言本质上是模糊的。一条需求声明可以被不同的利益相关者以多种有效方式解读。
“是的，但是”现象。 当用户看到交付的系统时，他们经常说”是的，但那不是我的意思。“这是原始需求中未解决的模糊性的症状。

需求发现的启发式方法

“Mary had a little lamb” 启发法。 通过在 “Mary had a little lamb” 这句话中对不同的词加重音，意思会发生巨大变化（MARY had a little lamb, Mary HAD a little lamb, Mary had a LITTLE lamb 等）。这说明即使是最简单的陈述中也潜藏着模糊性。将此技巧应用于需求：逐一强调每个词以揭示隐藏的假设。
“谁是客户？” — 一个根本性的问题。为系统付款的人、使用系统的人和维护系统的人可能都有不同的需求。需求分析师必须识别所有利益相关者，并在他们竞争性的需求之间进行协商。
“真正的产品是什么？” — 需求应描述真正需要的产品，而非某人假定需要的产品。这呼应了 Are Your Lights On? 中质疑问题定义的原则。
“Humpty Dumpty” 原则。 “当我使用一个词时，它就是我选择的那个意思。“不同的利益相关者对同一个词有不同的理解。分析师必须创建共享的定义。

好的需求的特征

需求应该是可测试的。 如果你无法判断一个需求是否已经被满足，那它不是需求——而是一个愿望。
需求应该是无歧义的（或者模糊性应该被明确承认和管理）。
需求应该是必要的。 每个需求都会增加成本；不必要的需求就是浪费。
需求应该是一致的。 需求之间不应相互矛盾。
需求应该是完整的 — 虽然完整的需求是一个理想，在实践中永远无法完全达到。
需求应该是可行的。 以现有技术和资源无法实现的需求是没有用的。
需求应该是可追溯的。 每个需求都应有已知的来源（谁提出的，为什么提出）。

Satisficing（满意即可）概念

借用 Herbert Simon 的概念，Weinberg 和 Gause 指出，在实践中，需求永远不会被完美定义。团队会 satisfice（满意即可） — 找到一组”足够好”的需求然后推进，同时知道需要迭代。

Context-Free Questions（上下文无关问题）

本书引入了 Context-Free Questions（上下文无关问题） — 无论项目领域如何都可以问的问题，包括：
- 谁是客户？
- 成功的解决方案对客户究竟值多少？
- 想要解决这个问题的真正原因是什么？
- 这个解决方案会带来什么问题？
- 产品将在什么环境中运行？
- 谁是用户？
- 解决方案的约束条件是什么？

“起点”问题

需求收集没有明确的起点。你无法在不了解解决方案空间的情况下定义需求，但你也无法在不了解需求的情况下评估解决方案。这种循环意味着需求探索本质上是迭代的。

Functions、Attributes 和 Constraints

本书区分了：
- Functions（功能） — 系统做什么（行为）。
- Attributes（属性） — 系统的质量特征（性能、可用性、可靠性）。
- Constraints（约束） — 解决方案的限制条件（必须在 Windows 上运行，预算不超过 10 万美元）。
许多需求失败源于只定义了功能，而忽略了属性和约束。

重要案例与隐喻

“Mary had a little lamb” — 上文描述的歧义演示，是书中最令人印象深刻的工具之一。
“搬家具”案例。 客户说”把家具搬一下。“但搬到哪里？哪些家具？什么时候搬完？假定自己知道对方意思的分析师一定会搞错。
“电梯问题”再探。 与 Are Your Lights On? 类似，但这里用来说明不同的利益相关者（楼宇业主、租户、维护人员、电梯制造商）对同一个系统有不同的需求。
“瑞士军刀”隐喻。 一个试图满足所有需求的产品会变得臃肿无用，就像一把有 200 个工具的瑞士军刀。

实用技巧

歧义调查。 将一条需求声明展示给多个利益相关者，让每人独立解读。比较解读结果以揭示隐藏的歧义。
上下文无关问题作为任何需求对话的结构化起点。
逐词强调测试需求声明中的每个词（“Mary had a little lamb” 技巧）。
用例和场景使抽象需求变得具体。
原型设计，尽早而非过晚地引出”是的，但是”的反馈。
需求分诊 — 确定哪些需求需要深入探索，哪些可以推迟。

常见陷阱

因为措辞看起来清楚就以为理解了需求。
只从一个利益相关者群体收集需求。
将解决方案与需求混淆。
将需求视为在任何时间点都是固定和完整的。
偏重功能性需求而忽略非功能性需求（属性和约束）。
在投入设计之前未对需求进行歧义测试。
允许政治因素压制合理的需求。

4. User Stories Applied: For Agile Software Development（用户故事实战：敏捷软件开发） — Mike Cohn

核心论点

User Stories Applied 认为，用户故事是敏捷项目中表达软件需求的最有效方式，因为它们强调对话和协作，而非文档。 用户故事不是详细的规格说明；它是开发团队与客户之间对话的占位符。真正的需求从对话中产生，而不是从卡片上写的内容产生。

主要原则与框架

用户故事格式

标准格式：“作为一个 [用户类型]，我想要 [某个目标]，以便 [某个原因]。”
三个组成部分（角色、目标、收益）确保每个需求都与真实的用户、真实的需要和真实的价值相关联。
“以便”从句至关重要——它传达了为什么，使开发人员在细节模糊时能做出更好的决策。

Three C’s（三个 C）

用户故事由三个组成部分构成，称为 Three C’s：

Card（卡片） — 写着故事的实体卡片（索引卡或等效物）。它被刻意设计得很小，以防止过度定义。卡片是一个提醒，而非完整的规格说明。
Conversation（对话） — 客户/产品负责人与开发团队之间的对话，用于充实细节。真正的需求在这里产生。
Confirmation（确认） — 定义故事何时完成的验收标准（或验收测试）。这些是故事被认为完成时必须通过的测试。

INVEST 准则

好的用户故事具有六个属性，用 INVEST 首字母缩略词概括：

I — Independent（独立的）。 故事之间应该相互独立，以便可以按任意顺序排列优先级、估算和开发。故事之间的依赖会造成计划上的复杂性。
N — Negotiable（可协商的）。 故事不是合同。细节由客户和开发团队协商。故事卡片捕捉的是核心要点，而非最终规格。
V — Valuable（有价值的）。 每个故事必须为用户或客户提供价值。技术故事（“重构数据库层”）应从用户价值的角度重新表述。
E — Estimable（可估算的）。 团队必须能够估算故事的大小。如果不能，故事要么太模糊，要么太大，需要拆分或澄清。
S — Small（小的）。 故事应该小到可以在单个迭代内完成。大故事（Epic）必须拆分成更小的故事。
T — Testable（可测试的）。 如果你无法为一个故事编写测试，你就无法知道它何时完成。不可测试的故事（“软件应该易于使用”）需要变得具体。

故事拆分技巧

Cohn 提供了几种拆分大故事的策略：

按工作流步骤拆分。 如果一个故事涵盖整个工作流，将其拆分为各个步骤。
按业务规则或变体拆分。 如果一个故事有多条业务规则，每条规则可以是一个独立的故事。
按数据变体拆分。 如果一个故事适用于不同的数据类型（如”按姓名、日期或 ID 搜索”），按数据类型拆分。
按接口拆分。 如果一个故事涵盖多个接口（Web、移动端、API），按接口拆分。
按操作拆分（CRUD）。创建、读取、更新和删除可以是独立的故事。
按性能拆分。 先”让它能用”，然后”让它快”作为单独的故事。
Spike Story（探索性故事）。 当由于技术不确定性而无法估算一个故事时，创建一个限时的研究 Spike 来降低不确定性，然后再编写真正的故事。

估算

Cohn 提倡使用 Story Points（故事点） 作为估算单位，表示相对工作量而非绝对时间。
Planning Poker（计划扑克） 是推荐的估算技巧：每位团队成员独立选择一张代表自己估算的卡片，同时亮牌，然后讨论差异直到达成共识。
Story Points 以一个参考故事为基准——一个团队充分理解的故事，被赋予一个基准点数值。
Velocity（速率） — 每次迭代完成的 Story Points 数量——用于规划和预测。

验收标准与测试

每个故事都应有验收标准，写在卡片背面（或作为附件文档）。
验收标准应由客户/产品负责人编写，可能在测试人员的帮助下。
它们定义了故事”完成”的边界，并作为验收测试的基础。
格式：简单的要点列表或 Given-When-Then 场景。

角色与 Persona

用户角色应在编写故事之前确定。Cohn 建议头脑风暴所有可能的用户角色，合并相似的角色，并创建一个角色模型 — 项目定义的角色集合。
Persona（用户画像） — 代表用户角色的虚构人物——增加了具体性和同理心。不要写”作为一个用户”，而是写”作为 Janet，一位不太懂技术的首次购房者”。
Persona 防止了为抽象的通用用户设计的陷阱。

收集故事

Cohn 列出了几种发现用户故事的技巧：

用户访谈 — 与实际用户的直接对话。
问卷 — 用于广泛收集意见的结构化调查。
观察 — 观察用户执行当前工作。
故事编写工作坊 — 多个利益相关者协作编写故事的引导式会议。
研究现有系统 — 研究当前系统（如有）以为其替代品推导故事。

重要案例

“BigMoneyJobs” 案例。 一个贯穿全书的求职网站案例研究，用于演示故事编写、拆分、估算和规划。
“作为一名招聘人员，我想发布一个职位，以便我能找到合格的候选人。” — 用来演示格式的经典用户故事示例。
“镀金”警告。 Cohn 描述了一些团队在故事中写了太多细节，使得卡片变成了迷你规格说明，违背了将故事作为对话起点的初衷。

实用技巧

对每个故事使用 “作为……我想要……以便……” 模板。
用 INVEST 检查清单评估故事质量。
使用 Planning Poker 进行估算。
为每个用户角色创建 Persona。
在开发开始前为每个故事编写验收标准。
举办故事编写工作坊协作收集故事。
使用 Spike Story 处理技术不确定性。

常见陷阱

编写过大的故事（伪装成故事的 Epic）。
编写没有”以便”从句的故事——丢失了理由。
编写技术故事而非面向用户的故事（“升级到 PostgreSQL 14”而非有用户价值的故事）。
将故事卡片视为完整的规格说明，而非对话的起点。
直到开发进行中才编写验收标准。
只由一个人（如产品负责人）编写所有故事，没有团队协作。
将 Story Points 当作工时来分配。
随着理解的变化不重新估算故事。

5. User Story Mapping: Discover the Whole Story, Build the Right Product（用户故事地图：发现完整故事，构建正确产品） — Jeff Patton

核心论点

User Story Mapping 认为，一个扁平的用户故事待办列表不足以理解整个产品。 待办列表丢失了叙事——用户试图完成什么的全景。故事地图通过将故事排列在二维地图上恢复了这种叙事：从左到右展示用户旅程，从上到下展示优先级。地图使得规划能够交付连贯的、端到端的用户体验的发布版本成为可能，而不是随机的功能集合。

主要原则与框架

故事地图的结构

故事地图有两个维度：

水平轴（从左到右）： 用户在系统中的旅程，按叙事流程排列（活动和任务执行的顺序）。
垂直轴（从上到下）： 优先级/细节，从顶部的核心功能到底部的锦上添花。

地图有几个层次：

Activities（活动）（最上面一行）— 将地图组织成若干区域的大型用户活动（如”浏览商品”、“下订单”、“管理账户”）。这些构成地图的骨干（Backbone）。
User Tasks（用户任务） — 在每个活动下方，用户执行的具体任务，从左到右按通常发生的顺序排列。当你从每个活动中取出最顶部的任务时，就构成了行走骨架（Walking Skeleton）。
Story Details（故事细节） — 在每个任务下方，充实该任务的各个用户故事，从最核心（顶部）到最不核心（底部）排列。

Backbone（骨干）

骨干是定义用户体验叙事流程的最上面一行活动。它提供了扁平待办列表所缺乏的”全景”。
骨干回答的问题是：“用户在这个系统中做的主要事情是什么，大致按什么顺序做？“

Walking Skeleton（行走骨架）

Walking Skeleton（行走骨架） 是最薄的端到端实现：骨干中每个活动各选一个故事。它是允许用户走通整个系统的最小功能集，即使每一步都是粗略和最简的。
行走骨架是第一个发布目标。它证明系统架构可以端到端工作，并给用户提供可以做出反馈的实物。
[解读] 这个概念与其他敏捷和架构文献中的 “Steel Thread”（钢丝线）或 “Tracer Bullet”（追踪子弹）概念密切相关。

共同理解优于文档

“共同理解才是真正的目标。” Patton 认为，需求活动的目的不是产出文档，而是在团队中建立共同理解。文档是副产品，不是目标。
“卡片只是对话的标记。” 呼应 Mike Cohn 的观点，Patton 强调故事是提醒，而非规格说明。
“先聊再记” — 先进行对话，然后只记录足以支持记忆的内容。过早编写太多文档会扼杀协作。

Output Is Not Outcome（产出不等于成果）

“最小化产出，最大化成果。” 构建更多功能（产出）并不保证为用户带来更好的结果（成果）。故事地图帮助团队聚焦于实现期望用户成果所需的最小功能集。
“不是构建完就算完成；用户的生活变得更好才算完成。” 这将”完成”的概念从开发视角重新定义为用户视角。

使用故事地图进行发布规划

要规划发布，在故事地图上画水平线。第一条线上方的所有内容是 Release 1（行走骨架 / MVP）。第一条线和第二条线之间的内容是 Release 2，依此类推。
每个发布版本都应交付连贯的用户体验切片 — 用户在每个版本中都应能完成有意义的事情，而不是拥有一堆不相关的功能。
Patton 称之为**“切蛋糕”** — 每一片都包含每一层的一点（每个活动的一点），而不是完全构建一个活动后再开始下一个。

Discovery 与 Delivery

Patton 区分了 Discovery（发现，弄清楚要构建什么） 和 Delivery（交付，构建它）。
故事地图主要是一个 Discovery 工具。它帮助团队在承诺解决方案之前探索问题空间。
“少构建” — 这是 Patton 反复强调的口号之一。故事地图使你提议构建的内容量一目了然，这通常会导致缩减范围。

“Rocks, Boulders, and Pebbles”（石头、巨石和鹅卵石）概念

Patton 使用一个故事粒度层级：
- Epics / Activities（史诗/活动） — 最大的单位，对应骨干项目。
- Features / Tasks（功能/任务） — 中等级别，对应用户任务。
- Stories / Details（故事/细节） — 最小的可实现单位。
故事地图使这个层级结构可见且可导航。

重要案例与隐喻

“Gary 的早晨日常” 案例。 Patton 通过映射一个人的早晨日常（起床、洗澡、吃早餐、通勤）来教授故事地图的基本机制。活动是骨干，任务是细节，你可以通过决定哪些早晨活动做完整版、哪些做最简版来”规划发布”（例如，“跳过洗澡、路上买咖啡”就是 MVP 早晨）。
“扁平待办列表”问题。 Patton 描述了面对 300+ 故事的待办列表却无法看出产品做什么的情况。故事地图通过恢复叙事结构解决了这个问题。
“想象你在拍一部关于用户的纪录片。” 这个框架帮助团队将用户旅程视为一个有开头、中间和结尾的叙事。
蒙娜丽莎类比。 你不会通过先完美画完左眼、再画右眼、再画鼻子来画蒙娜丽莎。你先勾勒出整个轮廓（行走骨架），然后逐层添加细节。发布版本也应如此。

实用技巧

与整个团队协作构建故事地图（开发人员、设计师、产品负责人、利益相关者），在墙上使用便利贴。
从骨干开始 — 识别主要的用户活动。
走通叙事 — 从左到右讲述用户的故事。
垂直添加细节 — 在每个活动下方，按优先级顺序添加任务和故事。
水平切片发布 — 画线定义发布边界。
用地图进行 Sprint 规划 — 地图提供了扁平待办列表所没有的上下文。
识别行走骨架 — 最薄的端到端切片。
随着理解的演进，审查和修订地图。
使用”现在和以后”的思维 — 什么必须在第一个版本中，什么可以等待？

常见陷阱

将待办列表当作计划。 一个排好优先级的故事列表不是产品愿景。没有故事地图的叙事结构，团队就会失去全局视野。
深度优先地”一次构建一个切片”。 完全构建产品的一个区域再开始下一个，会导致集成滞后，直到最后才有端到端的用户体验。
独自做地图。 故事地图是一项协作活动。如果一个人构建地图然后展示，就失去了共同理解的好处。
过度映射。 在开始开发之前试图映射每一个细节，本质上是伪装的瀑布模式。映射到足以规划下一个版本，然后迭代。
混淆故事地图与流程图。 故事地图遵循用户的叙事，而非系统的流程或数据流。要以用户为中心。
不回顾地图。 故事地图应随着团队的学习而演进。静态的地图和其他文档一样会过时。
关注产出（构建的功能）而非成果（解决的用户问题）。

跨书主题

以下主题在五本书中反复出现：

主题	相关书籍
先定义问题，再寻找方案	Are Your Lights On?、Exploring Requirements
协作优于文档	Specification by Example、User Stories Applied、User Story Mapping
模糊性不可避免，必须加以管理	Exploring Requirements、User Stories Applied、Specification by Example
具体例子胜过抽象描述	Specification by Example、Exploring Requirements、User Stories Applied
识别正确的利益相关者	Are Your Lights On?、Exploring Requirements、User Stories Applied
从小处开始，持续迭代	User Story Mapping（Walking Skeleton）、Specification by Example（Key Examples）、User Stories Applied（小故事）
对话是主要媒介	User Stories Applied（Three C’s）、User Story Mapping（共同理解）、Specification by Example（规格说明工作坊）
解决方案会产生新问题	Are Your Lights On?、Exploring Requirements
需求永远不会”完成”	全部五本书