傳統到敏捷的轉型中，誰更適合做Scrum Master？_華為雲開發者社群

摘要：本文主要講述的是從傳統到敏捷 Scrum 團隊轉型中，對 Scrum Master 這一角色的分析。

本文分享自華為雲社群《傳統到敏捷的轉型中，誰更適合做Scrum Master？》，作者：敏捷的小智。

目前，越來越多的 IT 企業和團隊開始在做敏捷轉型，而邁向敏捷轉型的第一步，往往就是組建一支敏捷的團隊，在 Scrum 的敏捷團隊中，Scrum Master 起到了至關重要的作用，那麼由傳統向敏捷轉型的過程中，原團隊中誰更適合擔任這樣的角色呢？

本文主要講述的是從傳統到敏捷 Scrum 團隊轉型中，對 Scrum Master 這一角色的分析，關於 Scrum 等其他相關內容等不在本文講述範圍內。

如果想要知道誰更適合，首先要知道 Scrum Master 究竟是幹什麼的。

Scrum Master 作為 Scrum 框架中的三個角色之一，一直以來也沒有一個很好的中文翻譯，而且 Scrum Master 這個詞，從字面意思上理解不僅有精通還有控制的意思，而 Scrum Master 的角色職能上又沒有實際的權利，所以單從詞本身上來看也是充滿了矛盾色彩。

按照 Scrum 指南中的定義，Scrum Master 是負責幫助團隊理解 Scrum 理論、實踐、規則和價值的。對 Scrum 團隊而言，他/她是一位服務型領導。ScrumMaster 幫助 Scrum 團隊之外的人瞭解他/她如何與 Scrum 團隊互動是有益的，通過改變他/她們與 Scrum 團隊的互動方式來最大化 Scrum 團隊所創造的價值。

Scrum Master 的職責不僅在團隊內部服務於產品負責人（Product Owner）和開發團隊，還服務於組織，如下：

ScrumMaster 服務於產品負責人包括：

確保 Scrum 團隊中的每個人都儘可能地理解目標、範圍和產品域；
找到有效管理產品待辦列表的技巧；
幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；
理解在經驗主義的環境中的產品規劃；
確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；
理解並實踐敏捷性；
當被請求或需要時，引導 Scrum 事件。

ScrumMaster 服務於團隊：

作為教練在自組織和跨職能方面給予開發團隊以指導；
幫助開發團隊創造高價值的產品；
移除開發團隊工作進展中的障礙；
按被請求或需要時，引導 Scrum 事件；
在 Scrum 還未完全採納和理解的組織環境中，作為教練指導開發團隊。

ScrumMaster 服務於組織：

帶領並作為教練指導組織採納 Scrum；
在組織範圍內規劃 Scrum 的實施；
幫助員工和利益攸關者理解並實施 Scrum 和經驗導向的產品開發；
引發能夠提升 Scrum 團隊生產率的改變；
與其他 ScrumMaster 一起工作，增強組織中 Scrum 應用的有效性。

除了 Scrum 指南 ，Kenneth Rubin 還給出了 Scrum Master 的職責範圍包括：教練、服務型領導、過程權威、“保護傘”、“清道夫”、變革代言人，而且具備見多識廣、善於提問、有耐心、有協作精神、保護團隊、公開透明的特徵（更多解釋見《Scrum 精髓：敏捷轉型指南》第 10 章的內容）

所以，綜上可以看出 Scrum Master 作為一個非傳統團隊中的角色，是一個需要多項技能和能力的相對比較全面的多面手，對能勝任該角色的人員也是有一定的要求的。如現在比較流行的 T 型人才（在知識結構上有深度也有廣度），甚至多專多能。

一般來說，在傳統團隊，主要的角色有：專案經理、技術經理、QA、測試人員、開發人員等。如果單從原教旨主義來看，傳統的角色可能都不可以做 Scrum Master，但 Scrum 指南也並沒有指明只有什麼樣的角色才可以做 Scrum Master，只要是符合 Scrum Master 的能力要求的不管你之前是什麼角色是都可以。那麼現在的問題，可能就不再是誰可以做 Scrum Master 了。

筆者曾在一段時間內輔導兩家企業做敏捷轉型，這兩家公司都比較小的創業型公司。在轉型初期，其中一家企業 A，在內部探討後決定 Scrum Master 由原團隊中技術比較好的成員擔任，該成員在主要擔任的工作有開發、需求討論和運維等工作，在作為團隊的 Scrum Master 後除了做之前的工作外，也同時擔任著 Scrum Master 的工作，由於人微言輕等因素，在推動 Scrum 的會議和實踐時受到了多方面的阻塞。而另一家企業 B，正好相反，他們的 Scrum Master 由他們的 CEO 擔任，所以可想而知，在實施 Scrum 的過程中非常的“順利”，但是，他們 CEO 還同時擔任著產品負責人的角色。在過程中團隊常常分不清他是 Scrum Master 還是產品負責人，一言堂的局面也是在所難免的。

上述的情況都不是從傳統團隊轉型到敏捷團隊的好例子，在轉型過程中出現問題的情況也還有很多，這基本上都源於轉型團隊對 Scrum Master 這個角色理解上的偏差，對於這種新角色，看似傳統的任意角色都不適合但又好像都可以擔任，“Scrum Master”本身就有一定的矛盾性，從“服務型”或“僕人式”這樣的描述來看好像是沒有管理權利，甚至低人一等的感覺，但是 Scrum Master 確實管理著 Scrum 的過程，為團隊創造最大的價值。那麼從傳統轉敏捷後，到底誰更適合做 Scrum Master 呢？

解決方案

從傳統團隊轉敏捷，擔任 Scrum Master 的分別有：專案經理、技術經理（架構師）、QA(質量保證-QUALITY ASSURANCE)、測試，這些都是筆記見到和了解到的。就如分析中所說，在 Scrum 中沒有指明什麼樣的角色才適合做 Scrum Master，如果非要從中選擇一個相對來說更適合的角色，我們大致上可以以 Scrum 指南上對該角色的職責（服務於產品負責人、服務於團隊、服務於組織）描述來界定的，並給出上述 4 種角色的各自優勢和不足（注：由於每個公司對角色的職能定義不盡相同，下面的分析僅以筆者認知為準）。如下：

可能，有些讀者對於 QA 的這個角色，可能會有人不太熟悉，這裡要特意介紹一下。

QA，在目的上是，為了使管理者和專案人員客觀地瞭解專案執行的活動和工作產品與既定的過程要求和產品標準的符合情況。

QA 角色的特點大致有 5 個方面，即對質量體系實施的作用、對專案 QCD(Quality, Cost, and Delivery)的作用、對管理者的作用、對企業文化的影響、對客戶的影響，具體如下：

綜上所述，QA 的角色所對接的不僅僅是管理者（組織）和專案中的人員（團隊），也對客戶（需求 or 產品負責人）同時也是處理過程改善的過程推動者，相對於其他角色，在 Scrum Master 的職能的契合程度上最高的，而且當一個團隊從瀑布到敏捷的轉型過程中，QA 保障了過程的實施有效性及延續性。所以，QA 轉為 Scrum Master，是筆者見過最多的，也是最成功的。此外，筆者也對其他角色的轉型佔比給出個人傾向的排序：測試>專案經理>技術經理。如果在傳統的團隊中還有 BA（Business Analys）這樣的角色，筆者認為 BA 的優先考慮程度要高於測試（因為一個合格 BA 的職責範圍包括業務和技術等多方面），所以最後的排序為：QA>BA>測試>專案經理>技術經理。讀者可根據自身情況作參考。

然而，雖給出了一個排序，但在真正的團隊轉型過程中，不能是隻單純的把某一原角色轉變成新角色就可以了，還要配合著能力和思想上的轉變，不管是哪種角色，如果想成為一個合格的 Scrum Master，都需要從“心”出發，除了提升自我技能外，還要從思想（同情心、同理心、服務型等）上根本發生轉變。

最後，我們經常會說“沒有銀彈”，確實如此，在實際的工作中，哪怕一個 Scrum Master 完全符合了 Scrum Master 的職能角色定義，也不見就 OK 了，符合定義可能只是會讓 Scrum Master 看起來很 Scrum Master，不見得團隊就能成為一個優秀的高效能的自組織團隊，也不見得所有的過程和問題都可以得到完美實施解決，因為沒有真正的完美，只有是在實踐中尋找、在總結中完善，在提升中蛻變後才能變得完美。別忘了，你們可是敏捷團隊啊，把你的想法落實到迭代中慢慢探索適合自己團隊的道路吧。

參考附錄

《Scrum 精髓：敏捷轉型指南》

《The Scrum Guide》

點選關注，第一時間瞭解華為雲新鮮技術~