最近总结了下在项目中采用的一些实践，以及一些需要注意和避免的细节问题
- QA完成故事测试时鼓掌等对团队正面反馈的一些实践（让团队更注重项目整体的进度并加强责任感），甚至可能包括一些团队建设的活动
- 每天的Code Review，最好QA也能参与，让整个团队都能从业务和代码层面有统一、整体的认识
- 在故事正式开始开发之前，不仅仅写好测试场景和用例，最好能写明自动化测试的场景，对于回归测试和对故事的认识都有更深入的了解
- 发布经理和迭代经理的轮替，能让更多团队成员接触敏捷开发流程上的各方面，对增强团队责任感和对流程的理解有不少帮助
- 多了解客户组织架构以及对客户的影响，分析在不同的情况下找哪个最合适的人来解决问题；同时需要多和客户沟通，加强个人的影响力，多方面加强与客户之间的关系
- 更好地了解和分析客户的业务模式及需求，不仅仅是从单个故事的角度提出我们的建议，而是从更高的层级提供分析以实现更多的业务价值
- 尝试用Ruby配合Cucumber搭建自动化测试环境，因为像使用cuke4duke配合Java这种实现方式，增加了中间插件自身的限制对于测试框架的影响；以及需要单独的测试环境和数据库
- 更频繁地和客户进行周期性的反馈（至少一个月一次），以及更频繁的团队内部的一对一的交流和反馈
- 合理的分配时间，控制同时参加活动的数量，保持精力的充沛
- 加强和客户，以及其他团队的沟通，制定更好的沟通计划（定期，有明确的接口人）
- 对于新人，尤其是QA的培训，可以分层次，采用技能矩阵的方法来制定比较详细的计划，想办法让他们保持积极性；可以建议每6个月换一下项目，加强 项目组和办公室之间的联系；对于新人的项目介绍和培训也需要系统化
- 加强团队成员的质量意识，开发帮忙测试，交换开发和测试的职责，让团队成员自己使用和测试系统；团队成员共享向客户演示的职责
- 增加测试覆盖率的可视化（手动以及自动化测试)，并进行分析
- 根据模块、功能、实际的每一天进行缺陷等测试的分析
- 在对客户演示之后进行反馈的总结，以帮助进行后续分析和开发的指导（迭代演示和故事卡演示）
- 不要急于沟通，可以沉淀一下，对问题有清晰的认识以后，避免自己情绪的干扰，再进行沟通；更多地使用电话等即时沟通的方式；多使用图片等直观的形式
- 通过不同的形式使故事卡、团队、迭代的进度更可视化
- 有急事时通知团队做好相应的处理
- 尽量避免打扰其他团队成员的工作
- 坐的位置最好能覆盖不同的结对的开发人员，加强相互之间的沟通
- 合理调节故事大小（包括技术故事），保证每天都有故事完成，增强团队的成就感