如何跨出敏捷Scrum第一步？唯品會是這麼做的

邱戈川/數人云產品總監

了哥，原名邱戈川，17年IT老兵，曾任唯品會分散式架構平台技術產品經理，現數人云產品總監~他在唯品會主導的基於Docker、Mesos的分散式服務框架，廣泛用於各大核心業務系統，在這過程中也很好地將敏捷Scrum落地。

近期小數推薦了《LinkedIn的SRE文化》、《當心DevOps的虛假指標》等文章，

了哥這篇同樣是一種理念——敏捷Scrum。

哦漏，這麼多理念該相信哪一個？

莫急，一張圖了解DevOps&SRE&Scrum的關係：

哈哈，借用了哥的一句話：不以敏捷開發為基礎的DevOps都是耍流氓！

一起來看看了哥是如何在唯品會實踐敏捷Scrum的。

寫在前面的話

寫這個系列文章的目的不是為了說明什麼是Scrum，畢竟講Scrum的書和文章已不計其數。我寫這個文章是希望總結我在唯品會一年多來實行Scrum開發模式的一些回顧、總結以及後續可能需要改進的地方的探討。

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

在唯品會，工作上的氛圍則相對寬鬆，因為之前已經有兩個原來的同事先進來同一個部門了，一個江湖人稱「江南白衣」，一個人稱「隔壁老王」。因為部門廣州的人少，所以我們三個就延續了原來的工作方式，照例施行Scrum模式。一開始還擔心部門領導或公司對於工作方式有明確要求，後來才知道，其實唯品會在公司範圍沒有明確的工作方式的指引，全靠團隊自身。另外部門領導遠在美國，經（shi）歷（mian）比我們多，抓大放小就讓我們自己管自己了。不過源於之前公司的文化熏陶，大家工作上自覺性還是很高的，也沒有什麼需要特別管理的地方。

不過現在回頭看，還好我是在平台部門，而不是業務部門，不然施行Scrum模式將會遇到巨大的困難，因為在平台部門產品規劃、發布等都是自主安排，而不是外部驅動，不然由業務計劃倒推產品計劃將是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。

了哥(邱戈川)公眾號：vipdocker

推薦閱讀：