开篇必读
作者写了近11页的使用前必读，简明扼要地阐述了本书核心思想。(本人觉得能深刻领悟这11页的内容就OK了)
用户故事的目的：达成共识
作者先是举了一个做蛋糕的例子，用户表述完想要什么样的蛋糕，店员记录下然后交给了师傅。但做出来的蛋糕并不是用户想的那个。
由此，引出共享文档并不代表达成共识。
作者建议停止写出完美的文档，因为就算是有方法写出完美文档，如果读文档的人产生了误解呢。所以，推荐大家坐在一起，使用更有效的方式讨论，使用文档+图片等结合的方式，使大家达成一致理解。
用户故事不是一种写需求文档的方式，而是一种建立共识的机制。它旨在鼓励敏捷开发中人与人之间沟通，而不是写下故事。如果你的项目上，只是写下故事，并没有使用文字和图片结合的方式讨论，那说明故事用错了。
好的故事：像度假时拍的照片
作者举例说：如果你来看我的度假照片，那只看到的是照片；而我能回忆起照片上的内容，因为我经历了整个过程。
也就是说，如果你充分参加了开发功能的讨论，然后基于讨论内容写出文档，各方就会对文档有一致的理解。没有参与讨论的人是无法通过读文档了解到细节的。
作者还认为，文档只是用来备忘。敏捷文档包括讨论、画图、记录，使用的是便签和故事卡。
你不是收集沟通，是改变世界
在创意和发布之间，所有的东西都可以叫“输出”，输出是我们开发出来的东西。过程输出并不那么重要，重要的是输出产生的成果。成果只有一个度量标准，即软件给用户解决问题的方式带来了什么样的变化，最重要的是，是否使这个世界变得更好。
你的目标一定不是只开发一个新产品，在讨论需求的的时候，就是讨论为谁开发，他们现在怎么做事情，他们的做事方式未来会有哪些变化。
好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。
少即是多
员工的目标也是帮助公司获得更多收入，保护即有市场、拓展新市场或帮助公司更高效地运营。因为如果公司不健康，员工就没有充分的资源可以帮助用户。
想要开发的功能总比你能投入开发的资源多。
最小化输出，最大化成果和影响。
最常见的错误理念就是，努力加快输出速度，有太多东西要做。但事实上你会发现你的工作不是开发更多而是开发更少功能。
你的工作不是更快开发更多功能，而是使那些投入精力开发的功能在成果和影响上可以最大化。
第一章 产品全景图
用户故事地图，就是在讲大故事的同时进行拆分。
边讲边计：在讲故事的同时 ，通过写卡片或便签来具体化你的想法。
思考 - 记录 - 讲解 - 摆放
和团队一起构建用户故事或讨论事情的时候，应用一些简单的可视化技术会很有帮助。
讨论的最常见错误就是大量的讨论被蒸发掉了。
刻画用户画像
逻列不同用户，讨论他们能从中得到什么好处，使用动机，假设他们的使用方式，他们需要哪些功能。
在这么多用户和用户需求中，如果我们只能选择其中一个用户，你会选择哪个。
探索细节和可选项
在宽度上完成故事地图之后，就该开始进行细化了。每一列顶层卡片都是在故事，拆分的细节放在对应的下方。在每个大故事上停一下，然后提出以下问题：
- 用户在这一步具体要做什么事情？
- 用户在这一步还有其他选择码？
- 如何做才能使用户觉得更炫酷？
- 出现问题时如何处理？
用户故事地图通过良好的沟通并以地图的形式来组织沟通的内容。从左到右是人们讲述大故事的步骤，从上到下逐步的细化。最关键的部分是产品构思框架。
在排优先级的时候，我不会使用“必须做”、“应该做”、“可能做”这种MoSCoM的方式，只区分做和不做。优先级划分的原则非常简单，“没有它就无法工作”就做，其他的都先不做。
第二章 计划，为了更少的开发
想要开发的功能，总是超出你能投入开发的资源。
故事地图帮助大型组织建立共识
地图要涵盖贯穿多个用户和系统的叙事主线
从左到右是整个地图的主干，讲述的是所有用户角色和他们创建和管理站点内容的完整故事。
需求范围没有蔓延，而是我们对需求的理解更深刻了
在传统软件开发理念中，估算开发时间 并对发布日期做出承诺后发现的新功能，称为“需求范围蔓延”。作者认为范围没蔓延，只是对需求理解更深刻了。当然，团队在构建用户故事地图过程中，可以提前发现哪些地方有遗漏。
划分MVP发布计划和路线
聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向。
聚焦于特定的目标成果，这是排定开发工作优先级的秘密。
成果背后是参与特定活动的特定用户之特定行为的改变。
这是个魔法：以视觉化方式将想法做成一幅很大的地图使计划的步骤进一步简单化，他使得一大帮人可以协同完成产品交付。
最小可行产品(
MVP)是指可以产生预期成果的最小产品发布。
在用户故事和用户故事地图使用过程中，两点最重要：
- 最大胆、风险假设最大的假设是什么？哪些是最不确定的？
- 为了消除假设或风险，需要哪些真实信息？
最小可行产品是为验证假设而做的最小规模的实验。
第三章 计划 为了更快的学习
每一次发布都当成一次实验，关注于自己要学习的东西
使用故事地图来划分出可行产品更小的发布，用它来支撑最小可行性产品实践，以迭代的方式发现什么才是真正的可行。
错误的做事方式 (???)
对于这一小节，本人有更多的思考与想法，试想：如果我们接了一个客户，对方明确这三个月要做的需求内容且在3个月后正式交付上线。那么，我们采用第一种拆分的方式完全可行，根本没必要选第二种实验学习。
选择对最终版进行拆分，然后逐块进行开发，经过几月有了最终发布产品。但这是一种错误的做事方式 。简单的一幅图形象说明，如图下，在最后一次发布之前，每次发布都是一个不可用的。
如果采用下图这种计划发布方式，每次发布后得到一个试用版产品。
基于验证的学习
从理解假设出发并验证它们，从客户和用户面对的问题，至形成对应的解决方案。所做的每一步和开发的每一功能都 有一个明确的目标，就是学习。（学习我们是否在开发正确的产品）
第四章 计划， 为了按时发布
最佳估算秘密：最靠谱的估算，来自于真正理解自己在估算什么的工程师。
成功估算秘密：达成一致理解，是成功估算最大的秘密
制定可逐步达成的开发计划
用户地图切分成三部分：
第一部分是跑通整个流程，在每部分功能开发完成之后，可以看到一个端对端可用的软件。在这个过程中削除技术风险，否则会给后续的工作带来诸多麻烦。称“功能上可用的骨架”。
第二部分，团队进一步对产品进行完善，使其接近于可发布的标准。
第三部分，进一步打磨产品特性，使其接近于完美。
第5章如何创建故事地图
故事地图六步法
1、厘 清问题，用户是谁，带来什么价值。
2、构建全景图，广度优先。
3、探索，向深度拓展，讨论其它类用户，这些人又要做什么，哪些环节会出问题。使用画像、原型和实验不断优化解决思络，尽量改变和完善故事地图。
4、制定发布策略。请记住一点：聚焦于业务目标的达成和目标用户。果断砍掉无助于取悦用户和帮助公司达成目标最小方案的东西。
5、制定学习策略。请记住，实际验证之前都是假设。故事地图和讨论可以帮助我们发再用哪些最大的风险。
6、制定开发策略。在去掉所有不必要的东西之后，留下的就需要投入开发。根据实现的先后顺序，将最小的可行方案进一步切分。早期先聚焦于关键技术问题和开发风险。
第6章 用户故事的故事
同样一份文档，阅读的人不同，各自得到的信息也不一样。
最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作。
用户故事最初是Kent Beck的创意，他的想法是停止写出完美文档的“执念”，大家坐一起，讲一讲用户故事。
如果团队没有聚在一起对用户故事进行充分讨论，就说明你们运用用户故事的方式不对。
在Ron Jeffries的《极限编程实施》一书中对3C原则的描述非常棒。
Ron Jeffries的3C原则
卡片（Card) ：在一堆的卡片上写上你期望的软件特性
交谈（Conversation）：聚在一起对要开发的软件进行深入讨论
确认（Confirmation）：对完工的条件进行确认。
第七章 如何把故事讲好
模板
作为【一个用户】 Who
我想要【某个产品特性】What
这样我就可以【获得某种收益】Why
模板格式并不是用户故事的唯一要素
提升讨论效果的检查单
- 讨论用户角色
- 讨论要做的功能
- 讨论为什么做
- 讨论软件之外的东西
- 讨论异常情况
- 讨论问题和假设
- 讨论更好的解决方案
- 讨论方案如何实现
- 讨论开发周期
后续章节没什么精华直接跳过。