EventStorming反馈

感谢Yolanda 提供的实战机会，也感谢DCS同事们的配合，历经4个小时完成了一次Event Storming，并收集到了每个人的反馈，我基于每个人的反馈做了回复，大家一起探讨，共同进步。

EventStorming反馈

很好的聚焦方式, 我想可能要预先告诉参与人士预期的成果（比如用图形展示一下：从凌乱到清晰的结果）

结果是什么是不可预知的，按照EventStorming的创始人的说法，就是每次只讲一种颜色的报事贴的使用，然后所有的人聚焦在贴Domain Event 和讨论上面。

Story不太适合这样的方式，太耗费时间，并且真正story需要的细节问题的解决并没有做到，可能还是适合一个大的项目初期的brainstorming。

有一点类似的感觉，这个Story 主要的原因是流程有些短，体现不出时间线的价值。
我们这次做的是big picture 加部分business flow，但是由于本身flow 不复杂，的确没有展现出Event Storming 梳理business Flow的真实效果。

参与度较高，但对于流程简单却逻辑复杂的系统功能设计不大符合。对于时续性较强的流程梳理效果会比较好。

非常赞同，长的流程或者很多分支很难一下子难理清楚或者需要大家一起探讨的情况下更加合适一点。

对会议参与人员参与意愿和背景知识要求较高，对小团体会议比较适合，人数太多可能会难控制进度和议题，对红色问题贴纸的讨论好像没有控制话题扩散

对于我们今天的EventStorming，需要到场的有 Project Manager，Domain Developer，Developer，BA，还有用户。
关于红色贴纸的讨论很有意思，我们针对贴纸写的东西进行讨论就是为了防止发散，但是还是发散了，值得思考。

教官可以更自信地对学员提出的问题，给予直接和有效回应

感谢你的肯定

帮助内部讨论快速抓住重点，取大放小，有的放矢。更新了我们一贯的工作思路方法，很好！

EventStorming的目的是每个参会者都需要贡献，然后大家一起讨论出来要做什么该怎么做，重要的事情需要得到大家的一致认可。

有利于统一参与者的思想，试探出需求整体范围，解决主要争端。需要系统开发中涉及到的每个角色（包括用户）参与，更适合于瀑布开发，当迭代计划紧时很难展开，因为大部分细节问题依旧没有浮出台面，也较难以表达。大的流程都有，不知道这这样的方式下，是否不需要在需求评审时向开发交代完整需求细节？或日后再开会？

EventStorming 只是一个将会议可视化的工具，主要用处是让大家达成一致的共识，它并不是万能的，它只是用一种大家都能听懂的语言去将我们的软件尽可能的可视化。

EventStorming反馈