2)记录一段时间后，形成项目组的编码规则和代码自查表，项目成员在编写代码的时候可以自查，以减少代码的低级问题和重复问题。

　　问题5：开发过程中文档很少，无法支撑测试组在前期进行测试计划编写和测试用例设计。这样开发和测试成了串行的工作模式。目前是上线的版本非及时开发的版本，也有历史的测试用例和竞争对手的产品的情况下，这个问题反馈出来的影响还不是很大。但同样希望能引起重视。

　　措施：1) 在敏捷中强调测试驱动开发来避免这个问题，希望测试组的同学在这个方面进行研究，已适应演进式的设计和开发。

　　2) 在过渡时期，测试需要跟开发同步进行测试用例的分析和设计，测试完成后，需要进行覆盖率分析。

　　3) 与测试经理进行沟通，希望测试人员能进行敏捷培训，使用敏捷开发模式的项目测试需求。

　　项目在每个Sprint回顾会议的时候，都会讨论过程的改进点，经过5个Sprint的调整后，项目组织结构变化如下：

　　改进前：1个Scrum master，1个Product owner，1个项目经理，1个主设计师，7个开发人员，2个随测试人员，随机2-4个系统测试人员。

　　改进后：

　　1个Scrum master，负责Scrum流程的引导，扫清项目的障碍。

　　1个Product owner，负责在需求获取，product backlog的编写，需求优先级排序。主设计师和2个UI作为需求的输入人员，协助PO进行需求的澄清。

　　4个开发人员，1个开发人员负责基础版本维护和公用代码提取，另外3个开发人员各负责一个版本的功能开发和需求更新。

　　2个随测人员与项目组坐到了一起，应用Robot自动化测试框架，编写测试脚本，执行每日的自动化测试。

　　原先的项目经理进行产品的发布计划的制定和跟踪与项目外的协调工作。

　　原先的系统测试人员独立于项目组存在，依据传统流程，按照版本发布计划进行系统测试和上线的部署。

　　改进后的组织结构，在近的2个Sprint中反应良好，相对改进前，更专注于各自的工作。

　　在以后的Sprint的回归会议中，将一如既往的听取团队的改进建议，如有不适合的地方，仍要继续调整。