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