最近新开了一个公众号，有兴趣可以关注一下。时不时就复活去更新一下。
最近在带几个新员工，新员工是学校刚毕业的，习惯于做一些导师或者师兄师姐们拆解好的任务，有很明确的功能描述，甚至喂饭喂到什么地步呢，输入输出，需求文档，参数类型都规定好了，他只要把逻辑实现一下就行。
但是问题来了，职场不是学校，喂饭喂到这种程度才能做的话，不如我自己写写算了。带人很累，但是我秉着授人以鱼不如授人以渔的想法，想要让他们学会怎么做程序设计。
今天给大家介绍一个能够让软件设计快速入门的方法论，事件风暴。
事件风暴的官方定义：
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等级，编写不同开发周期的需求分析文档。
3.识别每一个事件可能导致的不同结果
延续上述案例，主流MVP1的每一个步骤都可能导致不同的结果：
客户提交订单，订单有可能提交失败；
客户支付订单，订单有可能支付失败，客户可能超时支付，客户可能取消订单；
商家发出商品，商品可能库存不足，商品可能丢失物流；
客户收到商品，客户可能没有及时签收，商品可能存在问题，客户可能申请退款，客户可能申请退货；
客户结束订单，客户可能没有收到商品，客户可能没有结束订单，订单可能超时自动关闭；
商家发出赠品，赠品可能没有库存，赠品可能没有及时通知客户，赠品丢失物流信息；
客户收到赠品，赠品可能存在质量问题，赠品可能需要补发，赠品可能没有被及时签收……
将以上所有可能的结果都绘制到流程图中，每一个结果可能会产生新的业务流程，比如退货流程，退款流程，系统自动关闭订单流程等。不同的流程会产生新的事件风暴流程。
最终会变成一个完整的业务流程。
