事件风暴是一项出色的技术。它提取的领域知识和完成它所花费的时间是强大的。它可以在业务层面用于识别痛点和需要改进的领域，就像价值流图一样。较低级别的事件风暴是用于设计软件的出色的沉浸式协作过程。
一年多前，我开始在红帽开放创新实验室担任咨询工程师。 在这个新角色中，我接触的第一个实践是事件风暴。虽然起初这个过程看起来很复杂，但它已成为我最喜欢与客户一起使用的做法。用这种技术打破知识孤岛和可视化业务流程所花费的时间给我留下了最深刻的印象。
作为一名顾问和开发人员，在一年多的时间里接触了许多客户，快速了解每个新客户及其独特的问题是成功的关键。事件风暴 (ES) 是我用来获得对它们如何运作的共同理解，同时还可视化其潜在问题和解决方案的技术。
我在 Red Hat 中处于一个幸运的位置，我能够与我们的几个客户一起尝试事件风暴。试验什么有效，什么无效，这让我写出了我认为的事件风暴研讨会应该是什么样子。
我对成功的 ES 研讨会的一些想法和观察：
- 为 Event Storming 的新组保留键Key/图例。试图反复解释每个部分，你会失声！
- 从一个简单的、相关的例子开始。这对于母语不是英语的人尤其重要。我倾向于使用人们熟悉的东西，比如网上商店。
- 从最初事件开始分而治之
- 在绝对必要之前不要使用Aggregate这个名字。我通常会创建一个虚拟名称，例如“combobulator”并将其放在墙上。团队倾向于在不完全了解的情况下尝试命名它。一旦您多次走过流程，您就会知道足以说出它的名字！
- 突出显示和可视化您要测试的假设，并确保将它们传递到待办事项并进行相应的测试。无需为 ES 添加新颜色，我只需用圆点贴纸突出显示以表示这是一个需要进行的实验。
- 注意控制技术人员的思路节奏，因为您很快就会陷入实施的杂草中。这可能会让非技术人员筋疲力尽，并且会因此改变更广泛群体的参与度。
- 如果您没有足够的墙壁空间，请使用一些泡沫板作为“假墙”或沿着一些连接在一起的桌子铺开造型纸。
- ES 是一个颜色拼图，但有些人可能无法区分明亮的颜色。在每个便利贴的角落和钥匙上添加一个简单的图标，以便色盲人士清楚每个便利贴代表什么
- 每个人都可以与之交互的物理建模空间和使用工具（Sharpies & Post-Its）为人们创造了一个安全的空间，让人们可以参与 ES 并挑战人们提出的想法。从事 ES 不需要购买技术技能或花哨的许可工具。我喜欢折叠取下的便利贴，然后将它们放在下面的地面上。形成的一堆代表已被纠正的误解。
- 注意将 ES 之间空间隔开，否则您将花费大量时间移动事物，为知识差距腾出空间。永远不要从角落开始！
- 在 ES 上做Pivot Events标记，然后在大组中划分并克服这些边界以加快进程。确保您停下来并检查以定期向所有组重播叙述。旋转到事件风暴的不同部分，以便在以这种方式工作时可以添加所有知识
- 当价值切片到产品待办列表时，将命令映射到用户故事。执行此操作时，压缩逻辑上属于一个功能的命令。为了可追溯性，可以将一个简单的 id 代码添加到Commands，然后导入到用于将用户故事存储在待办事项中的任何工具中。
- 作为主持人，您必须让听众保持专注。为此，请提出很多问题以梳理叙述中的空白。一定要包括可能被大声的小组成员过度支持的人。仅仅因为某人很安静并不意味着他们没有有价值的意见。我喜欢问的一些问题是“如果出现问题，它会如何表现？” 或“这总是发生还是有时发生？”。颠倒叙述也可能是有益的，“在这个事件发生之前必须发生什么？”。
我对事件风暴 (ES) 理解
我对事件风暴 (ES) 的简要描述是，它是一个建模研讨会，用于可视化业务或系统中的流程。它从组织的各个高度提供视角。对于业务运营级别，Big Picture Event Storming 可以真正识别差距和受挫的领域。突出显示存在权衡的地方，从而为您的组织提供一个专注于改进的地方。将范围缩小到流程建模和特征建模，为开发人员、设计人员、最终用户和业务利益相关者提供了一种共享语言，可以在不需要复杂技术魔法的情况下进行交流。只是一群人在交谈，讨论业务目标并在便利贴上捕捉事物。使用这种视觉技术邀请正确的人进行对话将强调以前隐藏的依赖关系。突出这些可以避免从技术和业务角度对产品做出错误的决定。
事件风暴是一种探索和发现的模式。它来自领域驱动设计 (DDD) 的世界，我喜欢将其视为精简的 DDD。DDD-Lite 但具有更多的业务重点和更少的行话复杂性。ES 研讨会聚集了整个企业的所有人员，并将技术技能要求留在门口。对与会者的唯一要求是他们的精力、注意力和尝试的意愿。在 ES 研讨会期间，每个人都手持橙色便利贴 ( Events) 以及他们随身携带的有关公司部分的知识。
软件创建是一项探索性任务，在探索的同时会发生更多的学习。抓住这一点至关重要。ES 将所有知识可视化为基于事件的思维导图，并确定其中的差距、未知数和痛点。有了 ES 的合适受众，您可以在传统上可能永远不会见面的群体之间实现和谐，更重要的是，在以前存在误解的地方保持一致。
例如，在 ES 研讨会中，您可以获得了解业务需求和要求的业务分析师，与将实现功能的开发人员一起确定命令和事件。再加上让 UX 设计师和最终用户对数据和可以支持这些数据的 UI 进行一些验证，您将获得端到端的对齐。在编写一行代码之前，您还将获得早期验证哪些可以工作，哪些不可以。
事件风暴有几种形式。大图、服务或流程设计和功能设计。这个秘籍将涵盖流程和功能级别的设计。
有关事件风暴的更全面背景，请查看开放实践库，您将在其中找到更多链接、文章和 ES 在现场与我们的客户一起使用的示例。
具体操作
我做的第一件事是设定事件风暴研讨会的目标。这可能是流程的入口点、终点或两者兼而有之。
Event只是某人关心的过去发生的事情。设置好起点后，让参加者分成 2 到 3 人一组，并确定他们在系统中能想到的所有Events内容。
我最初通常会花 15 到 20 分钟，然后在周围徘徊以确保人们正在执行任务并进行交谈，并在需要时澄清事情。如果组中有中小企业，我会确保将它们平均分成几组，而不是聚在一起。
随着团队的Events确定；要求一个志愿者小组通过将 加入Events到建模表面并开始讲述故事来向小组播放他们的声音。强制执行事件的时间线，从左到右移动。
要求其他组Events沿着时间线添加他们。鼓励与会者在表面上洗牌，以便为更多人腾出跟随Events空间。
如果团队想出不同的词来描述同一事件，请尝试就语言达成共识。
澄清未完全展开的事件。例如，如果一个组有一个非常高级别的事件，例如“订购的物品”将其分解为较低级别的详细信息，例如“物品已添加到购物篮”和“结帐已打开”等。
如果有任何问题或假设; 如果还不能回答，请标记它们。重要的是把不能自信回答的事情标记好并继续前进，否则你很快就会陷入杂草丛生。
创建事件的主干后，让团队从前到后和从后到前播放整个故事。
下一节将介绍 Event Storm 谜题中的大部分关键。现在是时候推出Actors，Commands，Read Model和Systems。为每个添加图表，使它们在视野范围内。与小组一起浏览它们并澄清是否有人有任何误解。
Command表示一个为响应从Read Model获取的信息做出的决定。Actor代表发出Command的人，System是接受Command的地方。System的责任s=是响应Command，并因此触发Event.
...
最后是识别和命名聚合Aggregate. 聚合是系统的状态机。它是接收命令并决定是否采取行动的东西。
聚合Aggregate可能是导致最混乱的部分，也是最大的时间海绵——尤其是命名它！通过拖到最后，大部分的未知数都会被清除。当流程更加充实时，我让小组重播事件风暴并确定System存在或必须构建的位置。如果一定要建，我就加Aggregate黄牌，给它起个无意义的名字，比如comobulator。通过这样做，它可以帮助人们不会陷入应该定义聚合的边界。继续重放流程，小组自然会开始识别出一些命令是发给组合器的，而另一些命令是发给其他东西的。将这些捕获为其他东西。当 ES 的完整传递完成后，返回命名它。理解的深度应该那么高，Aggregate自然而然就会现出名字和边界。
