注解
这本书是一个叙述算法，用于使用敏捷技术从构思到实施进行整个开发过程。 该过程分步骤进行，并在每个步骤中指示该过程步骤的方法。 作者指出，大多数方法都不是原始的，没有声称是原始的。 但是良好的演示风格和过程的某些完整性使本书非常有用。
用户故事图的关键技术是在用户执行过程时构想和陈述。
同时，可以用不同的方式描述该过程。 您可以在达到关键价值时制定步骤，也可以只是想象用户的工作日，以及它在系统中的工作方式。 作者关注于以下事实：需要说明过程，在过程图上以用户历史记录的形式进行发音，这是用户故事图的名称。
谁需要它
适用于IT分析师和项目经理。 必读。 轻松愉快地阅读，本书中等大小。
意见反馈
以最简单的形式，它是如何工作的。
访客来咖啡馆，选菜，点菜，接受食物，吃东西，付钱。
您可以在每个阶段从系统编写我们想要的需求。
该系统应显示菜肴清单，每种菜肴的成分，重量和价格，并能够添加到购物篮中。 我们为什么对这些要求充满信心？ 需求的“标准”描述中没有对此进行描述，这会带来风险。
不了解为什么需要这样做的艺术家通常不需要什么。 与创意无关的表演者不参与结果。 敏捷说，所以让我们主要关注的不是系统，而是关注人员，消费者，他们的任务和目标。
我们造就人，出于同情心，我们会给他们细节，而在人的方面，我们开始讲故事。
办公室员工Zahar去吃午餐了，想吃点东西。 他需要什么？ 想法是他可能想吃商务午餐。 他希望系统记住的另一个想法是他的偏好，因为他正在节食。 另一个想法。 他想立即喝咖啡，因为他已经习惯于在晚餐前喝咖啡。
而且仍然存在业务（组织角色是代表某个组织利益的角色）。 该企业希望增加平均账单，增加购买频率，增加利润。 想法是，让我们提供某种美食的不寻常菜肴。 另一个想法-让我们介绍早餐。
想法可以并且应该具体化，转换和设计为用户故事。 作为Zakhar商务中心的一名员工，我希望系统能够识别我，以便我根据自己的喜好收到菜单。 作为服务员，我希望系统通知我何时接近餐桌，以便客户对快速服务感到满意。 依此类推。
数十个故事。 进一步确定优先级和积压？ Jeff指出了出现的问题：由于细节与目标的不一致，细小的细节之间的联系以及对概念的理解的缺失以及对功能的优先级划分造成了混乱的局面。
作者的路径：我们不优先考虑功能，而是优先考虑结果=用户得到的结果。
一个明显的非显而易见的观点：优先级会议不是由整个团队举行，因为它没有效果，而是由三个人组成。 第一个负责业务，第二个负责用户体验，第三个负责实施。
我们选择解决一个用户问题的最低要求（最低可行解决方案）。
我们通过在团队中告诉和讨论人员和利益相关者的需求，在用户故事的背景下，通过用户故事，轮廓设计，限制和业务规则来详细描述优先事项。 在机会积压的过程中，剩下的想法没有集合。
该过程以卡片的形式从左到右书写，并在该过程的步骤下将想法写在卡片上。 必须与团队一起讲出整个历史的道路，以便彼此了解。
以这种方式进行曝光可创建过程匹配的完整性。
您需要检查的想法。 没有团队成员戴上帽子，而是活在当下的头上，解决了他的问题。 当他没有看到发展动态，重新创建牌，并且团队发现替代方案时，可能会有变体。
然后深入进行评估。 三个人就够了。 负责用户体验，开发人员和测试人员的最喜欢的问题：“如果...会怎样？”。
在每个阶段，讨论都在用户历史记录过程的地图上进行，该地图可让您牢记用户的任务以进行理解。
根据作者，我需要文件吗？ 是的，我需要。 但请注意，让我们记住我们达成的共识。 来自外部的人的参与再次需要讨论。
作者没有深入研究文档充足性的主题，而是着重讨论。 （是的，无论不怎么了解敏捷的人，都需要文档）。 同样，仅研究部分功能可能会导致需要对整个系统进行完全更改。 作者指出，如果他们没有想到这个想法，就会有过多阐述的风险。
为了消除风险，必须快速收到有关所创建产品的反馈，以最大程度地减少对“错误”产品创建的损害。 他们绘制了一个想法的草图-由用户确认，界面原型的草图-由用户确认，等等。 （另外，还介绍了一些如何验证程序原型的方法）。 创建软件的目的（尤其是在最初的阶段）是通过快速反馈进行培训；因此，创建的第一个产品是可以证明或证明假设的轮廓。 （作者依靠Eric Rice的著作，《精益方法论的启动》）。
如果实施由多个团队提供，则故事图有助于建立沟通。 地图上应该是什么？ 您需要什么来支持对话。 不仅是用户故事（谁，什么，为什么），还包括想法，事实，界面概述等。
将历史地图上的卡片划分为几条水平线，您可以将作品划分为多个发行版-选择最小的版本，构建功能和弓箭层。
我们在流程图上讲故事。
员工来吃午饭。
他想要什么？ 服务速度。 这样他的晚餐已经在桌上或至少在托盘上等着他。 Opa-错过的步骤：员工想吃饭。 他登录系统并选择了商务午餐选项。 他看到了卡路里含量和营养价值，以维持饮食而不发胖。 他看过这道菜的照片，以决定是否要在这个地方吃饭。
接下来，他将去吃午餐和午餐吗？ 也许他会在办公室吃午餐？ 然后，该过程的步骤是选择食物的位置。 他想知道他何时被释放，以及选择在哪里花费时间和精力-下降或工作的成本。 他想看到咖啡馆很忙，以免打扰。
接下来，员工来到咖啡馆。 他想看一下自己的盘子，拿走然后立即去吃饭。 咖啡馆想收钱以赚取维修费。 员工希望在与咖啡店的定居点中浪费最少的时间，以免浪费宝贵的时间而无益。 怎么做？ 进行远程维修后，请提前付款，反之亦然。 或现在使用自助机付费。 以下哪项是最基本的？ 有多少人愿意用信用卡支付午餐？ 有多少人相信卡号的存储可以重复使用该餐厅？ 没有现场研究，不清楚是否需要测试。
在流程的每个步骤中，您至少都需要以某种方式提供功能，为此，您需要以某种人为基础，并选择对他来说更重要的人（相同的三个选举人）。 故事传到最后=做出了可行的决定。
接下来是细节。 客户希望看到咖啡馆的工作量，以免打扰到队列。 他到底想要什么？
观看天气预报，他会在15分钟内去多少人
提前半小时观看咖啡馆的平均服务时间及其动态
观看表的使用情况和动态
但是，如果预测系统给出难以理解的结果或停止工作该怎么办？
观看咖啡馆中的视频线以及餐桌的使用。 嗯，为什么不先做呢？
作者指出了一个练习的小练习：试着想象你早上醒来后在做什么。 一卡=一动作。 放大卡片（而不是研磨咖啡-喝点清凉的饮料）以删除各个细节，而不是着眼于实现方式，而是着眼于目标。
本书适合谁使用，适合IT分析师和项目经理。 必读。
应用领域
3至5人的小组讨论和决策有效。
在第一张卡上写下需要开发的内容，在第二张卡上写下-要修复在第一张卡上完成的事情，在第三张上-要修复在第一张和第二张卡上完成的事情。
编写蛋糕之类的故事-不写出制作食谱，而是找出由于什么原因与谁分享蛋糕的对象。 如果您分解实施方式，则不是在蛋糕，奶油等的制造上，而是在小成品蛋糕的制造上。
当您需要在开始拍摄之前仔细开发和舔脚本，组织场景，演员等时，软件开发类似于制作电影。
资源将永远是稀缺的。
20％的努力给出了切实的结果，60％的不确定性表明20％的努力是有害的-这就是为什么重点在于学习而不是在出现负面结果时绝望的原因。
直接与用户沟通，感觉自己的鞋子。 关注一些问题。
详细说明和制定评估历史是Scrum最沉闷的部分，使讨论在水族馆模式下站不住脚（3-4人在董事会进行讨论，如果有人想参加，他会代替某人）。