在胡凱近期組織的新任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的團隊,可以交付更高質量的軟件。