经过半年的实践，可以总结了。
这次敏捷实践总体上说是比较成功的，完全按计划完成了任务，团队的凝聚力较强，员工进步很大，我个人也很有收获。
还是说说可以改进的地方吧：
1） 产品负责人不在团队中，会有很大的问题。
这体现在很多问题在最后评审时才提出来。我只是技术负责人和日常管理。虽然后期我也有意识的加强了和产品负责人的沟通，但一些细节还是会有问题，我也不可能什么都跟他汇报。
这种情况应该是比较普遍的，产品负责人往往是公司高层，他不可能整天泡在研发团队中。
如果再来一遍，我会要求产品负责人每周参加一次我们的会议，查看我们的进展，这样，不至于到最后评审时才提出问题。
2） 一定要找有合作意识的团队成员。
这个团队加我一共是7人，其中6人有团队合作意识，只有一个人没有。而这个人偏偏职位比较高，并且和我有私交。在研发过程中，他给我很大的困扰。能力不足，自以为是，没有质量意识，把别人当作测试员。我又拉不下面子去讲他。
如果再来一次，我会很认真的跟他沟通，如果继续这样，我会把他剔除出去。
3） 质量，质量
从头到尾，质量都不能达到我的期望。当然，我的要求也是比较高的，对于公司其它项目的质量，我们的质量肯定要远远好过他们。
在研发中，我采用了测试驱动和结对编程等手段。结对编程对质量到底有多少帮助，我到现在还不能确定。测试驱动绝对有好处，但测试数据的准备确实是个大问题，一旦需求发生变化，直接改代码往往很简单，但是要改测试就很麻烦。对于测试数据，我有一些改进的思路，但没有去实践。
最大的问题是，员工的质量意识不够。
另外，在最初的几个迭代中，我先从后台做起，最后集成，也是一个败笔，应该前后台同步，通过前台做持续集成的。
我的期望是，如果我们开发完成了，那就是完成了，可以发布了。我不想加一个专门的测试过程。经过这次实践，我做一点修正，开发完成后，还是要有一个准备发布的过程，这个过程，主要的工作是发布的内部演示。
所以，如果再来一次，我会坚持持续集成，测试驱动一定要做，但是测试数据要做一些改进，使对测试的修改不要那么痛苦。结对编程我会做一些量化工作。