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