從QA到EP

　　注：作者：高磊，豌豆實驗室技術總監。本文發表于《程序員》雜志 2013 年 8 月刊。

　　兩三年以前，和友人談到 QA(軟件質量保證) 這個行業，還有 QA 這個團隊的未來，就有了一絲憂慮。而現在，終于有機會實踐一下自己之前的想法，在這里分享給大家。

　　從我有限的從業經驗到現在，經歷了很多次軟件開發模式的變化，這些變化，或因為跟風，或因為有切實的問題要解決，總之始終處于各種不同的嘗試的路上。QA 團隊從最早的強調流程，到后來強調開發技術，搞自動化測試，再后來又開始做敏捷和持續集成，這條發展的路上，對自己的要求不斷變高的同時，也伴隨著一個組織和團隊發展的魔咒。

　　組織發展魔咒

　　這個發展的魔咒更像是一個循環，可能開始于任何一個環節。

　　例如，公司負責技術的高層，沒來由的認為，測試和質量保證并不重要。這個判斷會慢慢滲透到技術團隊的各個角落，導致測試工程師，乃至測試團隊的其他角色，例如SQA，未來發展的空間會被壓縮，而壓縮發展空間的結果就是留不住人、招不到人。一方面相關工作的經驗技能要求越來越高，一方面可見的天花板又擺在那里。于是整個 QA 團隊都成了別人眼中的 「低技術」團隊，不論真的低技術還是別人以為的低技術，這種印象都很要命，為了擺脫這種印象，大家需要做點東西來證明自己，于是各種自動化測試框架、平臺、系統，紛紛出現，殊不知此時，QA 團隊和整個公司的價值已經慢慢的不一致了，自己關起門跟自己玩，成了普遍現象之后，在公司高層看來，他會覺得自己的 「QA 團隊并不重要」的判斷被證明了，因為沒有任何明確的證據表明，QA 團隊與公司愿景和計劃之間的直接聯系。

　　可怕么?在很多軟件研發組織中，這是現實存在的循環。

　　說起來我們的實踐，確實打破了這個循環，說起來好笑，我們解救 QA 團隊的方式，就是徹底取消這個團隊。但是反過來講，只有殺死「QA 團隊」，才能真正的解放「QA 工程師們」，真正解放整個軟件研發過程。

　　一些基本的價值觀

　　這個事情，就要從一些最基本的價值觀說起。

　　比如，人總要對自己做的事負責。當然做了漂亮的事情，誰都希望頭上有光環，但是做了丑事，也要能忍受得了羞辱。之為 「吃自己的狗食」，而老式的軟件開發分段流程，等于鼓勵上游做的錯事，下游來擦屁股，于是上游頤指氣使，下游低三下四，這種頤指氣使和低三下四還能傳導，于是的于是，最下游的一個環節，就是公認的受氣包了。暫不說效率和質量，從最基本的做事方法的角度，似乎也有些欠妥。我們這一條怎么落地呢，就是改組研發團隊，建立 Owner 制度。一個項目的 Owner，就像一個項目的 CEO，大事小情都要關注，從產品到開發，從測試到運維，總之一個項目的成敗，都需要 Owner 來操心，項目外的人，都是他的資源。相應的，項目也變得和平臺無關，而與特性有關，每個項目組都會涉及到幾個平臺的設計、開發工作。

　　還比如，給質量一個明確的標準。做質量工作或者測試的人，都會有強迫癥，總覺得哪里不對勁，還得狠狠的回歸一遍，又一遍?？善鋵嵈蠹叶贾蕾|量是沒有個確定的標準說好還是壞的，那怎么確定質量呢?我們稱作 「質量體現在造成實際的影響上」，也就是說，一個嚴重的問題，如果沒造成影響，或很輕微，那就不嚴重。而一個輕微問題，如果影響面很廣，例如有 1000 萬用戶都看見了，那就不輕微。

　　又比如，交付一個完美產品還是建立一個快速召回的機制?我們確實真的想每時每刻都能交付一個完美無暇的產品，但那不可能。特別是在互聯網行業，跟傳統的電信、醫療、航空航天的產品迭代有天壤之別，一個完美產品用一年做出來，市場可能早就變了天了。但不完美就有質量風險和代價，為了平衡這一點，我們必須建立一個快速召回缺陷產品的機制，甚至能讓用戶在發現缺陷之前，就用上了新版本。

　　有了這幾條價值觀，我們就大概知道開發過程改進的方向，以及做事情的原則了。那我們做了什么呢?我們組建了 EP 團隊。

　　EP 是什么

　　說到這里，EP 這個詞才第一次出現，這個詞的內涵之豐富，可能需要仔細說說。

　　我最早看到 EP 這個詞，是在當時還是 Google EP 團隊成員的 James Wittaker 寫的那一個有名的 「How Google Test」的系列博客中，內容我就不轉述了，很多人都讀過。

　　EP 是 Engineering Productivity 的縮寫，工程生產力的意思，這個團隊，就是給整個大技術團隊，甚至整個公司提高工作效率的。通俗直白的說，就是一個工具團隊。因為工欲善其事、必先利其器，不要小看工具團隊，某些程度上來講，一個產品隨著市場的變化可能很快凋亡，而一個好的工程工具，生命力要強得多，比如，開發語言其實就是最基本的工程工具了。那么，對一個公司，或者說交付團隊來講，怎么衡量工程生產力的高低呢?這個衡量方式其實就決定了「EP團隊」的工作方向。我們自己定義的工程生產力從低到高的定義是這樣的：1)質量，這是最基礎的指標，什么都不行，也要保證質量過關，否則一個產品連生存的可能都沒有。2)同等質量水平下，追求速度。質量過關了，就要看迭代速度了，你比競爭對手快，你就能活下來。3)同等質量和速度下，工程師的幸福感。如果質量也過關了，速度也快，但是大家過得很苦，天天加班，重復勞動，看不到未來，這也不行。幸福是什么?對我們來說，就是不被反復的簡單問題所困擾，該自動的都自動，自動不是說一定快，但是一定省心，這里的幸福就是省心，有精力去關注更多的有意義的事情，而不是每天處理簡單重復的問題。4)同等質量和速度，也有幸福感，再看成長。工程師們有沒有感受到成長?不斷的解決問題或開發產品，感受到的是重復勞動還是成長?其實前三點都做到了，第四點一定是有的。

　　EP 做什么

　　我們回頭說 EP 團隊，EP 團隊也有自己的人生理想，那就是一個三部曲：替、教、獨立。

　　第一個是替的階段，其實就是比較老式的開發過程，我替你測試、替你上線、替你運維。

　　這個階段，完全不符合我們「吃狗食」那一條價值觀，按照狗食法則，一個人自己設計開發編碼，當然要自己測試，自己寫的代碼 bug 多要一遍遍回歸，這個苦果自己不吃誰來吃?但沒辦法，大多數程序員在如何測試自己的程序方面沒有受過什么訓練，為了盡快發布產品，只能替，但這個替的時間要越短越好，盡快進入下一個階段，教。

原文轉自：http://www.wangyuxiong.com/archives/52072