这段时间换了新的pair，在和pair做story的过程中。我们提出了“Story Review”这样一个事情。我们两个人都从中收获颇多，就简单写篇博客记录一下，以后说不定还会有更新。
所谓的Story Review其实就是在做完一个Story以后，对做Story的收获和不足的梳理总结，应该包括但也不限于如下：
1. 完成Story的过程是否能够改进？
解决有没有走弯路？下次能不能避免这样的弯路？
是不是漏掉了一些环节？没有和BA充分确认需求？下次应该要注意首先和BA确认需求
是不是被QA测出了bug？是因为什么原因产生了这个bug？没有考虑到一些边界条件？没有考虑到特殊情况？能不能总结出来下次避免？
2. 具体-抽象-具体
我们解决当前Story对应的问题，能不能上升到一个抽象的层次？能不能成为一类问题的共性解决方案？
如：fix一个bug。如果仅仅是fix一个bug，那你完成的事情就只是fix一个bug。但是如果我们抽象的来看这个问题，它应该是我们解决fix所有bug这种“抽象”的一个具体解决方案，并且不一定是最优的。通过抽象，能够提高这一类问题的效率。
又如：我们解决了一Transaction之于Hibernate的问题，解决这个问题本身是一个非常具体的事情。解决掉它而不加总结，那你只是具备了当前Transaction之于Hibernate的问题。但是如果把这个问题抽象的来看，它应该是Transaction Design的问题。通过这个方式思考，会很容易的找到被反复验证的解决方案。
3. 杂项
杂项相对来说就是没有太多的规律性的总结。
某个IDE快捷键的使用是否熟悉？
重构或者在解决一个问题时，tasking是不是做的足够好？是不是能够保证focus在当前的task上？
简而言之，做任何事情都应该不断的总结，这样思考问题的能力才能提升。Story Review真的还是挺不错的总结反思的方式。