我觉得这样一个方式比较适合多角色。比如说有我们真正的用户，如果没有的话，用户代表。然后是比。可能还比较缺失，我们的DEV和QA也要参与进来，就是要整个对于这个模块开发的所有人都要参与，不仅仅是BA参与这第一个问题
非常正确，EventStorming 关键的一点是invite the right people, 比如 用户，BA，QA， Dev 还有PM
第二个我觉得比较适合模块刚刚开始开发，而不是很适合我们。做了一段时间去做refactor，然后比如说我们，今天我觉得我们的痛点没有解决，但是对比清楚这个模块要做什么呢，那这样的话适合一个新的模块的开发。
EventStorming的目的之一是一个单词“Clarity”， 不管是老的模块的refactor 还是新的模块的开发，都需要达到这样的目的，关于所说的痛点，有些可以通过这个工具进行针对性的讨论解决，有些是需要额外的时间解决，这个工具可能只能帮助我们把问题暴露出来（Clarity）
我可能打算在我接下来可能要进行一个大的模块的开发，我就想用一下这个EventStorming，让所有参与会的人，了解我这个模块要做什么事情，以及它要分多少个页面，多少功能。
非常好哦，这是EventStorming Big-Picture 的初心所在。
本次会议聚焦了一个小问题，所以效果我认为是达到预期的。也可以引发相应的后续行动。大家都能到达同一个page了。
是的，通过可视化的手段让大家到达同一个Page，效果就达到了。
很好的整理，分享系统的机会，缺陷就是有些耗时间啦
耗时是每次都会给出的反馈，我们可以从另外的角度看一下，我们是不是达到了目标，我们是不是用有效的工具开了一个有成效的会议，如果一次会议让大家统一了认知，花点时间可能是值得的哦。
1今天这种两个系统集成或者协作的case，解决红纸条过程中才渐渐划分两个系统各自的角色职责是否妥当？是否在eventstorming过程中应该更早讨论明确？另外比如最后可能一个多小时的tms多种登录方式梳理是不是其实不在今天会议的主题内？当然对我们来说能理清楚也是非常好的事情；
系统是大家在互相讨论的过程中每个人积极参与贡献出来的，因此慢慢演变得出结论是妥当的；最后一个多小时讨论的TMS多种登陆方式的确不在议题内，但是就像你说的，既然大家很有兴趣讨论，那讨论一下也很好的，问题总归要理清楚解决的：）
2. 类似user profile/o-chart影响domain event流程或关键问题是否应该更早获得关注？感觉上午很大部分时间都绕不开这种问题，要么更早直面，要么就干脆放一边快速推进？今天上午仅整理流程+提已知问题的一定程度上降低了下午未参会同学的体验？（但谁让他没参会哈哈！）
哈哈，关键人物 参会很重要
3.结论&计划的recap？
结论已经通过miro电子化了，计划不是EventStorming的范畴，需要按照我们自己的方式走哦，毕竟EventStorming只是一个可视化会议的工具
4.如何更好的估计/控制会议时长？第一轮的storming是否可以会前进行？尤其在不是新功能的情况下，具体event大家都很熟悉。
很好的问题，看开会的目的吧，不同会议的目的可能会采取不同的方式，关于控制会议时长，这是个很难回答的问题，个人觉得还是目标导向吧，在达到目标的情况下适当控制时间。
