寫在前面的話

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

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

為什么會在唯品用Scrum

時間需要倒流到2015年7月，多輪面試后終于進入唯品會平臺架部–基礎架構(gòu)部。不過每次換工作都是在上一家經(jīng)歷很長的時間后，所以面試技巧都不怎么樣，總覺得懂啥說啥，因為就算忽悠進來也做不出啥來，所以基本上面試也沒準備什么。或許屬于你的地方通常都要先考驗你，也不怕笑話，進入唯品會我前后半年面了3次，***還是這個部門的領導有眼光要了我。雖然中間有被打擊到，但是后來想想也沒什么，本身找工作就是一個緣分的過程。這些都是插曲了。

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

所以在廣州我們這個基礎架構(gòu)的團隊就自然而然的開始了Scrum模式開發(fā)。也就是說因為人員的過往經(jīng)歷使我們繼續(xù)走在了Scrum的道路上。

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

團隊的組成

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

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

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

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

再次，對于開發(fā)過程中出現(xiàn)的問題或者團隊中有爭論的點，需要以技術的視野來判定對產(chǎn)品的影響，從而決定事情的優(yōu)先級，從而推動產(chǎn)品的進展

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

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

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

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

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

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

人員配比

一個比交容易自管理的團隊規(guī)模，從實踐是1+1+3+2的方式，也就是一個PO，一個Architect，三個開發(fā)，兩個測試。7人的組合是比較好的配置。很多時候Scrum無法開展也因為人員配比的原因，如我們有個團隊負責組建的開發(fā)，一人一個組建，這樣基本就連站會溝通都困難。

***

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

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

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