17、分布式团队协作：从挑战到高效协同

分布式团队协作：从挑战到高效协同

1. 缺陷处理与非功能问题关注

1.1 故事卡缺陷处理

当测试中发现错误时，对于故事卡的处理存在不同观点。很多人反对将故事卡退回开发栏，但如果编写新卡来追踪问题，故事卡会保持原位直到新的缺陷卡修复。对于故事卡“完成”后发现的问题，需记录新的缺陷卡并放入任务列表，这些缺陷可能由客户提出或在测试其他功能时发现，要与所有故事卡一起评估优先级。借助缺陷跟踪系统（如 JIRA），可平衡分布式团队的生产力，统一评估缺陷优先级，确保高优先级缺陷尽快修复。

1.2 非功能问题关注时机

软件响应性能和可用性是软件交付的重要指标，直接影响用户体验。在任务规划时，难以全面考虑非功能问题，后期出现问题时只能被动研究。例如，在项目发布前一天发现性能下降问题，需综合考虑新功能对客户的价值、用户实际使用中遇到性能问题的频率和受影响人数等方面，来决定是提升性能后延迟上线还是立即上线。很多团队在早期开发过程中不重视性能指标，建议在适当时间将性能测试添加到持续集成管道中。

1.3 生产环境缺陷定义

对于新引入的生产环境缺陷，必须尽快修复；对于长期存在的缺陷，需评估是否需要修复，这类缺陷通常优先级较低，因为用户未抱怨，可能很少使用或不影响正常业务。

1.4 共享测试环境的测试规则

若各团队共享一个测试环境，需提前商定操作规则，减少相互影响和冲突，避免因其他测试人员更改测试数据导致测试结果错误。应尽早在实际环境中进行测试，测试环境越接近生产环境越好，避免在验收测试临近上线时才发现严重性能问题。除客户外，产品的最终用户也可能参与验收测试，离岸团队可协助他们准备测试脚本，帮助