今天和老庄一起过性能的需求方案，又一次对实例化有了更深刻的体会。
首先，问题域，是谁的？什么问题？即:
用户是谁？使用场景是什么？
要解决什么样的问题？
这个阶段，使用given…when…then的方式，用场景和例子来说话，会让人更容易理解。
搞清楚问题后，接下来需要考虑方案域的问题:
当前的功能实现是什么样的？
功能流程是什么样的？
基于以上，我们的实现方案是什么？
接着，该功能需要如何去验证？
写AC的时候，采用实例化场景的方式，一样采用given…when…then的三段式风格，用表格的形式列举出来，会直观有效。
在这一部分，在考虑场景的时候，除了正常功能场景，还需要尽可能多的考虑异常，波及，升级，效率……等场景。
基于以上三个部分，才能更加完整的实现需求的实例化，当对代码具体细节不是很清楚的时候，反而会让人从用户角度更关注业务，然后才是方案和设计，这也是我们会强调集体设计的原因，面临复杂问题和有着参差不齐的团队组成的场景下，这绝对是一个更好的方法。
原来上面的知识都在心里，但真正做起来之后，再回过头感受一下，才发现实际中还可以这样做，应该这样做。
上下班路上微信听书，讲到《失控》这本大牛级的书，里面提到最完美的生态系统是大自然生物界的生态系统，靠系统的不断进化去不断完善这个系统。反思一下，有时候团队管理何尝不是这样，更完美的自组织团队也是团队组织自己的进化和完善，太有秩序，没有混乱，没有外部的压力和刺激，亦或是完全的命令-控制型团队对很难进化成一个好的系统，要想打造这样一个组织，首先需要收起你的控制欲，让大家有更多的自组织性，当然这一切必须要建立在一定的规则和边界下，就像大自然的系统，自然有其基本的自然法则和边界的限制，路漫漫其修远兮，吾将上下而求索。
图片发自简书App
