今天是迭代回顾的日子，我正好也对这个迭代做一个总结。
1. 观看演示。今天上午第一次观看了演示，演示相当于客户验收吧。演示不仅仅是把自己做了哪些事情展示出来，也是对迭代计划会议中制定的“完成标准”的反馈。绝大部分人的功能都实现了，相信他们也能从演示中找到成就感。但是问题也是有的，验收就是检查所做的结果是否符合“完成标准”，而大家所做的就是演示，没有对照标准，所以也看不出来对“完成标准”的符合情况。如果以后让我演示的话，我会这样演示：把迭代计划会议时制定的标准拿出来，按照标准演示，如果完全符合，就算完成了（假设需求不变）。如果不符合，要给出不符合的理由。如果没完成，就清楚的告诉大家没有完成。
2. 下午开了迭代回顾会议。会议中让新员工发言，说一下新员工本次迭代的感受。我的发言内容为：本次迭代一直有事做，但是却觉得收获不大，原因是所完成的任务涉及的面太窄。本次迭代对项目的贡献是：解决了两个问题单，一个算法(200多行)。问题单中有一个比较难，花了较多的时间才解决。这三个小任务用了一个迭代来完成，感觉接触的业务太狭窄了。我觉得新员工可以先改比较简单的问题单，可以多改一些，这样涉及的面就回宽一些，可以了解更多的内容。至于较难的单，可以让老员工集中精力解决，简单的问题单新员工解决就好了，这不是逃避难问题单，而是新员工对业务的了解应该由浅入深，先对项目有个总体性的了解，然后再深入到某些模块。问我在阅读代码时不爽的地方在哪？我说主要有两点，1，代码没有注释；2，项目缺乏文档。自己有了这样的感受，在后续中，我要进行改进首先自己要写注释，阅读代码后，可以适当的补充一些文档，让更新的新人做个参考。
3. 晚上开了进度跟踪会议，进一步了解了我们当前面临的内存和性能问题所在的位置。高性能是一个优秀软件必须具备的基本要求。我所关注的计算慢的问题，当比较多的时候，确实太慢了，如果我是最终用户的话，我也会觉得比较慢的。所以，趁明天有时间，还是要尽快分析解决。