“你們團(tuán)隊QA和DEV的人員比例是多少需频？”
“我們團(tuán)隊一般有1個QA和3~4對DEV pair.”
經(jīng)常會被問到這樣的問題誊爹，一般的小團(tuán)隊都是這樣的人員比例，QA也不會覺得壓力有多大如贷。當(dāng)多個特性團(tuán)隊工作在同一個代碼庫漾根、分別在開發(fā)同一個系統(tǒng)的不同功能的時候，雖然每個特性團(tuán)隊也保持前面所述的比例腌巾，對于QA的挑戰(zhàn)卻要大得多遂填，那是因為：
- QA不僅要了解自己特性團(tuán)隊的需求，還需要了解其他團(tuán)隊的需求澈蝙，因為這些功能都在同一個系統(tǒng)上吓坚，聯(lián)系必然是很緊密的；
- 某個團(tuán)隊發(fā)現(xiàn)的軟件缺陷的根源碉克、錯誤日志信息凌唬，在其他團(tuán)隊也可能發(fā)生，這些信息需要共享漏麦；
- 某個特性團(tuán)隊有任何基礎(chǔ)設(shè)施客税、測試環(huán)境配置文件的變化都得讓所有團(tuán)隊知曉，而QA是其中溝通這個內(nèi)容最恰當(dāng)?shù)慕巧?/li>
- ......
由此可見撕贞，大規(guī)模團(tuán)隊的QA不像小團(tuán)隊那么簡單更耻，溝通的成本要高很多。如果沒有及時溝通捏膨，將會造成信息不對稱秧均，要補(bǔ)救所花費(fèi)的額外精力是比較大的。當(dāng)然号涯，大規(guī)模團(tuán)隊不僅QA的溝通成本增加目胡，其他角色也一樣，只是因為我是QA嘛链快，就跟大家聊聊我們QA是如何應(yīng)對這種大規(guī)模團(tuán)隊的挑戰(zhàn)的誉己。
集體參加story的kickoff和desk check
不管哪個組有kickoff和desk check，各組的QA都一起參加域蜗，這樣基本能搞清楚各個團(tuán)隊都在開發(fā)什么功能巨双。只有兩三個特性團(tuán)隊的時候噪猾，這個方法還勉強(qiáng)行得通。但隨著團(tuán)隊越來越多筑累，在高峰期的時候袱蜡，QA可能一天都在這兩個活動中切換，通過這種方式了解各組的需求似乎不是一種高效的方式……
集體參加各組的feature kickoff
一個release做一個feature的話慢宗，QA參加feature kickoff每個release只需要參加一次坪蚁，貌似還可以的樣子。但由于各組的發(fā)布周期是一樣的婆廊，各組做feature kickoff的時候迅细，QA正是忙著上一個發(fā)布周期驗收測試的收尾階段，同時也是忙著review自己所在特性團(tuán)隊story的時候淘邻，一般都比較忙茵典，尤其特性團(tuán)隊越來越多，如果還要集中參加其他組的feature kickoff宾舅，一定會忙不開……
前面這兩項我們團(tuán)隊都有實踐過统阿，但顯然都沒能很好的堅持，因為手頭的確有些忙不過來筹我，這些自然優(yōu)先級就變低了扶平。大家始終堅信信息共享的重要性，于是團(tuán)隊在不斷摸索中找到以下兩種方式蔬蕊。
定期catch up
定一個每周一次的例會结澄，要求QA們合理安排手頭工作，務(wù)必參加該例會岸夯。例會上每個人
給大家介紹自己組內(nèi)的feature麻献，更新狀態(tài)，把遇到的困難猜扮、blocker勉吻、風(fēng)險等拿出來跟大家一起討論，討論對策旅赢，并且對一些接下來要做的事情清晰列出來齿桃，找到專人own，下次例會的時候檢查執(zhí)行情況煮盼。
QA內(nèi)部showcase
在每個發(fā)布周期短纵，在QA們做一次showcase，共享組內(nèi)新開發(fā)功能特性僵控。這樣不僅鍛煉了QA做好showcase的能力香到，同時也給其他團(tuán)隊QA共享了業(yè)務(wù)功能信息。
這兩項實踐以來，大家感覺到的收益還是蠻大的养渴，除了知識、信息共享之外泛烙，也增進(jìn)了QA間的相互了解理卑，對于大家一起合作帶來很大的幫助。
當(dāng)然蔽氨，除了這種具體的實踐藐唠，更重要的是大家都有一顆愿意分享的心。隨著例會和內(nèi)部showcase的開展鹉究，QA們共享信息的意識得到了加強(qiáng)宇立，日常工作中遇到某種情況覺得其他團(tuán)隊需要知道的就會主動分享出來。
大團(tuán)隊帶來的挑戰(zhàn)不是那么輕松容易解決自赔，關(guān)于如何能高效協(xié)作妈嘹，我們也還在繼續(xù)摸索中。
不知道您所在團(tuán)隊是否也面臨如此挑戰(zhàn)绍妨？是否愿意和我們大家一起分享分享呢润脸？
