软件流程设计之事件风暴EventStorming

最近新开了一个公众号，有兴趣可以关注一下。时不时就复活去更新一下。

最近在带几个新员工，新员工是学校刚毕业的，习惯于做一些导师或者师兄师姐们拆解好的任务，有很明确的功能描述，甚至喂饭喂到什么地步呢，输入输出，需求文档，参数类型都规定好了，他只要把逻辑实现一下就行。
但是问题来了，职场不是学校，喂饭喂到这种程度才能做的话，不如我自己写写算了。带人很累，但是我秉着授人以鱼不如授人以渔的想法，想要让他们学会怎么做程序设计。
今天给大家介绍一个能够让软件设计快速入门的方法论，事件风暴。

事件风暴的官方定义：

EventStorming is a flexible workshop format for collaborative exploration of complex business domains.事件风暴是一个处理复杂业务灵活小作坊。

目标：

发掘现有的健康业务线中最有改进价值的地方；
探索新业务模式的可行性；
设想新的服务，为每个参与方带来最好的正向结果；
设计整洁可维护的事件驱动型（Event-Driven）软件，以支持快速发展的业务。

事件风暴中的基本元素：

事件风暴中的基本元素很多，今天先介绍相对独立的系统（即不跟第三方系统交互），在设计流程的时候用到事件风暴中的几个必要元素。

1.事件 Event

指的是可以拆分到最小单元的业务动作。举个例子，“点击按钮”不算一个事件，因为没有任何业务属性，但是“查看账户余额”就可以认为是一个事件。

2.决策行为 Command

指的是导致事件发生的动作。顺着刚刚的例子说，“点击按钮”就是一个决策行为，导致了客户可以“查看账户余额”。

3.角色 User/Actor

指的是发起决策动作的一个参与者，就是对象。再顺着刚刚的例子，谁可以查看余额，很显然就是用户本人。值得注意的是，这里的Actor并不仅仅指生物学上的人类，它的范围涵盖了计算机领域的所有对象，一般包括，用户、信息系统、操作系统等。

了解了以上的几个必要元素之后，我们就有了一个基本的模型，那就是

User Command Event 谁-怎么做-做什么。
在这里插入图片描述
那么流程设计就是基于谁做什么导致什么结果，然后这个结果再驱动下一个人做什么的过程。

使用要点：

1.识别事件

案例：在双十一活动期间，某商家决定对在店内购买商品的客户都免费包邮赠送一本《C++程序设计》。
正常情况下的事件分解应该是。

客户下单，订单完成。
商家赠送书籍《C++程序设计》。
看起来很简单，但是怎么越想越不对，如果客户退货了怎么办呢？这本书也照送吗？
所以中间增加了一个事件，就是订单结束。
还有一个问题，很多客户是知道了这个赠品才买的其他商品，怎么能保证客户知晓自己有一个赠送书籍呢？
所以中间又增加了一个事件，就是订单结束后，通知客户赠品已发出。
……等等等等这样的想法还有很多。
这个识别事件的过程就是“风暴”。事件风暴就是所有的程序参与者（开发、测试、产品、业务、需求）在内的人不断经过唇枪舌剑，最终确认所有事件的过程。

2.根据结果事件倒推上一个事件

继续上面的案例：

客户收到赠品是最后一个事件，它的前提是

商家寄出赠品，它的前提是

订单已完成，它的前提是

客户收到商品，它的前提是

商品已发货，它的前提是

客户已付款，它的前提是

客户已下单。
在这里插入图片描述

2.识别主流事件并标注分支的优先级

首先，刚刚那个案例还是存在缺陷的，有很多问题我们没有考虑到，比如：订单生成了，但是客户取消付款；商品库存不足；赠品库存不足；客户要求退货退款；客户没有主动结束订单；赠品寄丢了。等等。

我们将这些其他的事件都补充到刚刚的流程中：在这里插入图片描述
但是软件的交付是有时间要求的，所以我们需要对所有的事件做优先级区分，以保证开发力量能够快速迭代上线。根据我们之前的分析，很显然正常状态下的完成整个业务流程的优先级是最高的。

在这个基础上我们就可以根据不同的MVP等级，编写不同开发周期的需求分析文档。