寫在前面的話

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

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

為什么會在唯品用Scrum

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

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

所以在廣州我們這個基礎架構的團隊就自然而然的開始了Scrum模式開發。也就是說因為人員的過往經歷使我們繼續走在了Scrum的道路上。

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

團隊的組成

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

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

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

其次，在平臺部門技術產品經理對接的上游是技術開發部門，而不是業務/商務部門，需要以技術的視角來溝通和協調業務開發上遇到的困難，并推動相關的產品的實施與運作，而不是去做商務分析如RoI等。

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

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

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

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

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

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

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

人員配比

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

***

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

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創文章，如需轉載請通過51CTO與作者聯系】

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