在胡凱近期組織的新任PM/TL經(jīng)驗(yàn)交流會(huì)上，提到了什么是合適的leverage模型。碰巧Mike Gualtieri近一篇文章中提到了沒(méi)有QA的團(tuán)隊(duì)，讓我覺(jué)得，沒(méi)有QA的團(tuán)隊(duì)，不但靠譜，而且沒(méi)準(zhǔn)會(huì)有奇效。
　　沒(méi)有QA，缺少了后的保障，軟件質(zhì)量是否會(huì)一降千里？不會(huì)的。沒(méi)有單獨(dú)的QA，并不意味著沒(méi)有人去做測(cè)試和質(zhì)量保證，而是讓每一名dev承擔(dān)測(cè)試的責(zé)任。很多人的經(jīng)驗(yàn)表明，開(kāi)發(fā)過(guò)程很常見(jiàn)的一個(gè)問(wèn)題是，Dev匆匆忙忙做完story，認(rèn)為任務(wù)已經(jīng)完成，剩下都是QA的事情，即使出了問(wèn)題，也是QA測(cè)試不周。在心理學(xué)上，這是一種典型的心理依賴(lài)。由于認(rèn)為自己只承擔(dān)開(kāi)發(fā)責(zé)任，Dev會(huì)用很大的精力追求開(kāi)發(fā)速度，這是導(dǎo)致缺陷過(guò)多、質(zhì)量下降的主要原因。在沒(méi)有QA的團(tuán)隊(duì)，Dev要對(duì)質(zhì)量負(fù)責(zé)，這種責(zé)任的轉(zhuǎn)移，讓Dev去掉了僥幸心理，從而會(huì)重視每一個(gè)Story的質(zhì)量。
　　另外，敏捷軟件開(kāi)發(fā)中，常提的一個(gè)概念是“關(guān)注交付”。軟件被開(kāi)發(fā)完成，沒(méi)有任何價(jià)值，只有上線(xiàn)，并給客戶(hù)帶來(lái)價(jià)值，才算真正交付。這種說(shuō)法很多人在很多場(chǎng)合都曾提過(guò)，但是“紙上得來(lái)終覺(jué)淺”，不親身體驗(yàn)，很難體會(huì)其中含義。沒(méi)有了QA的團(tuán)隊(duì)，會(huì)創(chuàng)造這樣一個(gè)“絕知此事要躬行”的條件，讓Dev的視角不再局限于開(kāi)發(fā)，而延伸到軟件生命周期中更接近交付的地方。這樣的體驗(yàn)，會(huì)不斷沖擊Dev慣有的思維，讓他們思考并理解交付的真正含義。
　　沒(méi)有QA，很容易實(shí)現(xiàn)完全的自動(dòng)化測(cè)試。自己完成的story被別人破壞怎么辦？沒(méi)有Dev愿意每次都手工回歸測(cè)試，只能是用自動(dòng)化。而Dev編寫(xiě)自動(dòng)化測(cè)試，具有QA無(wú)可比擬的優(yōu)勢(shì)。舉個(gè)常見(jiàn)的例子，很多項(xiàng)目會(huì)采用依賴(lài)注入機(jī)制，不光可以減少代碼的耦合，同時(shí)可以提高項(xiàng)目的可測(cè)試性，非常易于編寫(xiě)單元測(cè)試。這對(duì)自動(dòng)化的功能測(cè)試同樣有效，Dev在基礎(chǔ)架構(gòu)上，在開(kāi)發(fā)中時(shí)刻都會(huì)關(guān)注可測(cè)性，從而避免很多問(wèn)題，比如我經(jīng)歷的一個(gè)案例：某Web開(kāi)發(fā)團(tuán)隊(duì)，Dev只開(kāi)發(fā)Story，QA則經(jīng)常抱怨，Web頁(yè)面非常難于編寫(xiě)自動(dòng)化測(cè)試。
　　談了一些沒(méi)有QA的好處，我覺(jué)得它的局限在于：
　　1、某些遺留系統(tǒng)中，對(duì)環(huán)境的依賴(lài)性比較強(qiáng)，很難做到完全的自動(dòng)化測(cè)試，必須依賴(lài)QA的手工測(cè)試。相反可以從新項(xiàng)目開(kāi)始嘗試，引導(dǎo)甚至強(qiáng)制團(tuán)隊(duì)編寫(xiě)易于測(cè)試的程序。
　　2、大團(tuán)隊(duì)怎么辦？敏捷中，幾十人的團(tuán)隊(duì)算作大團(tuán)隊(duì)了，而我認(rèn)為大團(tuán)隊(duì)是反敏捷的，應(yīng)該拆成十人以下的小團(tuán)隊(duì)。小團(tuán)隊(duì)更具可控性，對(duì)軟件質(zhì)量會(huì)有更高的保障。
　　如果下半年有機(jī)會(huì)開(kāi)始新項(xiàng)目，我一定要做這樣的嘗試：沒(méi)有QA的團(tuán)隊(duì)，可以交付更高質(zhì)量的軟件。