摘要：本文主要講述的是從傳統到敏捷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 團隊而言，他/她是一位服務型領導。Scrum Master 幫助 Scrum 團隊之外的人了解他/她如何與 Scrum 團隊交互是有益的，通過改變他/她們與 Scrum 團隊的互動方式來最大化 Scrum 團隊所創造的價值。
Scrum Master的職責不僅在團隊內部服務於產品負責人（Product Owner）和開發團隊，還服務於組織，如下：
Scrum Master 服務於產品負責人包括：
- 確保 Scrum 團隊中的每個人都盡可能地理解目標、范圍和產品域；
- 找到有效管理產品待辦列表的技巧；
- 幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；
- 理解在經驗主義的環境中的產品規划；
- 確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；
- 理解並實踐敏捷性；
- 當被請求或需要時，引導 Scrum 事件。
Scrum Master 服務於團隊：
- 作為教練在自組織和跨職能方面給予開發團隊以指導；
- 幫助開發團隊創造高價值的產品；
- 移除開發團隊工作進展中的障礙；
- 按被請求或需要時，引導 Scrum 事件；
- 在 Scrum 還未完全采納和理解的組織環境中，作為教練指導開發團隊。
Scrum Master 服務於組織：
- 帶領並作為教練指導組織采納 Scrum；
- 在組織范圍內規划 Scrum 的實施；
- 幫助員工和利益攸關者理解並實施 Scrum 和經驗導向的產品開發；
- 引發能夠提升 Scrum 團隊生產率的改變；
- 與其他 Scrum Master 一起工作，增強組織中 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》