“你们团队QA和DEV的人员比例是多少？”
“我们团队一般有1个QA和3~4对DEV pair.”
经常会被问到这样的问题，一般的小团队都是这样的人员比例，QA也不会觉得压力有多大。当多个特性团队工作在同一个代码库、分别在开发同一个系统的不同功能的时候，虽然每个特性团队也保持前面所述的比例，对于QA的挑战却要大得多，那是因为：
- QA不仅要了解自己特性团队的需求，还需要了解其他团队的需求，因为这些功能都在同一个系统上，联系必然是很紧密的；
- 某个团队发现的软件缺陷的根源、错误日志信息，在其他团队也可能发生，这些信息需要共享；
- 某个特性团队有任何基础设施、测试环境配置文件的变化都得让所有团队知晓，而QA是其中沟通这个内容最恰当的角色；
- ......
由此可见，大规模团队的QA不像小团队那么简单，沟通的成本要高很多。如果没有及时沟通，将会造成信息不对称，要补救所花费的额外精力是比较大的。当然，大规模团队不仅QA的沟通成本增加，其他角色也一样，只是因为我是QA嘛，就跟大家聊聊我们QA是如何应对这种大规模团队的挑战的。
集体参加story的kickoff和desk check
不管哪个组有kickoff和desk check，各组的QA都一起参加，这样基本能搞清楚各个团队都在开发什么功能。只有两三个特性团队的时候，这个方法还勉强行得通。但随着团队越来越多，在高峰期的时候，QA可能一天都在这两个活动中切换，通过这种方式了解各组的需求似乎不是一种高效的方式……
集体参加各组的feature kickoff
一个release做一个feature的话，QA参加feature kickoff每个release只需要参加一次，貌似还可以的样子。但由于各组的发布周期是一样的，各组做feature kickoff的时候，QA正是忙着上一个发布周期验收测试的收尾阶段，同时也是忙着review自己所在特性团队story的时候，一般都比较忙，尤其特性团队越来越多，如果还要集中参加其他组的feature kickoff，一定会忙不开……
前面这两项我们团队都有实践过，但显然都没能很好的坚持，因为手头的确有些忙不过来，这些自然优先级就变低了。大家始终坚信信息共享的重要性，于是团队在不断摸索中找到以下两种方式。
定期catch up
定一个每周一次的例会，要求QA们合理安排手头工作，务必参加该例会。例会上每个人
给大家介绍自己组内的feature，更新状态，把遇到的困难、blocker、风险等拿出来跟大家一起讨论，讨论对策，并且对一些接下来要做的事情清晰列出来，找到专人own，下次例会的时候检查执行情况。
QA内部showcase
在每个发布周期，在QA们做一次showcase，共享组内新开发功能特性。这样不仅锻炼了QA做好showcase的能力，同时也给其他团队QA共享了业务功能信息。
这两项实践以来，大家感觉到的收益还是蛮大的，除了知识、信息共享之外，也增进了QA间的相互了解，对于大家一起合作带来很大的帮助。
当然，除了这种具体的实践，更重要的是大家都有一颗愿意分享的心。随着例会和内部showcase的开展，QA们共享信息的意识得到了加强，日常工作中遇到某种情况觉得其他团队需要知道的就会主动分享出来。
大团队带来的挑战不是那么轻松容易解决，关于如何能高效协作，我们也还在继续摸索中。
不知道您所在团队是否也面临如此挑战？是否愿意和我们大家一起分享分享呢？
