项目经过了迭代一阶段，总体来说我对team还是比较满意的，尽管也出现了不少的问题，但在这些问题暴露出来后领导们就认为我这样管理team是不正确的，我对team的过于信任导致了这次迭代一出现了目标偏差的现象，但我个人不这么认为，在团队管理上我一直坚信应该建立在对team的信任以及建立team的一致作战能力、一致荣誉感上，而不是步步对team进行制度性的防范和监控，这个我是不太认同的，尽管这样的做法通常来说确实能得到一个比较好的结果，但是我认为在那样的team中工作是不快乐的，会容易造成team的疲惫感，工作除了付出自己的辛苦得到物质收获外，我觉得最重要的还是让team得到精神上的快乐，我倡导快乐工作。
不过当然，既然暴露出问题，自然值得总结，在总结后发现现在的team确实是有些松散，还不够紧密的团结，重要的是没形成统一的荣誉感，在这样的情况下我仍然认为并不是通过制度、监控等方法去控制team，而是仍然给team一定的空间，简单的说说这次出现的问题和自己的解决思路：
1、迭代版本产生了偏离需求和UI的现象
出现这个现象我觉得最主要的原因是在提炼用户故事时做的不够好，同时在用户故事的录入上的控制
也不够好，针对这次出现的现象，我觉得在用户故事上必须表达出一个成功的业务场景的详细描述(通
过附带UI来说明)、业务规则的说明以及用户故事验证的说明。
判断一个用户故事是否完成的标准就是成功的业务场景的执行、业务规则的满足以及是否能够通过用
户故事验证。
验证工作由on-site customer做，多数情况下on-site customer就是项目经理、BA或需求分析人员。
通过频繁发布的持续集成版本将自己实现的用户故事与用户故事验证人员进行频繁的沟通和交流。
开发人员往往对细节不够重视也是造成此现象的原因，开发人员往往只注重主体功能的完成，但把细
节却给忽略了，这个在以后的迭代中需要进行纠正，培养开发人员对于用户故事完成的概念的认识。
2、开发人员在实现任务时出现了不知如何下手的现象
造成这种现象的发生我觉得最主要的仍然是CRC设计以及任务分解上出现了问题，按照CRC设计的要
求以及任务分解的要求这种现象出现的情况应该是不会发生的，尽管这次team的能力是有些欠缺，但
CRC设计加上任务分解其实会形成非常明确的详细设计以及如何实现详细设计的任务，在这点上解
决方案就是在下一次迭代会议上加强CRC设计以及任务分解这两块，CRC设计一定要能通过情景测
试，任务分解一定要分解的足够清晰，让开发人员都能明白是怎么做的，至于碰到难点的地方自然是
先安排为Spike任务。
3、开发人员在进行任务跟踪时出现偏离的现象
开发人员仍然没能形成很好的任务跟踪的习惯，这点只能不断的纠正，培养开发人员形成这样的习
惯。
4、接口依赖造成的瓶颈现象
这是此次迭代出现的一个较大的问题，未形成一个迭代中的接口依赖的全貌图，导致了在任务分配后
接口依赖常常集中在一个人的身上，出现了瓶颈现象，这点在第二个迭代中需要改进，增加整个迭代
的接口依赖图，这个可根据CRC设计提取形成。
5、任务自行挑选造成的任务完成有难度的现象
此次迭代中出现了这个现象，部分人员挑选了超过其能力很多的任务，最后导致了任务完成的过程中
出现了很多的问题，这个我仍然觉得一方面是CRC设计的问题，另一方面是缺少PP的原因。
6、持续集成失败次数过多的现象
此次迭代中造成持续集成失败的原因竟然多是测试代码编写的不正确以及测试代码对于运行数据的依
赖，这个我在项目总结会议上进行了讲解，由于这个项目压力太大，而且team能力确实有些不足，所
以我未强制执行TDD，不过仍然极度鼓励；第二个原因则是在造成了持续集成失败后未列为最高优先
级的事去做。
这次出现这些问题虽然有些是和团队个人相关，但我更多的认为这就是整个团队的责任，而不是某个人的，因此在第二个迭代中我仍然是以培养整个团队的一致荣誉感为首，并且仍然给予团队足够的空间以及充分的信任；而且在第一次迭代中出现这些问题也是好事，毕竟这是一支全新的团队，在团队能力欠缺的情况下我对于团队的表现是比较满意的，在后续我仍然的更多是依靠交流、反馈以及共同作战来弥补上面的问题，而不是依靠制度和强制性的监督。
比较可喜的是Team开始接受整个软件过程，TDD也开始得到接受，而且team成员的能力提升也是比较的明显，这其实对我而言就已经达到目标了，相信这样的一支团队是不会让我失望的。