抽象
本书讲述了使用敏捷技术执行从想法到实施的开发过程的算法。 该过程按步骤进行布置，并且在每个步骤中都指示了该过程步骤的方法。 作者指出，大多数方法都不是原创的，也没有声称是原创的。 但良好的写作风格和完整的过程使这本书非常有用。
用户故事映射的一项关键技术是随着用户在流程中的移动来构建想法和表现。
同时，可以用不同的方式描述该过程。 您可以在实现关键值时制定步骤，或者您可以简单地想象并想象用户使用系统的工作日。 作者重点关注这样一个事实：流程需要以流程图上的用户故事的形式进行概述，这就是用户故事图名称的由来。
谁需要它
适用于 IT 分析师和项目经理。 必读。 该书中等大小，读起来轻松愉快。
召回
最简单的形式就是这样工作的。
访客来到咖啡馆，选择菜肴、下订单、接收食物、用餐并付款。
我们可以在每个阶段编写我们想要从系统中获得什么的需求。
系统应显示菜肴列表，每道菜都有成分、重量和价格，并且能够添加到购物车。 为什么我们对这些要求充满信心？ 这在需求的“标准”描述中没有描述，这会产生风险。
不理解为什么这是必要的表演者通常会做错误的事情。 不参与创造想法过程的表演者也不参与结果。 敏捷说，让我们主要关注的不是系统，而是人、消费者、他们的任务和目标。
我们创建角色，为他们提供同理心的细节，并开始从角色的角度讲述故事。
办公室员工扎克哈去吃午饭了，想吃点快餐。 他需要什么？ 这个想法是他可能想要一顿商务午餐。 另一个想法是，他希望系统记住他的偏好，因为他正在节食。 另一个想法。 他希望立即给他送咖啡，因为他习惯在午餐前喝咖啡。
还有一个业务（组织角色是代表组织利益的角色）。 企业希望增加平均支票，增加购买频率，增加利润。 我们的想法是——让我们提供一些不寻常的菜肴。 另一个想法——让我们介绍一下早餐。
想法可以而且应该以用户故事的形式具体化、转化和呈现。 作为 Zakhar 商务中心的员工，我希望系统能够识别我，以便我可以收到基于我的喜好的菜单。 作为一名服务员，我希望系统能够通知我何时接近餐桌，以便客户对快速服务感到满意。 等等。
几十个故事。 接下来是优先级和待办事项？ 杰夫指出了出现的问题：陷入小细节并失去概念理解，再加上优先考虑功能会因与目标不一致而造成一幅参差不齐的画面。
作者的路径：我们优先考虑的不是功能，而是结果=用户最终得到什么。
一个明显不明显的点：优先级排序会议不是由整个团队进行的，因为它效率低下，而是由三个人进行。 第一个负责业务，第二个负责用户体验，第三个负责实施。
让我们选择解决一个用户问题的最小值（最小可行解决方案）。
我们通过告诉团队并与团队讨论人们和利益相关者在流程的每个步骤中需要什么，在用户故事地图上使用用户故事、设计草图、约束和业务规则来详细说明首要的想法。 我们将剩余的想法留在积压的机会中，未经审查。
该流程从左到右写在卡片上，流程步骤下方的卡片上写有想法。 必须与团队成员一起讨论整个故事的发展路径，以确保相互理解。
以这种方式进行的细化创造了符合流程的完整性。
收到的想法需要进行测试。 非团队成员戴上这个人的帽子，在脑海中过着这个人的一天，解决他的问题。 有可能他没有看到进展，再次创建卡片，团队为自己寻找替代方案。
然后是评估细节。 这事三个人就够了。 负责用户体验、开发人员、测试人员最喜欢的问题是：“如果……会怎样”。
在每个阶段，讨论都遵循用户历史的流程图，这允许牢记用户的任务以形成连贯的理解。
作者认为文档是否必要？ 是的，我需要它。 但作为注释可以让您记住您同意的内容。 再次让局外人参与进来，需要讨论。
作者并没有深入探讨文档充分性的话题，而是重点讨论讨论的必要性。 （是的，文档是需要的，无论那些对敏捷没有深入了解的人如何声称它）。 此外，仅详细阐述部分功能可能会导致需要对整个系统进行彻底的返工。 作者指出了当想法错误时过度阐述的风险。
为了消除风险，需要快速接收正在创建的产品的反馈，以最大程度地减少创建“错误”产品的损害。 我们绘制了这个想法的草图 - 与用户验证它，绘制了界面原型 - 与用户验证它，等等。 （另外，还有一些关于如何验证程序原型的信息）。 创建软件的目标，特别是在初始阶段，是通过接收快速反馈来学习；因此，创建的第一个产品是能够证明或反驳假设的草图。 （作者参考了 Eric Ries 的著作“Startup using Lean method”）。
当跨多个团队进行实施时，故事地图有助于改善沟通。 地图上应该有什么？ 您需要什么才能让对话继续下去。 不仅仅是用户故事（谁、什么、为什么），还有想法、事实、界面草图等等……
通过将历史地图上的卡片划分为几条水平线，您可以将工作划分为多个版本 - 突出显示最低限度的内容，一层不断增加的功能和鞠躬。
我们在流程图上讲故事。
一名员工来吃午饭。
他想要什么？ 服务速度。 这样他的午餐就已经在桌子上或者至少在托盘上等着他了。 哎呀 - 错过了一步：员工想吃东西。 他登录并选择了商务午餐选项。 他看到卡路里含量和营养成分可以帮助他节食而不增加体重。 他看了这道菜的照片来决定是否去那个地方吃。
接下来，他会去吃午餐和晚餐吗？ 或者也许午餐会送到他的办公室？ 然后该过程的步骤是选择吃饭的地方。 他想看看什么时候能送到他手上，要花多少钱，这样他就可以选择把时间和精力花在哪里——下楼还是去上班。 他想看看咖啡馆有多忙，以免排长队。
随后，这名员工来到了咖啡馆。 他想看看他的托盘，这样他就可以拿着它直接去吃晚饭。 咖啡馆想收钱，通过服务赚钱。 员工希望在与咖啡馆的结算上损失最少的时间，以免无用地浪费宝贵的时间。 怎么做？ 远程服务后提前付款或反之亦然。 或者使用自助服务终端当场付款。 这其中最重要的是什么？ 有多少人愿意用银行卡支付午餐费用？ 有多少人会相信这家食堂会存储他们的卡号以便重复付款？ 如果没有实地研究，还不清楚，需要进行测试。
在这个过程的每一步，你都需要以某种方式提供功能；为此，你需要以某个人为基础，选择对他来说更重要的东西（同样的三个选择器）。 将故事进行到底=提出了可行的解决方案。
接下来是细节处理。 客户想看看咖啡馆有多忙，以免排长队。 他到底想要什么？
看看他到的时候15分钟后会有多少人的预测
提前半小时查看咖啡馆平均服务时间及动态
查看情况和餐桌占用动态
如果预测系统给出的结果不明确或停止工作怎么办？
通过视频观看咖啡馆里的队列以及桌子的占用情况。 嗯，为什么不先这样做呢？
作者指出了一个可以练习的小练习：试着想象一下早上起床后你做了什么。 一张卡=一个行动。 放大卡片（不是磨咖啡，而是喝提神饮料）以消除个别细节，重点不在于实施方法，而在于目标。
本书的读者对象是：IT 分析师和项目经理。 必读。
应用
3 至 5 人小组的讨论和决策是有效的。
在第一张卡片上写下需要改进的内容，在第二张卡片上写下您在第一张卡片上所做的事情，在第三张卡片上写下您在第一张卡片和第二张卡片上所做的事情。
准备故事就像准备蛋糕一样——不是写出菜谱，而是找出蛋糕适合谁、适合什么场合以及有多少人。 如果我们细分销售，那么它就不是蛋糕、奶油等的生产，而是小成品蛋糕的生产。
软件开发类似于拍电影，在拍摄之前需要仔细开发和打磨剧本、组织场景、演员等。
资源永远都会短缺。
20% 的努力会产生切实的结果，60% 会产生难以理解的结果，20% 的努力是有害的 - 这就是为什么专注于学习而不是在出现负面结果时绝望的原因很重要。
直接与用户沟通，设身处地为用户着想。 重点关注一些问题。
详细和开发故事进行评估是scrum中最沉闷的部分，让讨论以水族箱模式站立起来（3-4人在董事会讨论，如果有人想参加，他就替换某人）。
来源： habr.com