软件开发团队协作中遇到的问题

一、提交测试后的代码改动导致线上BUG

1. 在迭代开发之前，应该更深入了解需求与更仔细的设计技术方案，争取在提测前一次做对。
2. 在提测后遇到需要更改的部分时，应该暴露问题，组内进行技术与影响范围评估，如果不必要，则在下次版本优化，必要则邮件提交给测试。

二、测试时间节点不明确

1. 测试须在提测前2天提供完整的测试用例。（根据两周一迭代计算）
2. 测试须要提测前4天进行测试用例评审。（根据两周一迭代计算）

三、UI评审不及时

1. UI须在提测前2天开始评审并在提测前完成评审。

四、提测成果不完整

1. 开发在获取测试用例后的2天，进行高优先级测试用例自测和功能模块互测，并将测试缺陷与UI评审缺陷全部修复。
2. 开发在提测当天或前一天，在测试面前进行功能演示。

五、BUG修复不及时

1. 测试须备注BUG的优先级。
2. 无特殊情况，开发须每日根据优先级顺序清空名下BUG，避免阻碍第二天测试工作。

六、沟通不足导致需求缺失、无人认领

1. 开发、产品、UI之间的协作须拒绝口头协议，以邮件或wiki的方式抄送存档。
2. 测试无须跟踪BUG进度，但是须将BUG指给正确的人，如果不知道，指给对应的开发负责人，由负责人分配。
3. BUG相关责任人（无论是直接还是间接），须对问题跟进到完全解决为止。
4. 高优先级的问题，与问题相关的所有人讨论解决（开发、测试、BA），讨论结果wiki存档。
5. 低优先级的问题，每日晚上汇总，第二天晨会统一提出，站会后拉相关责任人一次解决，提升效率。

七、需求评审不充分导致后期工作指数增加

1. 需求评审阶段的结束标志：需求问题清空、技术难题方案调研结束、UI图完整。
2. 需求评审阶段达成的共识：UI、测试、开发、BA对需求有充分的了解与有完整的文档输出，后续的更改都需同步文档。

八、文档中UI图与原型不符合问题

1. UI在设计图须完全按照原型。
2. 在需求评审结束后的一切UI改动，须以增量的方式在wiki更新。
3. 如果需要提升效率，可以在给对应的开发提供UI之后，每日晚上更新文档。

九、部分功能的测试步骤复杂

1. 开发遇到一些需要管理后台修改数据的操作，可以找相关测试寻求帮助。
2. 如果无法操作，须在代码层使用全面的模拟数据进行单元测试。