版权声明：原创文章，转载请保留此声明，谢绝商业用途Copy。 https://blog.csdn.net/prufeng/article/details/80445890
《用户故事地图》
Jeff Patton
故事地图是一门在需求拆分过程中保持全景图的艺术。
故事地图可以使我们专注于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。
使用用户故事的目的并不是为了写出更好的用户故事。
产品开发的目的也并不是开发出产品。
共享文档并不代表达成共识。
使用用户故事的目的是达成共识。
文档是用来备忘的。
实际上，你的工作是改变世界。
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。
只有满足顾客和用户的需求，公司才能实现自己的诉求。
想要开发的功能，总是比你能投入开发的资源多。
最小化输出，最大化成果和影响。
用户故事不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片相结合的方式辅助讨论，这是一种建立共识的机制。
用户故事也不是需求，用户故事是关于问题解决方案的讨论，解决公司的问题，解决客户的问题，解决用户的问题，目的是我们对要开发的功能达成共识。
你的工作不是更快开发更多功能，而是使那些投入精力开发的功能在成果和影响上可以最大化。
1，产品前景图
故事是讲出来的，不是写出来的。
用户故事地图，就是在讲大故事的同时进行拆分。
边讲边记：在讲故事的同时，通过写卡片或便签来具体化你的想法。
整理对产品的创意框架。
刻画用户画像。
使用卡片，能够提升沟通的默契程度。
使用用户故事地图可以提前识别产品创意中有哪些坑。
聚焦于故事的整体，不要过早陷入细节。
探索细节和可选项。
2，计划，为了更少的开发
想要开发的功能，总是超出你能投入开发的资源。
故事地图帮助大型组织建立共识。
贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。
创建故事地图的过程可以帮助发现设计中的坑。
需求范围并没有蔓延，而是我们对需求的理解更深刻了。
聚焦系统外的预期成果来决定系统内需要什么功能。
划分发布路线图。
为成果排优先级，而非功能。
最小可行产品是为验证假设而做的最小规模的实验。
3，计划，为了更快的学习
对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。
验证产品要解决的问题是否真的存在。
在设计原型过程中学习。
手绘线框图和高保真原型可以帮助你具象化解决方案。
通过原型和用户测试验证产品方案是否真的有用，有价值。
能够质疑用户所说的内容。
在开发过程中学习。
迭代直至可行。
把每次发布都当成一次实验，关注于自己要学习的东西。
4，计划，为了按时发布
故事地图要做到什么程度？以能够支持沟通为限呗！
最靠谱的估算，来自真正理解自己在估算什么的工程师。
制定可逐步达成的计划。
不要将所有迭代产出都对外发布。
使用故事地图管理风险。
伟大的作品永远没有完成这回事，只有放弃。——达芬奇
运用迭代思维持续评估和打磨作品。
运用增量思维。
根据开发策略切分故事地图。
5，如何创建故事地图
分步骤写出你的故事
组织情节
探索替代故事
提取故事地图的主干
切分出能帮你达成特定目标的任务
用户任务是构建故事地图的基本模块
使用目标层级的概念，可以帮助汇总小任务或分解大任务。
故事地图通过自左向右的叙事流来组织，这种概念是人们讲故事最自然的方式。
细节、替代、变化和异常，构成故事地图的主体。
活动组成故事地图的主干。
使用文字和图片相结合的方式辅助讲故事，达成共识。
不要只谈论开发什么功能，要关注哪些用户会用以及为什么这样做就能以最小的投入获得最大的产出。
6，用户故事的故事
同样一份文档，阅读的人不同，各自得到的信息也不一样。
最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作。
用户故事之所以得名，并不是要人们如何写出更好的用户故事，而是如何在协作中更好地使用它。
如果团队没有聚在一起对用户故事进行充分的讨论，就说明你们运用用户故事的方式不对。
7，如何把故事讲得更好
使用故事模板来引发讨论
作为［一个用户］，我想要［某个产品特性］，这样我就可以［获得某种收益］
用户角色［who］
功能［what］
为什么［why］
提升讨论效果的检查单
8，不要把所有内容都写在卡片上
9，卡片只是开始
在头脑中构建清晰的图像
养成口述用户故事的习惯
检视产出（用户体验质量，功能质量，代码质量）
验证性学习胜过可工作的软件（或者面面俱到的文档）
尝试通过用户故事来驱动所有的事情，不论软件或是其他。
10，做产品好比烤蛋糕
如果故事描述的方案过于昂贵，就应当考虑替代方案。
如果故事描述的方案符合预算，但仍然很大，那么切分成小块可以帮助你更及时地评估产品和把控进度。
不要把大故事切到大计划中。把大故事切小，做小计划。
11，碎石行动
从用户角度看，大小规模恰当的故事，是一个可以满足某一需要的故事。
从开发团队角度看，大小规模适当的故事，是一个只需要几天时间就可以完成开发和测试的故事。
从业务角度，大小规模适当的故事，是一个有助于实现业务目标的故事。
对话是拆分故事的最好工具之一。
使用机会讨论来达成问题是否值得解决的共识，最终作出继续进行或取消的决策。
通过探索和对话，力求找到最小的、可行的方案。
通过深潜式故事工作坊来讨论细节，拆分故事，并对我们将要开发的内容达成共识。
开始开发产品细节时，通过对话的方式对正在开发的软件给出反馈信息。
经常反思产品质量、工作计划和工作方式。
拿有意义的工作软件模块去测试客户和用户，并从中学习。
对组织内的干系人而言，项目的进度和完成质量要保持持续可见。
运用度量和直接接触来真正了解结果是否达到预期。
12，谁是碎石负责人
产品经理——打造一个有价值、可用且可行的产品。
组建一个核心团队来协助产品负责人，包括用户体验专家、设计专家和技术专家。
身为产品负责人，要兼顾其他干系人的想法，扮演制作人的角色，帮助他们获得成功。
13，从机会开始
针对机会展开对话
深入挖掘机会，丢弃机会或思考机会。
通过重绘旅程地图来挑战假设。
Jeff Patton
故事地图是一门在需求拆分过程中保持全景图的艺术。
故事地图可以使我们专注于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。
使用用户故事的目的并不是为了写出更好的用户故事。
产品开发的目的也并不是开发出产品。
共享文档并不代表达成共识。
使用用户故事的目的是达成共识。
文档是用来备忘的。
实际上，你的工作是改变世界。
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。
只有满足顾客和用户的需求，公司才能实现自己的诉求。
想要开发的功能，总是比你能投入开发的资源多。
最小化输出，最大化成果和影响。
用户故事不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片相结合的方式辅助讨论，这是一种建立共识的机制。
用户故事也不是需求，用户故事是关于问题解决方案的讨论，解决公司的问题，解决客户的问题，解决用户的问题，目的是我们对要开发的功能达成共识。
你的工作不是更快开发更多功能，而是使那些投入精力开发的功能在成果和影响上可以最大化。
1，产品前景图
故事是讲出来的，不是写出来的。
用户故事地图，就是在讲大故事的同时进行拆分。
边讲边记：在讲故事的同时，通过写卡片或便签来具体化你的想法。
整理对产品的创意框架。
刻画用户画像。
使用卡片，能够提升沟通的默契程度。
使用用户故事地图可以提前识别产品创意中有哪些坑。
聚焦于故事的整体，不要过早陷入细节。
探索细节和可选项。
2，计划，为了更少的开发
想要开发的功能，总是超出你能投入开发的资源。
故事地图帮助大型组织建立共识。
贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。
创建故事地图的过程可以帮助发现设计中的坑。
需求范围并没有蔓延，而是我们对需求的理解更深刻了。
聚焦系统外的预期成果来决定系统内需要什么功能。
划分发布路线图。
为成果排优先级，而非功能。
最小可行产品是为验证假设而做的最小规模的实验。
3，计划，为了更快的学习
对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。
验证产品要解决的问题是否真的存在。
在设计原型过程中学习。
手绘线框图和高保真原型可以帮助你具象化解决方案。
通过原型和用户测试验证产品方案是否真的有用，有价值。
能够质疑用户所说的内容。
在开发过程中学习。
迭代直至可行。
把每次发布都当成一次实验，关注于自己要学习的东西。
4，计划，为了按时发布
故事地图要做到什么程度？以能够支持沟通为限呗！
最靠谱的估算，来自真正理解自己在估算什么的工程师。
制定可逐步达成的计划。
不要将所有迭代产出都对外发布。
使用故事地图管理风险。
伟大的作品永远没有完成这回事，只有放弃。——达芬奇
运用迭代思维持续评估和打磨作品。
运用增量思维。
根据开发策略切分故事地图。
5，如何创建故事地图
分步骤写出你的故事
组织情节
探索替代故事
提取故事地图的主干
切分出能帮你达成特定目标的任务
用户任务是构建故事地图的基本模块
使用目标层级的概念，可以帮助汇总小任务或分解大任务。
故事地图通过自左向右的叙事流来组织，这种概念是人们讲故事最自然的方式。
细节、替代、变化和异常，构成故事地图的主体。
活动组成故事地图的主干。
使用文字和图片相结合的方式辅助讲故事，达成共识。
不要只谈论开发什么功能，要关注哪些用户会用以及为什么这样做就能以最小的投入获得最大的产出。
6，用户故事的故事
同样一份文档，阅读的人不同，各自得到的信息也不一样。
最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作。
用户故事之所以得名，并不是要人们如何写出更好的用户故事，而是如何在协作中更好地使用它。
如果团队没有聚在一起对用户故事进行充分的讨论，就说明你们运用用户故事的方式不对。
7，如何把故事讲得更好
使用故事模板来引发讨论
作为［一个用户］，我想要［某个产品特性］，这样我就可以［获得某种收益］
用户角色［who］
功能［what］
为什么［why］
提升讨论效果的检查单
8，不要把所有内容都写在卡片上
9，卡片只是开始
在头脑中构建清晰的图像
养成口述用户故事的习惯
检视产出（用户体验质量，功能质量，代码质量）
验证性学习胜过可工作的软件（或者面面俱到的文档）
尝试通过用户故事来驱动所有的事情，不论软件或是其他。
10，做产品好比烤蛋糕
如果故事描述的方案过于昂贵，就应当考虑替代方案。
如果故事描述的方案符合预算，但仍然很大，那么切分成小块可以帮助你更及时地评估产品和把控进度。
不要把大故事切到大计划中。把大故事切小，做小计划。
11，碎石行动
从用户角度看，大小规模恰当的故事，是一个可以满足某一需要的故事。
从开发团队角度看，大小规模适当的故事，是一个只需要几天时间就可以完成开发和测试的故事。
从业务角度，大小规模适当的故事，是一个有助于实现业务目标的故事。
对话是拆分故事的最好工具之一。
使用机会讨论来达成问题是否值得解决的共识，最终作出继续进行或取消的决策。
通过探索和对话，力求找到最小的、可行的方案。
通过深潜式故事工作坊来讨论细节，拆分故事，并对我们将要开发的内容达成共识。
开始开发产品细节时，通过对话的方式对正在开发的软件给出反馈信息。
经常反思产品质量、工作计划和工作方式。
拿有意义的工作软件模块去测试客户和用户，并从中学习。
对组织内的干系人而言，项目的进度和完成质量要保持持续可见。
运用度量和直接接触来真正了解结果是否达到预期。
12，谁是碎石负责人
产品经理——打造一个有价值、可用且可行的产品。
组建一个核心团队来协助产品负责人，包括用户体验专家、设计专家和技术专家。
身为产品负责人，要兼顾其他干系人的想法，扮演制作人的角色，帮助他们获得成功。
13，从机会开始
针对机会展开对话
深入挖掘机会，丢弃机会或思考机会。
通过重绘旅程地图来挑战假设。
14，通过探索来建立共识
探索不是开发软件
A. 我们实际想要解决哪些问题？
B. 哪些方案对我们的组织和购买该产品的客户有价值？
C. 基本可用的方案是什么样子？
D. 在现有时间和工具的前提下，可以开发哪些功能特性？
探索的4个核心步骤
A. 从业务角度来组织想法。
B. 理解客户和组织，搞清楚怎样做才能帮到他们。
C. 把自己的解决方案呈现出来。
D. 简化并计划最小化的可行方案及其具体开发方式。
一起创建轻量级的用户画像，力求在团队中建立共识和同理心。
用户界面可视化，以求对解决方案达成共识。
如果保留下来的想法超出扔掉不用的想法，就说明你的探索工作可能没做对。
可行意味着对特定商业策略、目标客户和用户都是成功的。
15，通过探索来进行验证性学习
大多数时候，我们其实都是错的。
同理，聚焦，形成想法，做原型，测试。
Design Thinking: Empathize, Define[Focus], Ideate, Prototype, Test
直接与客户和用户交谈，亲身体验你想帮他们解决的实际困难。
实际聚焦于一个或多个问题并加以详细阐述。
有意识地针对客户和用户的问题构思若干个可能的解决方案。
制作简单的原型进行探索，得出最好的解决方案。制作有一定保真度的原型，让用户和客户可以评价解决方案是否真的可以解决他们的问题。
将解决方案拿给可能购买或使用产品的人看。不要期望他们一开始就能取得成功。不断加以迭代和完善。
精益创业（Lean Startup）思想改变产品设计。
在精益创业中，学不到东西往往才是最大的失败。
16，提炼、定义和开发
人人参与并非明智之举。
使用用户地图来可视化进展。
17，故事呢，就好比《行星战机》
对故事循序渐进进行分解，而不是一次性完成。
每一个故事讨论和分解阶段，都要一心想着目标。
聚焦小故事，清理待办列表。
地图绘制要适度。
18，开发完成后怎么学习
团队回顾三要素
产品：用户体验的质量，功能上的质量，代码的质量
计划：工作量预估完成情况
过程：哪些做事方式可以改进
为产品建立度量指标，追踪新功能的使用情况。
在用户使用新产品时安排时间对他们进行观察。
使用故事地图来评估发布是否准备就绪。
读者心声：
用户购买的不是你的产品，而是更好的自己。
你的产品是用户通往更好自己的解决方案。
探索不是开发软件
A. 我们实际想要解决哪些问题？
B. 哪些方案对我们的组织和购买该产品的客户有价值？
C. 基本可用的方案是什么样子？
D. 在现有时间和工具的前提下，可以开发哪些功能特性？
探索的4个核心步骤
A. 从业务角度来组织想法。
B. 理解客户和组织，搞清楚怎样做才能帮到他们。
C. 把自己的解决方案呈现出来。
D. 简化并计划最小化的可行方案及其具体开发方式。
一起创建轻量级的用户画像，力求在团队中建立共识和同理心。
用户界面可视化，以求对解决方案达成共识。
如果保留下来的想法超出扔掉不用的想法，就说明你的探索工作可能没做对。
可行意味着对特定商业策略、目标客户和用户都是成功的。
15，通过探索来进行验证性学习
大多数时候，我们其实都是错的。
同理，聚焦，形成想法，做原型，测试。
Design Thinking: Empathize, Define[Focus], Ideate, Prototype, Test
直接与客户和用户交谈，亲身体验你想帮他们解决的实际困难。
实际聚焦于一个或多个问题并加以详细阐述。
有意识地针对客户和用户的问题构思若干个可能的解决方案。
制作简单的原型进行探索，得出最好的解决方案。制作有一定保真度的原型，让用户和客户可以评价解决方案是否真的可以解决他们的问题。
将解决方案拿给可能购买或使用产品的人看。不要期望他们一开始就能取得成功。不断加以迭代和完善。
精益创业（Lean Startup）思想改变产品设计。
在精益创业中，学不到东西往往才是最大的失败。
16，提炼、定义和开发
人人参与并非明智之举。
使用用户地图来可视化进展。
17，故事呢，就好比《行星战机》
对故事循序渐进进行分解，而不是一次性完成。
每一个故事讨论和分解阶段，都要一心想着目标。
聚焦小故事，清理待办列表。
地图绘制要适度。
18，开发完成后怎么学习
团队回顾三要素
产品：用户体验的质量，功能上的质量，代码的质量
计划：工作量预估完成情况
过程：哪些做事方式可以改进
为产品建立度量指标，追踪新功能的使用情况。
在用户使用新产品时安排时间对他们进行观察。
使用故事地图来评估发布是否准备就绪。
读者心声：
用户购买的不是你的产品，而是更好的自己。
你的产品是用户通往更好自己的解决方案。