寫(xiě)在前面的話

打算寫(xiě)這篇(系列)文章的目的不是去為了說(shuō)明什么是Scrum，畢竟講Scrum的書(shū)和文章已經(jīng)不計(jì)其數(shù)，同時(shí)可以看看Wikipedia的說(shuō)明:SCRUM。而寫(xiě)這個(gè)文章的目的是總結(jié)我在唯品會(huì)一年多來(lái)實(shí)行Scrum開(kāi)發(fā)模式的一些回顧、總結(jié)以及后續(xù)可能需要改進(jìn)的地方的探討。

另外有時(shí)候有些人又喜歡將Scrum和DevOps等同，這個(gè)個(gè)人不是太認(rèn)可。畢竟我理解的Scrum還是產(chǎn)品開(kāi)發(fā)范疇，DevOps更多是開(kāi)發(fā)運(yùn)維一體化的概念。但是兩者也是有密切關(guān)聯(lián)的，因?yàn)閷?duì)于一個(gè)開(kāi)發(fā)理念上還是很陳舊的無(wú)法接受敏捷開(kāi)發(fā)的團(tuán)隊(duì)，DevOps的實(shí)行也順暢不到哪里去。

為什么會(huì)在唯品用Scrum

時(shí)間需要倒流到2015年7月，多輪面試后終于進(jìn)入唯品會(huì)平臺(tái)架部–基礎(chǔ)架構(gòu)部。不過(guò)每次換工作都是在上一家經(jīng)歷很長(zhǎng)的時(shí)間后，所以面試技巧都不怎么樣，總覺(jué)得懂啥說(shuō)啥，因?yàn)榫退愫鲇七M(jìn)來(lái)也做不出啥來(lái)，所以基本上面試也沒(méi)準(zhǔn)備什么?；蛟S屬于你的地方通常都要先考驗(yàn)?zāi)?，也不怕笑話，進(jìn)入唯品會(huì)我前后半年面了3次，***還是這個(gè)部門的領(lǐng)導(dǎo)有眼光要了我。雖然中間有被打擊到，但是后來(lái)想想也沒(méi)什么，本身找工作就是一個(gè)緣分的過(guò)程。這些都是插曲了。

回歸正題，進(jìn)入唯品會(huì)后，工作上的氛圍則相對(duì)寬松，因?yàn)橹耙呀?jīng)有兩個(gè)原來(lái)的同事先進(jìn)來(lái)同一個(gè)部門了，一個(gè)江湖人稱“江南白衣”，一個(gè)人稱“隔壁老王”。因?yàn)椴块T廣州的人少，所以我們?nèi)齻€(gè)就延續(xù)了原來(lái)的工作方式，照例施行Scrum模式。一開(kāi)始還擔(dān)心部門領(lǐng)導(dǎo)或公司對(duì)于工作方式有明確要求，后來(lái)才知道，其實(shí)唯品會(huì)在公司范圍沒(méi)有明確的工作方式的指引，全靠團(tuán)隊(duì)自身。另外部門領(lǐng)導(dǎo)遠(yuǎn)在美國(guó)，經(jīng)(shi)歷(mian)比我們多，抓大放小就讓我們自己管自己了。不過(guò)源于之前公司的文化熏陶，大家工作上自覺(jué)性還是很高的，也沒(méi)有什么需要特別管理的地方。不過(guò)現(xiàn)在回頭看，還好我是在平臺(tái)部門，而不是業(yè)務(wù)部門，不然施行Scru模式將會(huì)遇到巨大的困難，因?yàn)樵谄脚_(tái)部門產(chǎn)品規(guī)劃、發(fā)布等都是自主安排，而不是外部驅(qū)動(dòng)，不然由業(yè)務(wù)計(jì)劃倒推產(chǎn)品計(jì)劃將是Scrum***的敵人。當(dāng)然也有些業(yè)務(wù)的團(tuán)隊(duì)也是實(shí)行Scrum，不過(guò)他們具體的困難和痛點(diǎn)，容我深入了解后再表。

所以在廣州我們這個(gè)基礎(chǔ)架構(gòu)的團(tuán)隊(duì)就自然而然的開(kāi)始了Scrum模式開(kāi)發(fā)。也就是說(shuō)因?yàn)槿藛T的過(guò)往經(jīng)歷使我們繼續(xù)走在了Scrum的道路上。

那么對(duì)于其它的團(tuán)隊(duì)的借鑒意義呢?其實(shí)就是找對(duì)人。Scrum不是什么靈丹妙藥，一切都是通過(guò)人在實(shí)施，不同的人使用相同的方式還是會(huì)產(chǎn)生出不同的效果。當(dāng)然如果你有足夠的資源找到***的人，那么什么模式都是虛的，就像我問(wèn)阿里的有些團(tuán)隊(duì)(當(dāng)然不是每個(gè)團(tuán)隊(duì))一樣，他們其實(shí)不需要什么模式，因?yàn)閳F(tuán)隊(duì)的人的經(jīng)驗(yàn)和能力差不多，很多的Soft Skill都是很高的，對(duì)于這樣的團(tuán)隊(duì)，沒(méi)有比“放養(yǎng)”更好的開(kāi)發(fā)模式了?，F(xiàn)在至少我在的團(tuán)隊(duì)還不是，或者以后也難遇到，所以Scrum還是對(duì)我們有幫助的。不過(guò)站在我的部門領(lǐng)導(dǎo)的角度看，其實(shí)我們就是“散養(yǎng)”的模式。

團(tuán)隊(duì)的組成

既然談到人，團(tuán)隊(duì)的組成與Scrum的順利實(shí)施密不可分。從Scrum教科書(shū)上看，一個(gè)Scrum團(tuán)隊(duì)分為產(chǎn)品經(jīng)理(PO)、Scrum Master，開(kāi)發(fā)成員。但是在實(shí)施中，這個(gè)人員配置并不合適很多公司，特別是原來(lái)是比較傳統(tǒng)模式開(kāi)發(fā)過(guò)來(lái)的公司。我們結(jié)合實(shí)際，以及人員情況作出了調(diào)整。目前的角色安排是這樣：

產(chǎn)品經(jīng)理：對(duì)于我們這種比較純技術(shù)類型的產(chǎn)品的開(kāi)發(fā)，比較合適的是技術(shù)產(chǎn)品經(jīng)理。兩者的區(qū)別主要體現(xiàn)在“技術(shù)”兩個(gè)字上，因?yàn)橄嚓P(guān)的產(chǎn)品管理更多是體現(xiàn)在技術(shù)的相關(guān)性上。這里面可以講的東西足夠再講一篇文章，簡(jiǎn)單先做下闡述。

首先從產(chǎn)品的需求上，技術(shù)產(chǎn)品經(jīng)理需要在產(chǎn)品功能需求的同時(shí)兼顧關(guān)心自身產(chǎn)品的技術(shù)導(dǎo)向性和新技術(shù)的使用，并以技術(shù)解讀的方式來(lái)判定產(chǎn)品的需求。如現(xiàn)在比較熱門的容器化技術(shù)是否合適自身的產(chǎn)品，是否能解決產(chǎn)品的某些短板。我們目前也在某個(gè)產(chǎn)品中引入容器技術(shù)，歸根到底是為了解決機(jī)器資源服用降低成本的問(wèn)題。而這些對(duì)于業(yè)務(wù)型的產(chǎn)品經(jīng)理是不關(guān)心，因?yàn)樗麄兺ǔ５某霭l(fā)點(diǎn)是業(yè)務(wù)流程。

其次，在平臺(tái)部門技術(shù)產(chǎn)品經(jīng)理對(duì)接的上游是技術(shù)開(kāi)發(fā)部門，而不是業(yè)務(wù)/商務(wù)部門，需要以技術(shù)的視角來(lái)溝通和協(xié)調(diào)業(yè)務(wù)開(kāi)發(fā)上遇到的困難，并推動(dòng)相關(guān)的產(chǎn)品的實(shí)施與運(yùn)作，而不是去做商務(wù)分析如RoI等。

再次，對(duì)于開(kāi)發(fā)過(guò)程中出現(xiàn)的問(wèn)題或者團(tuán)隊(duì)中有爭(zhēng)論的點(diǎn)，需要以技術(shù)的視野來(lái)判定對(duì)產(chǎn)品的影響，從而決定事情的優(yōu)先級(jí)，從而推動(dòng)產(chǎn)品的進(jìn)展

***技術(shù)產(chǎn)品經(jīng)理，更多是整體協(xié)調(diào)產(chǎn)品，讓大家更順暢的干活，從而符合產(chǎn)品的路線圖規(guī)劃。當(dāng)然如果能講業(yè)務(wù)的產(chǎn)品經(jīng)理和技術(shù)產(chǎn)品經(jīng)理融合到一個(gè)人是***的?？上н@個(gè)很難，而且工作負(fù)荷也高。在有資源的團(tuán)隊(duì)，可以同時(shí)設(shè)置業(yè)務(wù)產(chǎn)品經(jīng)理和技術(shù)產(chǎn)品經(jīng)理。不過(guò)目前看到最多的情況是沒(méi)有產(chǎn)品經(jīng)理，更別談明細(xì)分工了。

Scrum Master：設(shè)立該角色是否有必要?在唯品會(huì)之前的公司，通常需要這個(gè)角色來(lái)完成一些Scrum中的日常工作，如貼任務(wù)條，組織planning game等。但是在唯品會(huì)中單獨(dú)設(shè)置這個(gè)比較難，最主要是大家人為認(rèn)為該角色工作含金量低。所以實(shí)踐過(guò)程中，這個(gè)角色就不特定去強(qiáng)調(diào)了，相關(guān)的任務(wù)就分?jǐn)偨o技術(shù)產(chǎn)品經(jīng)理或者開(kāi)發(fā)Leader就可以。

Developer Leader/Architect: 開(kāi)發(fā)負(fù)責(zé)人或者開(kāi)發(fā)架構(gòu)師。在做純技術(shù)產(chǎn)品的團(tuán)隊(duì)，很多時(shí)候技術(shù)產(chǎn)品經(jīng)理的角色被團(tuán)隊(duì)的架構(gòu)師兼任了。這里無(wú)好壞之分，關(guān)鍵在于是否能承擔(dān)相應(yīng)的工作負(fù)荷，是否同時(shí)能把產(chǎn)品架構(gòu)設(shè)計(jì)好也能完成對(duì)外的相應(yīng)工作等。但是更多是看到這樣的架構(gòu)師分身無(wú)力，反而沒(méi)有把足夠精力放在架構(gòu)設(shè)計(jì)上，***造成產(chǎn)品開(kāi)發(fā)實(shí)施中問(wèn)題多多忙于救火。如何區(qū)分技術(shù)產(chǎn)品經(jīng)理和架構(gòu)師呢?最簡(jiǎn)單一句話：產(chǎn)品決定做什么，架構(gòu)決定怎么做。在Scrum中通常沒(méi)有說(shuō)明這個(gè)角色，但是在國(guó)內(nèi)很多團(tuán)隊(duì)的人員技能經(jīng)驗(yàn)不均等的情況下，還是需要這個(gè)角色來(lái)指導(dǎo)團(tuán)隊(duì)的開(kāi)發(fā)。

Tester: 測(cè)試人員。在Scrum模式下，通常是不再?gòu)?qiáng)調(diào)傳統(tǒng)意義上測(cè)試人員的角色。Scrum更追求是開(kāi)發(fā)的自行測(cè)試與自動(dòng)化測(cè)試。但是在團(tuán)隊(duì)開(kāi)發(fā)人員本身對(duì)于測(cè)試技巧，測(cè)試?yán)碚摬簧钊氲那闆r，設(shè)置獨(dú)立的測(cè)試角色還是很有必要的，特別是從傳統(tǒng)的開(kāi)發(fā)模式轉(zhuǎn)型到Scrum模式的團(tuán)隊(duì)。但是需要這個(gè)測(cè)試角色并不意味著依然像傳統(tǒng)方式那樣去執(zhí)行人肉測(cè)試，更多是需要這個(gè)角色從測(cè)試專業(yè)度去設(shè)計(jì)測(cè)試要點(diǎn)，彌補(bǔ)開(kāi)發(fā)者測(cè)試?yán)砟罨蚪?jīng)驗(yàn)上的不足，同時(shí)從產(chǎn)品端到端的角度開(kāi)發(fā)相關(guān)的測(cè)試程序滿足自動(dòng)化要求，并從非功能性上著手測(cè)試開(kāi)發(fā)過(guò)程中難以做的部分，如性能測(cè)試、穩(wěn)定性測(cè)試等。這里需要特別強(qiáng)調(diào)是測(cè)試點(diǎn)設(shè)計(jì)(Test Point Desing)，這個(gè)和產(chǎn)品的架構(gòu)設(shè)計(jì)同等重要，是驅(qū)動(dòng)開(kāi)發(fā)更好思考實(shí)現(xiàn)中有哪些遺漏的地方。這里可以通過(guò)xmind等腦圖工具幫助更有條理的做測(cè)試設(shè)計(jì)。但是看到太多的團(tuán)隊(duì)都是通過(guò)Excel來(lái)發(fā)散性做測(cè)試設(shè)計(jì)，想到哪里做到哪里。這里還有一個(gè)問(wèn)題，就是傳統(tǒng)測(cè)試?yán)砟钕矚g提到的“提測(cè)”。其實(shí)我個(gè)人比較反對(duì)這個(gè)名字，因?yàn)樗鼰o(wú)形中割裂了開(kāi)發(fā)與測(cè)試。那么測(cè)試和開(kāi)發(fā)如何配合呢?埋個(gè)關(guān)子，我下篇再講。

Developer: 似乎最不用說(shuō)明的是開(kāi)發(fā)者了。但是這里還是需要提的是，無(wú)論是什么模式，現(xiàn)在的開(kāi)發(fā)對(duì)于開(kāi)發(fā)者的要求已經(jīng)不簡(jiǎn)單的coding了，而是要求開(kāi)發(fā)更加全面，特別是需要編寫(xiě)好的自動(dòng)化測(cè)試

是不是漏了什么角色?是否想說(shuō)我們沒(méi)有項(xiàng)目項(xiàng)目經(jīng)理的角色?是的，對(duì)于Scrum的方式，其實(shí)更注重的是產(chǎn)品本身，而不是項(xiàng)目。因?yàn)楫a(chǎn)品是有Roadmap，項(xiàng)目猶如一次性的紙杯，做完就不會(huì)再有相同的了。但是是否就不需要項(xiàng)目經(jīng)理了呢?取決于公司情況，據(jù)說(shuō)硅谷多數(shù)公司都是沒(méi)有項(xiàng)目經(jīng)理的，不過(guò)對(duì)于系統(tǒng)龐多的公司，還是需要項(xiàng)目經(jīng)理在特定事情上協(xié)調(diào)多個(gè)產(chǎn)品團(tuán)隊(duì)的。如雙十一活動(dòng)的公司級(jí)項(xiàng)目。

人員配比

一個(gè)比交容易自管理的團(tuán)隊(duì)規(guī)模，從實(shí)踐是1+1+3+2的方式，也就是一個(gè)PO，一個(gè)Architect，三個(gè)開(kāi)發(fā)，兩個(gè)測(cè)試。7人的組合是比較好的配置。很多時(shí)候Scrum無(wú)法開(kāi)展也因?yàn)槿藛T配比的原因，如我們有個(gè)團(tuán)隊(duì)負(fù)責(zé)組建的開(kāi)發(fā)，一人一個(gè)組建，這樣基本就連站會(huì)溝通都困難。

***

***，一個(gè)好的團(tuán)隊(duì)，在具體事情角色分工和配合是清晰的。但是對(duì)于技術(shù)的提升是融合。借用我們團(tuán)隊(duì)Chembo同學(xué)一句拗口的話：不想做好測(cè)試的開(kāi)發(fā)不是好的PO。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創(chuàng)文章，如需轉(zhuǎn)載請(qǐng)通過(guò)51CTO與作者聯(lián)系】

戳這里，看該作者更多好文