官方《Scrum指南》中定義：Scrum Master在Scrum團隊中屬於服務型領導，負責踐行和支持《Scrum指南》中定義的Scrum，要幫團隊的每一個人理解Scrum理論、實踐、規則以及價值觀。markdown
最近咱們進行了一次調查，其中92％的受訪者表示他們正在實踐的scrum是按需定製的，而非「按章辦事」。這讓咱們想知道，這對扮演訓練和幫助團隊理解scrum角色的scrum master來講意味着什麼？ 這些scrum master是如何適應不斷髮展的且有別於官方規定實踐的敏捷世界的？框架
爲了回答這些問題，咱們對敏捷行業的無名英雄——scrum master的角色和責任進行了深刻研究。工具
Scrum Master是什麼？
Scrum Master是scrum的推進者。scrum是一種輕量級敏捷框架，專一於實現固定時間的迭代，也被稱爲sprint。做爲推進者，scrum master充當團隊其餘成員的教練，在《Scrum指南》中被稱爲「服務型領導」。優秀的scrum master致力於構建scrum的基礎和價值觀，同時保持必定的靈活性和開放性讓團隊有機會改進工做流程。翻譯
1.Scrum Master的職責
在理想的敏捷世界中，團隊能夠管理本身的流程和工具。然而，咱們發現許多團隊一般須要依賴scrum master做爲其流程的主導者才能實現敏捷的飛躍。要實現對團隊的掌控，並履行職責，scrum master須要花費大量的時間。在這種變革性的背景下，scrum master的工做能夠很輕鬆，如僅安排scrum相關儀式；也能夠很繁重，像團隊的其餘成員同樣深度參與整個過程。儘管《Scrum指南》列出了scrum master應該如何爲其餘角色提供服務，但關於scrum master的責任義務並無詳細列出來。事實上，咱們發現，scrum master一般須要執行下面部分或所有並無在scrum中定義的工做：blog
1.站會 ——根據須要促成每日站會（或每日scrum會）。
2.迭代/sprint規劃會 ——確保團隊不會承擔過多或超出能力範圍。幫助團隊進行估算及子任務的建立。
3.sprint評審會 ——參加會議並記錄反饋。
4.回顧會議 ——記錄須要改進的領域和後續sprint的行動項目。
5.委員會管理 ——承擔Scrum委員會的管理工做。而且保證信息的即時性及Scrum工具（Worktile或其餘工具）運行良好。
6.一對一談話 ——根據須要與團隊成員和利益相關者單獨談話。化解團隊對在流程和工做方式等方面的分歧。然而許多scrum從業者都反對一對一談話，由於他們認爲這些交流應該在每日站會上進行，一些團隊，特別是新團隊，更傾向於請scrum master與個別團隊成員按期進行面對面交流。scrum master則認爲這些單獨的交流互動對於團隊發展和成員之間的彼此瞭解相當重要。
7.內部協商 ——scrum master應該與團隊成員和內部利益相關者進行協商，就如何更好地與Scrum團隊合做達成一致。
8.報告 ——按期分析燃盡圖和其餘投資組合規劃工具，以瞭解團隊正以什麼樣的節奏構建產品。
9.護航者 ——scrum master經過消除外部障礙和改進過程或工做流管理內部障礙等方式爲團隊提供支持。
10.代勞雜務 ——若是scrum團隊沒有處於忙碌的狀態，那就是scrum master的問題。由於這意味着團隊可能在修理壞掉的電腦、挪動周圍的桌子甚至調整恆溫器。Scrum master應該隨時準備好作任何能夠幫助團隊的事。若是團隊真的須要的話，scrum master甚至須要爲成員準備咖啡和零食，以確保成員不須要在此類瑣事上浪費時間或趁機磨洋工。進程
2.你的團隊是否須要一個scrum master？
任何一個scrum培訓師都會告訴你，每一個scrum團隊都應該有一個scrum master。若是沒有，那麼大家的scrum就算不上真正的scrum，常常被叫作scrum-but。開發
在團隊剛開始嘗試scrum的時候，有一個具有scrum工做經驗的scrum master能夠帶來很大的幫助曾，固然，曾經見證過不少scrum成功案例者更佳。也正由於這個緣由，不少scrum master常常被聘用來擔任顧問，而非全職員工。get
但每一個scrum團隊都是獨一無二的。不少經驗豐富的團隊承擔前面列出的全部關於scrum master的責任，享受由團隊成員共同管理的流程併爲此感到自豪。這種狀況下，scrum master的角色將由團隊成員輪流承擔，並輪流組織召開每日站會和回顧會議。博客
而對於一些團隊來講，正確的作法就是請一個專業人員來擔任scrum master。工作流
不幸的是，因爲對scrum master角色存在誤解，因此常常致使現任管理者認爲scrum master是他們崗位職責的一部分。爲了更好的理解爲何這樣作會形成問題，以及爲何要在組織中單獨設立scrum master的角色，咱們將scrum master的角色與組織中現存的非scrum角色來作一個對比。
Scrum Master和產品經理
正如咱們在《敏捷產品管理概述》中提倡的那樣，產品經理與開發團隊之間的互動越多越好。這種互動應該與產品負責人的想法保持一致：支持客戶需求且清楚爲何開發這款產品。但若是這種互動模糊了任務-即團隊該怎麼實現功能，那就說明互動存在問題。儘管出發點很好，但這種利用型心態會致使問題被隱藏或掩蓋，如：缺陷、交接和未知問題等。交錯範圍和進程很容易鎖定範圍、進度和質量，而這注定致使失敗。
這就是爲何scrum master和產品負責人在scrum團隊中分別知足兩個不一樣需求的緣由，但這兩個角色在傳統軟件管理中一般是由一我的來擔任。規模較小的團隊也很容易就爲了節約支出而省掉scrum master這個職位。只是，一旦有障礙出現或變更發生，團隊就須要在流程管理和產品方向之間進行明確劃分。
團隊中若是有scrum maser就能夠幫助團隊實現因改變產品方向所帶來的消耗和由效率提高所帶來的收益兩者之間的平衡。一個優秀的scrum master經過賦予團隊權利，讓他們自行決定如何經過自組織的方式以最好的方式實現目標。
Scrum Master和項目經理
在非技術（或非敏捷）領域與scrum master角色對應的是項目經理的職位。這兩種角色都專一於「如何」完成工做並經過過程和建導解決工做流程的問題。那麼咱們是否同時須要這兩個崗位呢？大多數狀況下是不須要的。
傳統的項目經理和scrum master都有責任幫助他們的團隊完成工做，但他們的方法卻大相徑庭。項目經理設定時限和里程碑、報告進度並協調團隊溝通。從控制的角度實施工做，扮演一個比較傳統的管理者角色。
Scrum Master則旨在幫助團隊強化和精簡實現目標的流程。理想狀態下，他們是以團隊成員或協做者而不是控制者的身份開展工做。最好的Scrum團隊是自組織的，所以自上而下的管理不會取得好效果。
這只是一些Scrum團隊管理的一些建議配置。有些團隊配備全部角色，有些組織設置一個或根本沒有。
Scrum Master能爲組織帶來更大收益
在考慮是否聘請scrum master的時候，有一個考量因素優先於其餘任何因素，即：只有在您的組織致力於scrum並願意投資這個流程時才聘請。以上提到的各種管理角色均可以經過多種方式管理開發團隊，但scrum master只有在100%投入scrum時纔有效。
經過scrum master幫助每一個團隊管理他們的流程，整個組織能夠得到一些重大收益。除了按期向客戶提供交付價值（scrum的主要目標）外，團隊成員和經理能夠自由地專一於他們擅長的事。產品經理專一於戰略、開發人員專心寫代碼，而銷售人員則全身心的開發客戶。這像什麼？這就是高效運做的scrum團隊該有的樣子，也是咱們最期待的場景。
做者：MAX REHKOPF
翻譯/校對：Worktile
文章來源：Worktile敏捷博客