如何一步一步從 QA 到 EP
兩三年以前,和友人談到 QA(軟件質(zhì)量保證) 這個(gè)行業(yè),還有 QA 這個(gè)團(tuán)隊(duì)的未來,就有了一絲憂慮。而現(xiàn)在,終于有機(jī)會(huì)實(shí)踐一下自己之前的想法,在這里分享給大家。
從我有限的從業(yè)經(jīng)驗(yàn)到現(xiàn)在,經(jīng)歷了很多次軟件開發(fā)模式的變化,這些變化,或因?yàn)楦L(fēng),或因?yàn)橛星袑?shí)的問題要解決,總之始終處于各種不同的嘗試的路上。QA 團(tuán)隊(duì)從最早的強(qiáng)調(diào)流程,到后來強(qiáng)調(diào)開發(fā)技術(shù),搞自動(dòng)化測(cè)試,再后來又開始做敏捷和持續(xù)集成,這條發(fā)展的路上,對(duì)自己的要求不斷變高的同時(shí),也伴隨著一個(gè)組織和團(tuán)隊(duì)發(fā)展的魔咒。
組織發(fā)展魔咒
這個(gè)發(fā)展的魔咒更像是一個(gè)循環(huán),可能開始于任何一個(gè)環(huán)節(jié)。
例如,公司負(fù)責(zé)技術(shù)的高層,沒來由的認(rèn)為,測(cè)試和質(zhì)量保證并不重要。這個(gè)判斷會(huì)慢慢滲透到技術(shù)團(tuán)隊(duì)的各個(gè)角落,導(dǎo)致測(cè)試工程師,乃至測(cè)試團(tuán)隊(duì)的其他角色,例如SQA,未來發(fā)展的空間會(huì)被壓縮,而壓縮發(fā)展空間的結(jié)果就是留不住人、招不到人。一方面相關(guān)工作的經(jīng)驗(yàn)技能要求越來越高,一方面可見的天花板又?jǐn)[在那里。于是整個(gè) QA 團(tuán)隊(duì)都成了別人眼中的 「低技術(shù)」團(tuán)隊(duì),不論真的低技術(shù)還是別人以為的低技術(shù),這種印象都很要命,為了擺脫這種印象,大家需要做點(diǎn)東西來證明自己,于是各種自動(dòng)化測(cè)試框架、平臺(tái)、系統(tǒng),紛紛出現(xiàn),殊不知此時(shí),QA 團(tuán)隊(duì)和整個(gè)公司的價(jià)值已經(jīng)慢慢的不一致了,自己關(guān)起門跟自己玩,成了普遍現(xiàn)象之后,在公司高層看來,他會(huì)覺得自己的 「QA 團(tuán)隊(duì)并不重要」的判斷被證明了,因?yàn)闆]有任何明確的證據(jù)表明,QA 團(tuán)隊(duì)與公司愿景和計(jì)劃之間的直接聯(lián)系。
可怕么?在很多軟件研發(fā)組織中,這是現(xiàn)實(shí)存在的循環(huán)。
說起來我們的實(shí)踐,確實(shí)打破了這個(gè)循環(huán),說起來好笑,我們解救 QA 團(tuán)隊(duì)的方式,就是徹底取消這個(gè)團(tuán)隊(duì)。但是反過來講,只有殺死「QA 團(tuán)隊(duì)」,才能真正的解放「QA 工程師們」,真正解放整個(gè)軟件研發(fā)過程。
一些基本的價(jià)值觀
這個(gè)事情,就要從一些最基本的價(jià)值觀說起。
比如,人總要對(duì)自己做的事負(fù)責(zé)。當(dāng)然做了漂亮的事情,誰都希望頭上有光環(huán),但是做了丑事,也要能忍受得了羞辱。之為 「吃自己的狗食」,而老式的軟件開發(fā)分段流程,等于鼓勵(lì)上游做的錯(cuò)事,下游來擦屁股,于是上游頤指氣使,下游低三下四,這種頤指氣使和低三下四還能傳導(dǎo),于是的于是,最下游的一個(gè)環(huán)節(jié),就是公認(rèn)的受氣包了。暫不說效率和質(zhì)量,從最基本的做事方法的角度,似乎也有些欠妥。我們這一條怎么落地呢,就是改組研發(fā)團(tuán)隊(duì),建立 Owner 制度。一個(gè)項(xiàng)目的 Owner,就像一個(gè)項(xiàng)目的 CEO,大事小情都要關(guān)注,從產(chǎn)品到開發(fā),從測(cè)試到運(yùn)維,總之一個(gè)項(xiàng)目的成敗,都需要 Owner 來操心,項(xiàng)目外的人,都是他的資源。相應(yīng)的,項(xiàng)目也變得和平臺(tái)無關(guān),而與特性有關(guān),每個(gè)項(xiàng)目組都會(huì)涉及到幾個(gè)平臺(tái)的設(shè)計(jì)、開發(fā)工作。
還比如,給質(zhì)量一個(gè)明確的標(biāo)準(zhǔn)。做質(zhì)量工作或者測(cè)試的人,都會(huì)有強(qiáng)迫癥,總覺得哪里不對(duì)勁,還得狠狠的回歸一遍,又一遍。可其實(shí)大家都知道質(zhì)量是沒有個(gè)確定的標(biāo)準(zhǔn)說好還是壞的,那怎么確定質(zhì)量呢?我們稱作 「質(zhì)量體現(xiàn)在造成實(shí)際的影響上」,也就是說,一個(gè)嚴(yán)重的問題,如果沒造成影響,或很輕微,那就不嚴(yán)重。而一個(gè)輕微問題,如果影響面很廣,例如有 1000 萬用戶都看見了,那就不輕微。
又比如,交付一個(gè)完美產(chǎn)品還是建立一個(gè)快速召回的機(jī)制?我們確實(shí)真的想每時(shí)每刻都能交付一個(gè)完美無暇的產(chǎn)品,但那不可能。特別是在互聯(lián)網(wǎng)行業(yè),跟傳統(tǒng)的電信、醫(yī)療、航空航天的產(chǎn)品迭代有天壤之別,一個(gè)完美產(chǎn)品用一年做出來,市場(chǎng)可能早就變了天了。但不完美就有質(zhì)量風(fēng)險(xiǎn)和代價(jià),為了平衡這一點(diǎn),我們必須建立一個(gè)快速召回缺陷產(chǎn)品的機(jī)制,甚至能讓用戶在發(fā)現(xiàn)缺陷之前,就用上了新版本。
有了這幾條價(jià)值觀,我們就大概知道開發(fā)過程改進(jìn)的方向,以及做事情的原則了。那我們做了什么呢?我們組建了 EP 團(tuán)隊(duì)。
EP 是什么
說到這里,EP 這個(gè)詞才第一次出現(xiàn),這個(gè)詞的內(nèi)涵之豐富,可能需要仔細(xì)說說。
我最早看到 EP 這個(gè)詞,是在當(dāng)時(shí)還是 Google EP 團(tuán)隊(duì)成員的 James Wittaker 寫的那一個(gè)有名的 「How Google Test」的系列博客中,內(nèi)容我就不轉(zhuǎn)述了,很多人都讀過。
EP 是 Engineering Productivity 的縮寫,工程生產(chǎn)力的意思,這個(gè)團(tuán)隊(duì),就是給整個(gè)大技術(shù)團(tuán)隊(duì),甚至整個(gè)公司提高工作效率的。通俗直白的說,就是一個(gè)工具團(tuán)隊(duì)。因?yàn)楣び破涫隆⒈叵壤淦鳎灰】垂ぞ邎F(tuán)隊(duì),某些程度上來講,一個(gè)產(chǎn)品隨著市場(chǎng)的變化可能很快凋亡,而一個(gè)好的工程工具,生命力要強(qiáng)得多,比如,開發(fā)語言其實(shí)就是最基本的工程工具了。那么,對(duì)一個(gè)公司,或者說交付團(tuán)隊(duì)來講,怎么衡量工程生產(chǎn)力的高低呢?這個(gè)衡量方式其實(shí)就決定了「EP團(tuán)隊(duì)」的工作方向。我們自己定義的工程生產(chǎn)力從低到高的定義是這樣的:1)質(zhì)量,這是最基礎(chǔ)的指標(biāo),什么都不行,也要保證質(zhì)量過關(guān),否則一個(gè)產(chǎn)品連生存的可能都沒有。2)同等質(zhì)量水平下,追求速度。質(zhì)量過關(guān)了,就要看迭代速度了,你比競(jìng)爭(zhēng)對(duì)手快,你就能活下來。3)同等質(zhì)量和速度下,工程師的幸福感。如果質(zhì)量也過關(guān)了,速度也快,但是大家過得很苦,天天加班,重復(fù)勞動(dòng),看不到未來,這也不行。幸福是什么?對(duì)我們來說,就是不被反復(fù)的簡(jiǎn)單問題所困擾,該自動(dòng)的都自動(dòng),自動(dòng)不是說一定快,但是一定省心,這里的幸福就是省心,有精力去關(guān)注更多的有意義的事情,而不是每天處理簡(jiǎn)單重復(fù)的問題。4)同等質(zhì)量和速度,也有幸福感,再看成長(zhǎng)。工程師們有沒有感受到成長(zhǎng)?不斷的解決問題或開發(fā)產(chǎn)品,感受到的是重復(fù)勞動(dòng)還是成長(zhǎng)?其實(shí)前三點(diǎn)都做到了,第四點(diǎn)一定是有的。
EP 做什么
我們回頭說 EP 團(tuán)隊(duì),EP 團(tuán)隊(duì)也有自己的人生理想,那就是一個(gè)三部曲:替、教、獨(dú)立。
第一個(gè)是替的階段,其實(shí)就是比較老式的開發(fā)過程,我替你測(cè)試、替你上線、替你運(yùn)維。
這個(gè)階段,完全不符合我們「吃狗食」那一條價(jià)值觀,按照狗食法則,一個(gè)人自己設(shè)計(jì)開發(fā)編碼,當(dāng)然要自己測(cè)試,自己寫的代碼 bug 多要一遍遍回歸,這個(gè)苦果自己不吃誰來吃?但沒辦法,大多數(shù)程序員在如何測(cè)試自己的程序方面沒有受過什么訓(xùn)練,為了盡快發(fā)布產(chǎn)品,只能替,但這個(gè)替的時(shí)間要越短越好,盡快進(jìn)入下一個(gè)階段,教。
第二個(gè)是教,就是教技術(shù)團(tuán)隊(duì)的其他成員,如何測(cè)試自己的程序,如何構(gòu)造環(huán)境、構(gòu)造數(shù)據(jù),如何部署和運(yùn)維自己的產(chǎn)品。這里的自己做,并不是回到蠻荒時(shí)期,例如創(chuàng)業(yè)初期只有一個(gè)程序員的時(shí)候,他當(dāng)然是自己開發(fā)自己測(cè)試自己部署,但我們到了第二階段的自己做,是自己規(guī)范的做,通過我們提供的相對(duì)完善和規(guī)范的工具做。我們就處于這個(gè)階段的初期。
第三個(gè)階段是獨(dú)立,獨(dú)立是說 EP 團(tuán)隊(duì)從一個(gè)替人做事的下游團(tuán)隊(duì),到一個(gè)教人做事的教練團(tuán)隊(duì),真正進(jìn)化為一個(gè)提供技術(shù)服務(wù)的產(chǎn)品團(tuán)隊(duì)。這個(gè)產(chǎn)品團(tuán)隊(duì)的產(chǎn)品,大多數(shù)應(yīng)該是以一個(gè)標(biāo)準(zhǔn)化的、健壯的服務(wù)的形式,而不是人力資源的形式,提供給其他團(tuán)隊(duì)的。當(dāng)然這是我們的理想,能否達(dá)到或者是否切合實(shí)際,還需要時(shí)間來觀察。
EP 團(tuán)隊(duì)和整個(gè)技術(shù)團(tuán)隊(duì)的關(guān)系
從這三個(gè)階段的描述中,多多少少都提到一些 EP 團(tuán)隊(duì)和整個(gè)技術(shù)團(tuán)隊(duì)或整個(gè)公司的關(guān)系,那這個(gè)關(guān)系是什么呢?
前面提過,我們不希望是個(gè)下游替人收尾的團(tuán)隊(duì),我們也有「吃狗食」這樣的原則,所以我想到一個(gè)比喻,來說明 EP 團(tuán)隊(duì)和其他技術(shù)團(tuán)隊(duì)的關(guān)系。
我們都知道有一個(gè)行業(yè)叫做汽車制造業(yè),他們遵循一定的規(guī)范和標(biāo)準(zhǔn),還能巧妙的將創(chuàng)意和標(biāo)準(zhǔn)結(jié)合在一起,制造出一些工業(yè)奇跡,這些汽車被賣給各式各樣的人,汽車企業(yè)并不關(guān)心他們的產(chǎn)品用在什么地方,不過他們又發(fā)明了一種叫做 4S 店的東西,用來給那些工業(yè)奇跡定期維護(hù)、修理、還可以收集市場(chǎng)反饋以便改進(jìn)產(chǎn)品。
還有另一個(gè)行業(yè)叫做物流業(yè),他們的目的就是將貨物從一個(gè)地方運(yùn)到另一個(gè)地方,這種空間的轉(zhuǎn)移,就是他們?yōu)榭蛻魟?chuàng)造的價(jià)值。在這過程中,他們會(huì)利用到汽車制造業(yè)產(chǎn)出的汽車,但他們不太關(guān)心汽車本身的標(biāo)準(zhǔn)、設(shè)計(jì)細(xì)節(jié),他們只是使用,他們關(guān)心的是使用成本、維修方便。出問題,他們會(huì)找 4S 店。
這兩個(gè)行業(yè)之間的交集是汽車,汽車制造業(yè)的價(jià)值是制造出好的汽車,物流業(yè)的價(jià)值是貨物的到達(dá),汽車制造業(yè)不關(guān)心你的貨物的目的地,物流業(yè)不關(guān)心他的汽車的制造工藝。但汽車制造業(yè)會(huì)很關(guān)心你怎么用這個(gè)汽車,以及積極的幫助你保養(yǎng),而物流業(yè)也會(huì)很關(guān)心這個(gè)車費(fèi)不費(fèi)油,好不好開。
說到這里,你可能已經(jīng)看明白 EP 團(tuán)隊(duì)和其他技術(shù)團(tuán)隊(duì)的關(guān)系了:EP 團(tuán)隊(duì)就像汽車制造業(yè),提供高效、低耗的工具;產(chǎn)品技術(shù)團(tuán)隊(duì)就像物流業(yè),使用工具,快速前進(jìn),創(chuàng)造用戶價(jià)值。他們之間互相依賴,卻又彼此獨(dú)立。
EP 都有誰
了解了 EP 和周圍團(tuán)隊(duì)的關(guān)系之后,來看看我們的 EP 團(tuán)隊(duì)的角色和成員。
我們的 EP 團(tuán)隊(duì),大致分成如下幾個(gè)角色(而實(shí)際上的工作是混合的,之所以要分開成角色,主要是從招聘的角度出發(fā)):
SED,Software Engineer in DevOps。顧名思義,這個(gè)角色首先是個(gè)軟件開發(fā)工程師,其次,面向的領(lǐng)域是 DevOps,DevOps 的概念我們就不必多講了,在實(shí)際工作中,SED 工程師是個(gè)真正的多面手,他們可能今天在開發(fā)一個(gè) Linux server 的自動(dòng)化上線和回滾的工具,明天就要設(shè)計(jì)或優(yōu)化 CDN 的部署,后天又要解決一個(gè) Windows 平臺(tái)編譯加速問題,還有還有一個(gè)自動(dòng)性能 benchmark 工具等著他來開發(fā)。這個(gè)角色目前我們只有兩位,而且這個(gè)角色的工程師是最難招聘的,因?yàn)樾氯耍蛘吆苄〉墓境鰜淼娜耍苌儆惺苓^系統(tǒng)的訓(xùn)練或有比較先進(jìn)的軟件工程思想,而從大公司出來的人,已經(jīng)被大公司條塊分割的工作方式同化,一般只擅長(zhǎng)一個(gè)領(lǐng)域,而對(duì)跨界的或者不懂,或者沒興趣。所以這個(gè)崗位的工程師,都是有成熟公司工作經(jīng)驗(yàn)的 Geek 型的人。
SA,System Admin。系統(tǒng)工程師,和很多公司的運(yùn)維工程師很想像,實(shí)際上我們現(xiàn)在的狀態(tài),做的事情也和大多數(shù)公司的運(yùn)維工程師一樣,處理監(jiān)控,優(yōu)化服務(wù)部署等等,但不一樣的是我們的目標(biāo)是將絕大多數(shù)應(yīng)用層面的運(yùn)維工作交還給開發(fā)團(tuán)隊(duì),所以我們?cè)诓粩嗟膶⒈O(jiān)控系統(tǒng)改造為友好的,自助的,也不斷的將各位上線部署類的工作做成自動(dòng)的,現(xiàn)在已經(jīng)有了很多成果,我們的 SA 主要精力可以放在系統(tǒng)以及更底層的部分了。
TE,Testing Engineer。測(cè)試工程師,其實(shí)這個(gè)稱呼有點(diǎn)名不符實(shí),我們的唯一一位測(cè)試工程師,主要的工作其實(shí)是發(fā)布和迭代控制,要保證整個(gè)交付團(tuán)隊(duì)的迭代節(jié)奏,例如在代碼上拉發(fā)布分支、觸發(fā)發(fā)布事件、監(jiān)控?cái)?shù)據(jù)等等工作,這個(gè)工作要求非常精確,又很繁瑣,因此和 SED 工程師有非常多的交互,他們負(fù)責(zé)將這個(gè)過程自動(dòng)化。這里插入介紹一下我們的發(fā)布過程,可能大家會(huì)更理解為什么還有個(gè)「發(fā)布工程師」:
我們有三個(gè)發(fā)布 Channel:Beta、RC、Release,作用各有不同。例如 Beta Channel,主要用于一些新特性的提前發(fā)布,這里面可能會(huì)多少有點(diǎn)缺陷,所以一定要控制人數(shù),并且是那些喜歡嘗鮮的用戶,他們會(huì)用的比較徹底。而 Beta Channel,可能每天都有版本更新,會(huì)有一些用戶喜歡跟著 Beta 版。而這些新的特性如果用戶反饋不錯(cuò),并且沒有什么嚴(yán)重的問題,就會(huì)進(jìn)入最近一次 RC(Release Candidate),這個(gè)量就很大了,大概能占到我們每日活躍用戶的十分之一到五分之一,這里面的功能在沒有意外的話,就是正式發(fā)布的功能了,需要注意的是,不是每個(gè) Beta 都會(huì)變成 RC。而 RC 在發(fā)布幾天之后,如果一切正常,就會(huì)切換為 Release,Release Channel 一般會(huì)在一天之內(nèi),讓絕大多數(shù)活躍用戶升級(jí)完畢,這個(gè)時(shí)候,如果程序有 bug,影響就非常大了。
posted on 2014-03-28 11:06 順其自然EVO 閱讀(942) 評(píng)論(0) 編輯 收藏 所屬分類: CMMI & QA