但是，事件风暴的可能应用场景远不止领域建模，也远不止软件架构。事件是一个非常独特视角，能带来有价值的洞察。越来越多的实践者，把事件风暴活动应用在需求分析，特别是大粒度的业务流程分析中，收到了特别好的效果。我们在多个产品的业务流程分析中，都采取了事件风暴的工作方法，并且使用精益思想的价值导向和拉动的方法来增强事件风暴的实践。
我们的经验表明，这种增加了精益元素的事件风暴，在业务流程分析方面更为有序，探索能力更强，不仅仅拓展了AlbertoBrandolini的原始版本的事件风暴的适用范围，也更容易地在后续阶段向领域建模过渡。本文将介绍事件风暴应用于需求分析、特别是大粒度的业务流程分析的关键实践，并从精益方法[2]的角度，来解读事件风暴在需求分析中为什么有效的原因。
本文的介绍分为以下三个部分：
事件风暴，拆开来是“事件”+“风暴”，顾名思义，事件风暴就是关于事件的风暴——这里“风暴”指的是头脑风暴，一种激发集体智慧，产生、提出新思维、新洞见的思维方法。
理解事件风暴，就需要了解“事件”究竟是什么，以及如何进行更好的头脑风暴。让我们首先从事件的解释开始。
在本文的范围中，我们将“事件”定义为“业务事件”，也就是某个有业务意义的事情发生了。例如，在一个购物的业务场景中，“用户已经收到商品”就是一个“业务事件”。在一个交通的场景中，“乘客已经抵达目的地”也是一个“业务事件”。从上述两个例子中，我们可以看到，“某个有业务意义的事情发生了”，它一定是业务人员所关心的，某种具体化的业务结果。
为什么我们如此在意“事件”呢这是因为，事件往往代表了我们在业务中所追求的目标。如果我们在设计一个购物的业务流程，如果用户最终不能收到商品，不管出于什么原因，都不能被视为一个合理的业务流程。同样，如果我们在设计一个交通的业务流程，乘客如果没能抵达目的地，也不能被视为一个合理的业务流程。
虽然前述的两个事件都是最终结果，但是事件并不仅指最终的业务结果。任何在业务流程中“已经发生的事情”，都应当被视作是一个事件。例如，在购物场景中，除了“用户已经收到商品”，还可以有各种中间的业务结果，包括“用户已经成功下单”、“用户已经成功付款”等等，这些也都对应于业务事件。
许多人可能分不清“事件”和“动作”。我们也介绍一下两者的差异。“事件”代表某件事真实的发生了，而“动作”是一个具体的活动，也可能是事件发生的原因，但是，动作完成了，对应的事件可能发生，也可能不发生。一旦理解了这一点，二者的差异还是比较明显的。例如，“用户下单”就是一种动作。只有成功的下单，才可能触发“用户已经成功下单”事件，如果用户下单过程中有错误，就不可能触发“用户已经成功下单”的事件了。
头脑风暴是一个群体的、彼此激发的创造性活动。事件风暴也是一种头脑风暴，从而它也遵循头脑风暴在组织形式上的显著特点。注意到这些特点非常重要，因为在头脑风暴活动中，采用的形式确实是能深刻的影响到产出的内容的。
概括来说，从形式上，事件风暴在场地选择、信息呈现、与会人员和进程安排上，都有值得注意的点：
场地选择：为了能让参与者聚焦于同一个话题、进行创造性讨论的能力，一个环境开放、信息聚焦的空间具有很强的魔力。应使用类似于下面的空间：
在这类空间中，没有“需求评审”等活动中常见的会议桌，也不鼓励安放椅子，讨论起来会更加聚焦也更加轻松。
但是，如果是类似于下面的这种空间，沟通效果就会大打折扣：
信息呈现：在一个多人参加的工作坊中、如何在保持创意的同时，又不让讨论发散，是一个非常有挑战的任务。
报事贴是一种非常有效的创意工具。它兼具创意和聚焦的能力。随手撕下又可以随手抛弃的报事贴，氛围轻松，即使否定一个想法，相比于去否定一个已经准备了10天的PPT。没有那么重的心理负担。可以轻松的否定，才可以轻松的提出各种创意。
报事贴同时又是一种非常有效的聚焦工具。报事贴尺寸不大，表述的信息非常有限，所以单张报事贴表达的内容一定是聚焦的。把报事贴贴到墙上的动作，则比PPT翻页来说，快速把参与者的注意力拉到同一个话题上来。
正因为如此，在事件风暴中，所有的重要元素，例如事件、动作、执行者等，都是通过报事贴来呈现的。
虽然参与者必然应该为会议做好准备，但这绝对不意味着他们需要准备一份完善的PPT。真正的洞见应该是在讨论中产生，而PPT则具有某种若隐若现的引导性，不建议使用预先准备好的演示，例如PowerPoint（PPT）。根据经验，有PPT出现的场合，讨论更接近对PPT内容的评审，创造性思维很难充分发挥。
参与者：合适的参与者对于有效的头脑风暴特别重要。创意确实来自彼此激发，但是你不能指望想法能凭空产生。一定要邀请合适的人。需求分析过程所需的人，应该覆盖客户（如有可能参与）、业务人员、产品人员、架构人员、开发人员和测试人员。之所以需要邀请各种角色，是因为每种角色都是整个项目成功的重要参与方，而且具有不同的知识背景。有了不同的视角，事件风暴才会更有洞见。
在实施事件风暴的早期，富有经验的引导者也非常重要。引导者应该有“场”的感觉，能注意到参与讨论的群体的动态，鼓励和保证有想法的参与者能积极投入，又要保证大多数人都能参与其中。
参与事件风暴的人数其实没有约定。我曾经组织过超过60人的事件风暴，只要能组织得当，人数并不影响事件风暴的效果。当然，这么多人的情况很少发生，大多数事件风暴，参与者应当限定在一个团队或项目的范围，至多加上该团队或项目的上下游代表。10人以内的讨论，组织起来更轻松，成效也往往更显著。
组织形式：事件风暴遵循如下的结构：
关于上述结构的详细细节，我们会在第2节通过实例详细讨论。引导者应注意的是，同一个时刻，讨论应聚焦于同一个问题，例如在第一步，仅仅聚焦于发现业务事件，在第二步，仅聚焦于业务流程中的异常路径，这样的结构，能有助于结构化的讨论问题，保证问题聚焦。
在1.1节中，我们已经介绍过了事件。事件有时候也被称为“领域事件”，不过这个词汇具有浓厚的技术色彩，对一个有业务人员和用户代表参加的活动中实际效果不好。因此，我们在本文中使用“业务事件”，或简称“事件”，来指代“领域事件”。
如前所述，“业务事件”，指的是在实际发生的某个有业务意义的、实际发生的事情。
在事件风暴中，我们一般使用橙色的卡片，来指代事件。如下图所示：
有些没听说过事件风暴的参与者，可能会把“事件(event)”错误地理解成“事故（accident）”，如果存在这种情况，引导者应通过举例说明予以澄清。
某个事件如果会发生，它一定是某些动作的结果。例如，出租车已经到达终点，是出租车司机执行运送乘客这个动作的结果。
这时，我们称出租车司机为执行者，称运送乘客为动作。动作，在事件风暴的原始版本中有另外一个名字，叫做命令。命令这个词在领域建模角度是是正确的，但是，由于它对缺乏软件背景的人来说并不友好，所以在实践中，我们把命令称为动作。动作这个词，相对更容易理解一些。
在事件风暴过程中，执行者通常使用黄色的卡片表示，而动作通常使用蓝色的卡片表示。
当我们分析一个业务系统时，不可避免地需要和外部系统打交道，例如接收到外部系统的输入，或者向外部系统输出。虽然从严格定义上，执行者既可以包括人类，也可以包括其他外部系统，不过当需要明确区分时，可以显式地使用外部系统这一元素类型。
策略是某种类型的商业规则。当我们讨论业务流程时，经常会设计到某些业务规则。例如，如果我们正在开发一个打车的应用，那么乘客迟迟没有抵达，也许应该触发一个乘客已迟到事件，以避免司机不得不进行无休止的等待。乘客已迟到是一个有重要业务意义的事件，而“如果乘客超时5分钟，就判定乘客迟到”则是一条对应的业务规则。
数据信息，也就是事件风暴的读模型，往往是某些用户动作、或者某些业务策略所必须的输入。例如，在打车的应用中，“司机接单”这样的“执行者”-“命令”场景，司机显然需要出行数据作为信息输入。这个数据在原始的事件风暴中，被称为“读模型”，它是“用户发布出行信息”这个动作的结果。出于和前述相同的原因，在本文中我们称“读模型”为“数据信息”。
这些数据信息，大多数情况下都源自某个用户动作，或者某个事件产生的结果数据。
下图给出了前述的各种元素之间的关系，可以加深对于这些元素的理解
这个图的中部是主干部分，核心元素是执行者、命令和事件。执行者触发命令，命令的结果产生了具有某些实际业务意义的事件。事件可能发送给外部系统，也有可能激活某些策略，这些策略也可能出发某些命令。此外，命令的执行会产生数据，数据也会成为对执行者有意义的信息。
现在让我们通过一个具体的案例，来展示如何在业务探索中应用事件风暴。
在本案例中，我们正在准备开发一个新的产品，我们把它称为点点共乘。它的目标客户群体，是希望有打出租车出行的需要，同时又希望通过行程共享，带来费用节省、绿色出行目的的乘客。
当然，开发一个共享出行产品有非常复杂的业务场景。在本案例中，我们不准备覆盖所有的场景，仅从一个最简单的场景出发，看事件风暴如何帮助到业务的分析过程。
我们现在就以这样一个场景为例，来完成一次基于领域事件的需求业务分析过程。当然，下面的内容不是单个角色完成的，而应该是在工作坊中讨论的结果。
事件风暴的第一步，是弄清楚通过本次事件风暴，最终要满足什么样的业务目标。例如，在本例中，业务人员会进行如下的介绍：
这是我们共享出行这个产品的第一个版本。在这个版本中，我们最重要的目标是拉通共享出行的核心业务流，为后续业务奠定基础。
例如，可能有人会质疑：同起点同终点的逻辑，会大幅降低匹配的成功率，这是不是合理的？
业务人员如果已经进行过深入思考，并且确认这个场景是有效的，则可以补充一下背后的逻辑，例如：
虽然这样撮合的成功率比较低，但是我们可以在车站等人流密集的场所推广，所以还是有一定的应用场景。
但是，也不排除质疑的问题确实对目标是一个有效的挑战，那么这时参与者就应认真思考，这个目标是不是合理，是否需要进一步精化，或者对目标进行更大的调整。
就目标达成共识，几乎是所有的需求讨论的第一步。目标的共识非常重要，如果参与者对目标是什么没有共识，会在后续讨论中产生各种各样的分歧，而且参与者还不见得意识到，是什么导致了这些分歧。
相反，如果目标有了共识，在如何实现目标的业务策略上，则可能出现你预想不到的创意。
在参与者就目标达成一致之后，我们进入真正的事件风暴。
事件风暴并不需要太多的提前准备，但是引导者需要注意两个方面：
事件风暴需要一个真正适合进行头脑风暴的空间，典型的空间要求是：
参与者可能已经参与过多次的事件风暴，这时自然无需再对事件、执行者、动作等这些概念再做介绍。
如果有参与者还不了解事件风暴的玩法，引导者就比较重要。引导的最好方式是示例，避免进行过多的理论概念导入。
例如，在第一次谈到事件时，引导者可以取一张橙色的报事贴，写下一个正确的事件，做出示范，同时帮助参与者分清什么是事件，什么不是事件。
在谈到执行者和动作时，对执行者和动作进行讨论，确保参与者对这些概念都建立一致的理解。
第二步，也是最重要的一步，在工作区中放置第一个业务事件。
哪个才是第一个业务事件呢？在本文中推荐的做法是，从一个“真正的业务结果”开始。对于共享出行这一产品，参与者会提出：最重要的事件应该是“乘车人已经抵达目的地”。那么，我们就把这个事件的简洁表述“已抵达目的地”写下来。
现在，从“已上车”到“已抵达目的地”画一个箭头，表示这二者之间存在一个先后关系。
整个的事件流如下图所示：
或许，关于最源头的事件是什么，参与者也可能由不同的看法。例如，有人会认为“出行计划已发布”的前提是“用户已注册”。类似这类场景，是需要引导者和事件风暴的参与者视具体上下文做出判断的。如果确实“已注册”是一个还需要明确的场景，那就把它写下来。如果在当前产品中，“已注册”并不是一个需要深入分析的问题（例如它已经是成熟产品的一部分），那么就可以把这类前提列为整个工作坊讨论的前提条件，不做深入讨论。
写下来。如果在当前产品中，“已注册”并不是一个需要深入分析的问题（例如它已经是成熟产品的一部分），那么就可以把这类前提列为整个工作坊讨论的前提条件，不做深入讨论。
业务流程不可能一帆风顺。这一步，事件风暴的参与者，需要共同发现那些阻碍业务流程发展的因素。我们仍然从最后一个事件开始。
现在，摆在我们面前的问题是：
这时，参与者会提出各种各样的想法，例如：
同样，我们会依次审查：
通过审核上面的事件流，我们可能会发现许多预先所不曾想到的场景，例如：
最终完成的输出可能如下图所示：
在前述的步骤中，我们的视角是业务视角，并没有清晰地区分业务视角和产品功能。
现在，让我们切换到产品视角，来分析假如相应的业务事件要发生，或者识别到相应的业务事件的发生，谁应该做什么？“谁”就是“执行者”，“做什么”就是“动作”。
例如，对于“出行计划已发布”这样一个业务事件，我们可能对应到“乘车人”这个执行者和“发布出行计划”这个动作，我们使用不同颜色的卡片，把它们写下来，放置到“出行计划已发布”这样一个领域事件上。
有些业务事件，可能会对应于不同的产品逻辑。例如，对“乘车人已抵达乘车点”这样的事件，可能对应于“乘车人”点击“我已抵达乘车点”的动作，也可能对应于“系统通过GPS定位，判定乘车人已抵达乘车点”这样的业务策略。
不同的实现方式肯定各有优劣，风暴的过程，也是彼此进行讨论，获得最优设计的过程。
依次对业务事件的执行者和动作进行补充，我们可以得到一个更为完善的整体业务流程的概览：
在讨论过程中，一般会出现一个问题：对那些异常场景，或者是一些当前看起来不那么紧急的业务流程，是否要进行非常深入的讨论？
正如我们不可能一蹴而就的完成系统的全部能力，我们既没必要、也没可能用一次工作坊，就解决所有问题。对那些影响面较小、或者需要过很久才可能开始开发的功能，我们应该选择刻意的忽略，让我们在一开始聚焦于最重要的部分。
在业务流程的整体走查中，在不影响总体进展的情况下，也可以初步就系统功能的优先级进行讨论。例如，或许我们最终会选择在早期版本中，由用户自行输入我已经达到出发点选项，而在后续阶段采用GPS定位信息进行辅助。
通过事件风暴工作坊，一般都会获得如下的产出：
首先需要承认，本文确实是和原始版本的事件风暴在业务流建模的角度有较大的差异，这种差异本质上是一种重要的增强和补充，带来了更高的探索效率和更高质量的产出。“以终为始”的精益思维，是将事件风暴应用于业务场景探索，从而获得成功的最重要元素。
产品中所做的一切，都有一个简单的目标，即帮助用户达成其业务诉求，实现业务价值。而这种业务诉求或者业务价值的达成，本质的体现就是业务事件。优先把最重要的业务事件写下来，然后基于这个业务事件开始探索，就是价值导向的体现。
业务流程的前序步骤，必然是服务于后续的步骤。如果没有后续的步骤，前序步骤就没有什么意义。这是精益思想倡导的“拉动”思维的体现。至于通过哪种方式来达成后续步骤，有哪些潜在的前序步骤可以选择，则可以拓宽讨论的宽度，获得更有深入的洞见。
同样，“执行者”和“动作”和“业务事件”的关系，也符合这样的逻辑：执行者执行怎样的动作，并不是最重要，可以有多种执行者-动作的选择，来达到相同的业务事件触发，这也同样体现了结果导向的思维。
和传统的用例分析方法相比，事件风暴仍然会产出用例（本质上，粗略地可以等价为执行者+动作），只不过其核心思维聚焦于真正的业务结果——也就是事件，把执行者和动作在分析阶段定位为为了达成业务目标所必须采取的手段，这既降低了用例分析方法的能力门槛，也更符合事情原来的本质。
本文中使用了一些不同的术语来指称事件风暴中的元素。例如，我们把“领域事件”称为“事件”或“业务事件”，把“命令”称为“动作”。
这是一种现实的考量。毕竟，最早“事件风暴”被发明出来，首先是为了“领域建模”的目标。在领域建模中，“领域事件”是一个非常合理的名字，但是，当把它应用于业务场景分析时，就容易陷入“哪些事件是领域事件，哪些事件不是领域事件”的讨论。而且，对于一些客户方代表或者业务人员，“领域”这个词并不容易理解。简单的把它称为“业务事件”，并不会削弱它的表达力，还可以避免无谓的混淆。
当然，业务流程的讨论只是开发活动的起点。如果进入到架构设计阶段，把这里的业务事件进一步精化或者区分为领域事件，是完全合理的，而且也符合领域驱动设计自身关于“限界上下文”的定义——在不同的上下文中（需求分析上下文、架构设计上下文），可以使用不同的模型，只要建立好他们的映射就可以了。我们的需求分析上下文的业务事件，过渡到架构设计中的“领域事件”，就可以认为是这种方法的体现。
本文作者：张刚很多人对云效的认知是阿里云的一站式DevOps工具平台，这没错，但我们不仅仅如此。我们深知，DevOps是一组文化、工具和最佳实践的结合，仅有工具是不够的。持续打磨云效产品，让优秀的效能提升方法与云效工具更好的结合外，我们仍将持续输出阿里的研发效能和DevOps实践方法，欢迎持续锁定云效。