这周试点团队启动第二个迭代，方教练在周一指导团队开完计划会之后去另外一个项目几天，试点团队自己运作。作为观察员，从每日站会的情况看，团队运作越来越顺畅，配合越来越紧密，要点个大大的赞！大家应该庆祝自己取得的每一个进步：
站会纪律
首先站会纪律很好，到点团队成员就全部自觉的过来，会议中每个人的发言很简短，围绕目标把3个问题说清楚，不是汇报，也比较少发散讨论，会议时间比之前缩短了很多，后台团队因为每天是坐在一起的，基本上2分钟可以开完，前台2个团队的会议都在10分钟以内开完；SM的意识转变很快，主动提醒大家要主动移动自己的卡片，并且不要把自己的发言变成进展汇报；
团队承诺
因为计划会上大家对目标都给出了承诺，每张故事卡上都标出了测试用例设计完成时间、开发完成时间、故事卡完成时间这3个时间，团队成员在每一项工作完成后就用红笔在对应的时间上打勾，任务时间是否有超期是一目了然的，有风险也就立刻暴露出来了；
可视化和团队协作
第2个迭代是完全按照PO规划的用户故事来跟踪的，两个团队看板上只展示这个迭代要完成的内容，从故事拆分出事务单，关系很清楚。相比之前一个迭代跟踪所有的事务单，看板上的内容清晰简洁了很多；同时因为测试提前，开发人员会执行测试人员设计的测试用例，事务单不会再像之前一个迭代那样积压在测试人员手上，团队协作更加流畅；
DoD和自动化验收测试
项目启动时定的目标是每个故事都至少有一个自动化用例，在本周的推进例会上大家讨论觉得这个规则不是很合理，有些只是涉及到配置界面类的故事没有什么业务逻辑，添加自动化测试用例并无必要，所以对规则进行了调整：由PO确定故事是否需要自动化验收测试，并且在计划会上和团队成员明确，作为DoD的一部分。规则明确后，SM在相应故事卡上标出了红色的三角形；
及时排除阻碍
对于会议上发现的风险，在看板上增加一张红色即时贴标注出来，并不展开讨论。会议结束后SM在发现问题之后立刻组织协调解决，是立刻去找相关同事协调讨论，而不是通过QQ或者微信等方式。SM自己说那样效率太低了。
周五下午需求改进小组讨论需求如何改进，试点团队两位PO因为感受了用户故事在明确对用户的价值方面的好处，所以极力的推荐在合同类项目调研时使用用户故事的方式，但是这个转变有点大，还没有完全达成一致意见，下周方教练回来，可以再讨论一下。看见“敏捷之旅”专栏中PO永哥输出的用户故事的脑图，感觉画得很好，盗用一下。
本周的CoP活动继续，宇文输出了实例化需求的交流，我输出了一次精益思想的交流，虽然人员不多，但是大家可以针对具体问题开展讨论了，这是很好的开始，需要坚持下去，相信通过碰撞会产生好的点子和想法，有益于工作，有益于个人。
团队协作运作顺畅了，后面要在代码重构、自动化单元测试、持续集成等工程实践方面加大投入，带动工程技术能力和效率的提升。
敏捷是做出来的，不是说出来的，不断尝试，持续改进，我们会越来越好的。
我是有底线的
