作者：Mike Cohn

譯者：李潔（Jerry Li）

審校：廖靖斌（Eric Liao）

幾年前，我把幾個高爾夫球打到湖里了，一起打球的朋友給了我一些建議?，F(xiàn)在那位朋友打高爾夫球已經(jīng)不比我強了，但他仍在沒完沒了地建議。他說，“問題是，你得把球打得更遠?！彼@樣說還不如告訴我，“問題是，你打了很多次才把球打進球洞”。我當然需要打得更遠。但怎么做到呢？

類似的，你們可能也被告誡過——ScrumMaster、敏捷教練或敏捷項目經(jīng)理都可能告誡你——敏捷項目管理是要領導團隊而非管理團隊。

然而，指導ScrumMaster“要領導而非管理”，并不是什么有信息含量的指導。這相當于告訴高爾夫球手要把球打得更遠。這是正確然而沒有可操作性的指導。

如何才能最好地領導那些想變得敏捷的團隊，ScrumMaster們想理解這一點，首先要理解團隊需要什么樣的領導力，然后看看提供領導力的四種不同方法。

這源于保羅·赫塞（Paul Hersey）的情景領導力模型。

赫塞的模型為要采用新工作方式的團隊，描述了四個就緒級別，如圖1所示。

圖1. 情景領導力模型的四個就緒級別

根據(jù)赫塞的理論，領導者們需要調(diào)整其行為以匹配團隊的就緒級別。換句話說，ScrumMaster在與有能力和有意愿的團隊合作時采用的團隊領導方式，跟其與無能力、無意愿的團隊合作時是不同的。赫塞建議，優(yōu)秀的領導者從兩個維度來調(diào)整其領導行為：任務行為（Task Behavior）和關系行為（Relationship Behavior）。

領導者的任務行為，是指領導者對團隊工作進行指導的詳細程度。領導者的關系行為，是其在多大程度上使用與團隊的關系來領導團隊。這些行為共同構成了四種不同的領導風格：告知（Telling）、推銷（Selling）、參與（Participating）和授權（Delegating）。而“正確”的領導風格，就是最匹配團隊就緒級別的領導風格。

在圖2中，以圖形化的方式，展示了團隊就緒級別與領導風格間的關系。在圖2中，沿著X軸分布領導者的任務行為，沿著Y軸分布其關系行為。圖2被劃分為四個象限，四個就緒級別被分配到各個象限中。每個象限都包含著最適合該象限團隊的領導風格名稱。

圖2. 四種團隊就緒級別的四種領導風格

例如，一個無能力和不安的R1團隊，需要團隊ScrumMaster給予更多的任務指導。ScrumMaster將減少對雙向交流（高關系行為）的依賴，而更傾向于單向交流。ScrumMaster必須具備很強的人際技能，但R1團隊（無能力和不安）需要高水平的任務指導，才能贏得足夠的信心，并得以成長為R2團隊，并積極參與雙向交流。相對而言，R3和R4團隊，由于他們的能力水平較高，對ScrumMaster的任務指導需求程度則要低得多。

接下來，本文將詳細剖析ScrumMaster在領導各象限團隊時具體該做什么。

R1團隊的ScrumMaster須為團隊做些決策，以便讓團隊走向成功之路。

在一個無能力且無意愿或不安的團隊（R1團隊）真正變得敏捷前，其成員們首先需要獲得信心。為了幫助他們獲得定心丸，優(yōu)秀的ScrumMaster會更聚焦于告訴團隊成員做什么，而不是建立支持和交流關系。

盡管這似乎與Scrum對自組織團隊的強調(diào)不一致，但現(xiàn)實情況是，R1象限中的團隊并沒有為更好的自組織工作方式做好準備。然而，ScrumMaster和教練可以為此象限團隊打下基礎，使之能迅速成為一個R2（無能力但有意愿或自信的）團隊——一個已經(jīng)為變敏捷而準備就緒的團隊。

對于大型項目或者需團隊成員竭盡全力才能完成的激進目標，R1團隊并未做好準備工作。相反，這種團隊要先從贏得簡單的小目標開始，以增強信心。

R1團隊的ScrumMaster需要為團隊做些決策，來促使團隊走上成功之路。（是的，我剛說過。）這些決策通常涉及到建立一些基本的過程，這些過程將能幫團隊開始感受到成功。

首先，要堅持一到兩周的短沖刺。沖刺越短，團隊成員越能頻繁地感受到Scrum執(zhí)行反饋的效果。在向團隊引入Scrum時，短沖刺是非常有幫助的。新晉敏捷團隊需要評估工作方式。等一個月才能看到?jīng)_刺結果，這往往太長了。

接下來，要學習基礎的敏捷技能，例如測試。要解釋質(zhì)量是每個人的問題，也是每個人的工作。要建立程序員在簽入代碼前必須進行單元測試的規(guī)則。對于這類團隊，測試可以不實現(xiàn)自動化，但必須被完成。

同時，引入持續(xù)集成過程，或者至少做到每日構建。理想情況下，這些構建應該伴隨一個簡單的自動化測試集，可以是單元測試或者功能測試。

在開始時，預期可能不會有太多的測試用例，并且測試還可能會經(jīng)常失敗。然而，在大多數(shù)情況下，經(jīng)過幾周后，測試用例的數(shù)量會增加，構建成功的次數(shù)也將會增加。連續(xù)幾周收到構建成功次數(shù)翻番的正向反饋（以及由此而減少的返工），可以打造奇跡般的團隊士氣和信心。

幾年前，我被指派給一個R1級的、無能力和不安的團隊。團隊成員幾乎都是PC機環(huán)境下的COBOL程序員。公司剛被收購，之前的管理層曾一再告誡團隊成員，說他們沒有能力工作于更新或更有趣的技術。

這個團隊包含一些非常聰明的程序員，但是在被如此對待幾年后，他們毫無信心且技能過時。我為團隊提供了非常具體的指導，指導他們使用什么技術、如何工作等等，幾個月后，團隊恢復了信心。曾經(jīng)功能失調(diào)的團隊進入了R2象限。

R2象限是敏捷化的起點。在R2階段，相關團隊成員進入自我決策階段。

在R2象限，Scrum Master正在合作的是一個能力不足而又有意愿或信心的團隊。在本階段，團隊的發(fā)展目標是提升團隊成員能力。盡管有些團隊是在經(jīng)歷了第一象限和ScrumMaster的告知型領導風格之后才到達這一步，然而許多團隊一開始就是R2團隊。此象限團隊具備敏捷化的必要基礎，但它們還不敏捷。R2團隊需要ScrumMaster采用推銷型領導風格——一種由高度指導性任務行為和高度支持性關系行為結合而成的領導風格。

R2團隊的ScrumMaster已經(jīng)贏得了一定的信任和信心?，F(xiàn)在，是時候利用這些關系來提升團隊敏捷能力了。

在本階段，應當讓團隊成員更多地參與決策過程。盡管仍然需要ScrumMaster為團隊做些決策，但要盡可能邀請團隊參與。

ScrumMaster還會聚焦于幫助團隊成員提高技能。ScrumMaster會繼續(xù)關注測試，但要開始讓團隊成員去挑戰(zhàn)自動化測試的創(chuàng)建。要投入培訓以幫助團隊掌握合適的自動化測試工具——許多工具都能給投入的工作帶來立竿見影的回報。

為了加快知識和技能在整個團隊中的傳播，可以引入結對編程。我很少要求團隊成員以結對的方式編寫代碼，但我確實會要求他們嘗試結對編程，并自行識別結對編程的合適時機。

所有這些行動方案，都是建立在團隊初露頭角的信任之上，傳遞著這樣一個信息：關注代碼的質(zhì)量是可接受的和可取的。長久以來，很多團隊成員聽到的一直是快點、快點、再快點；但卻很難聽到這樣的信息：如果我們編寫出高質(zhì)量的代碼，就能得到更快的速度。提醒他們（以及那些只關注速度的人們），如果你上了高速公路，加速到每小時120英里，你就有可能會收到罰單或出交通事故。不管發(fā)生哪種情況，比起安全、高質(zhì)量的每小時70英里速度，你最終到達目標的速度都不會更快。

就個人而言，我從不告誡團隊（尤其是R2團隊）要加快速度。不過，我會經(jīng)常告誡他們，通過結對編程、自動化測試和重構，他們能學會編寫更好、更高質(zhì)量的代碼。

在“推銷”象限中，要繼續(xù)強調(diào)短迭代。R2團隊仍然能從每1-2周評估其進展中獲益。許多新晉敏捷團隊都很難適應這樣一種理念，即能在每個沖刺中創(chuàng)建高質(zhì)量的軟件。他們已習慣于先進行編碼階段再進行測試階段。

要提醒團隊成員，在Scrum項目中，編碼和測試同時進行的，這樣才能每個迭代都產(chǎn)生潛在可交付的產(chǎn)品增量。在一開始時，由于導致上周所有人都陷入恐慌性加班，許多團隊會拼命對此進行抵制。團隊最終還是能摸索出一種工作方式，使他們每個沖刺都交付高質(zhì)量軟件，但往往需要花費幾個（甚至更多）沖刺才能學會如何做到這一點。沖刺不妨短點，這樣團隊才能盡快掌握這項技能。 

對于R3團隊，要鼓勵他們自行決策。

隨著能力的提升，團隊開始走出R2象限。R3團隊能夠以真正敏捷的方式工作。因此，在此象限中，優(yōu)秀的ScrumMaster會轉(zhuǎn)變?yōu)閰⑴c型領導風格，減少任務指導，同時增加建立關系的行為。

不要把為團隊決策作為輸入（就像R2/推銷象限一樣），而是要鼓勵團隊自行決策。

要盡快這么做——即使團隊還沒意識他們已掌握新能力。面對新增的職責，R3象限團隊通常會短暫地回退到不安。但與R1團隊不同的是，R3團隊能力很強，能快速轉(zhuǎn)變成R4團隊。

為了幫助團隊轉(zhuǎn)變?yōu)樽孕袥Q策，ScrumMaster要徹底退出決策過程。ScrumMaster可以在旁邊鼓勵和支持團隊，但必須向團隊成員清楚地表明由他們自行決策。當然，團隊可能會犯一些決策錯誤。但那又怎樣呢？團隊成員們正在持續(xù)學習，其績效水平通常會比R1時要高出一大截，少許錯誤也只會帶來少許代價。

當團隊開始自組織并持續(xù)發(fā)展其敏捷技能時，ScrumMaster自然地會開始不再狹隘地關注團隊績效，而是更廣泛地關注全局因素。

團隊成員們將狂熱地聚焦于當前迭代選定的工作——未來不超過一到四周的時間范圍。是的，他們可能有一個發(fā)布計劃，會涵蓋未來三到四個月的工作內(nèi)容，但該計劃會刻意在細節(jié)上只進行簡短的描述。由于團隊成員們太聚焦于當前迭代的樹木，因此不得不信賴其ScrumMaster來關注長期的森林。

在這方面，ScrumMaster可以做很多事情。

首先，ScrumMaster可以看看當前迭代之后有什么需要提前規(guī)劃的事項。例如，與公司內(nèi)某項特定技術專家進行面談，或許能為團隊帶來好處。不幸的是，專家的辦公室在2000英里之外。而為了符合公司的差旅準則，他的機票必須提前兩周以上購買。又或者在幾個沖刺后，團隊計劃實現(xiàn)的某個特定用戶故事，這個故事需要銷售副總裁、市場副總裁和部門總經(jīng)理的大量投入。需要提前規(guī)劃好與這三個人的協(xié)作時間。

其次，ScrumMaster要確保每個沖刺所關注的用戶故事都不會偏離已納入發(fā)布版本的主題。由于Scrum鼓勵在每個沖刺開始時重新評估所規(guī)劃工作的優(yōu)先級，產(chǎn)品負責人和團隊可能會逐漸偏離于更大的里程碑或發(fā)布版本。

如果這些偏離是刻意的，是從前期沖刺中吸取教訓的成果，那這是一件非常棒的事情。然而，如果這是團隊和產(chǎn)品負責人過于關注樹木而忽視森林的結果，那么ScrumMaster就能協(xié)助讓項目回歸正確方向。

最后但并非最不重要的，ScrumMaster要確保團隊始終盡可能地從事最高價值的工作。為了做到這一點，可采用的方法是：在項目的推進過程中，投入精力與產(chǎn)品負責人一起對產(chǎn)品待辦列表進行優(yōu)先級排序和調(diào)整。

一旦團隊達到了R4就緒級別，優(yōu)秀的ScrumMaster將從參與型領導風格轉(zhuǎn)變?yōu)槭跈嘈皖I導風格。ScrumMaster必須更多地關注如何最大化團隊產(chǎn)能。

一旦團隊達到了R4準就緒級別，優(yōu)秀的ScrumMaster將從參與型領導風格轉(zhuǎn)變?yōu)槭跈嘈皖I導風格。此時，團隊只需要最少量的任務指導。需要時ScrumMaster可以提供幫助，但不要具體說明如何完成工作。

首先，除了授權團隊決策外，還要向團隊展示如何盡可能長的延遲決策。在延遲決策時，團隊能繼續(xù)接納其他方案，并將新的知識融入到最終決策中。我們希望開發(fā)人員在設計和編碼時能夠做到這一點。在Scrum項目中，我們要求團隊只編寫實現(xiàn)正在開發(fā)特性所必需的代碼。我們不會要求他們猜測著構建我們“某天”可能會需要的低優(yōu)先級功能。

例如，假設我們的一個合作伙伴想要向我們發(fā)送一份他們要加載到系統(tǒng)中的每周事務文件。我們還不知道它是采用逗號分隔的、固定長度的還是XML文件。我們不會寫一個支持所有這三種輸入的加載器，而是會延遲決策。這意味著我們可能不會編寫任何加載器代碼?；蛘?，意味著我們在開始編碼時可能會先對輸入數(shù)據(jù)源進行假設，并基于問題假設進行編碼。

決策時機是一切。在早先Java開發(fā)的日子里，我管理過一個項目，這個項目既可以交付為Java客戶端，也可以交付為原生的Windows客戶端。兩種方式各有利弊。我剛一啟動這個項目，就把“解決UI平臺問題”列入了待解決問題清單。為此，我召集了主要的開發(fā)人員一起討論，并一起快速做出了決策。

當然，我們做出的決策是錯誤的。然而，即使我們選擇了另一個平臺，我仍然會說我們做出了錯誤的決策。在當時這種情況下，正確的決策應該是延遲決策。在項目早期，我們沒有任何決策依據(jù)。當然，最終某天還是會做出決策，但這事絕不應該發(fā)生在項目的第二周。

因此，要讓團隊自行決策，但還要指導和建議他們，將決策推遲到盡可能晚的時候。

第二，致力于最大化團隊的總體產(chǎn)能。傳統(tǒng)管理的項目常常令人感覺像是一場有明確終點線的比賽，就像是10公里徒步跑或50英里自行車賽。而Scrum則更像是一場讓你明白24小時能跑多遠的比賽。Scrum項目通常沒有終點線。取而代之的是，只要時間用完了你就得停下來。如果需要交付更多的功能，你可以再重新開始；否則，你的工作就已經(jīng)完成了。這種差異導致Scrum團隊處理項目的方式，與傳統(tǒng)管理者不一樣。

傳統(tǒng)的項目經(jīng)理聚焦于實現(xiàn)最終目標，即在特定日期發(fā)布特定的功能集。

沒什么可以超出這個目標。起初，這似乎是支持傳統(tǒng)項目管理的一個優(yōu)勢。然而，如果在項目截止日期前一個月時，有位開發(fā)人員告訴項目經(jīng)理，擔心某領域代碼雖然暫時能用但卻結構脆弱，并在隨后幾個月可能會成為問題之源。你認為，項目經(jīng)理可能會作何反應。傳統(tǒng)的項目經(jīng)理非常可能會做出短視的決策，冒險采用脆弱的代碼。

而ScrumMaster則必須更加關注團隊產(chǎn)能的最大化。在某些特殊情況下，團隊或許也會贊成不重構脆弱的代碼以滿足一個月的最后期限。然而一般來說，正確的做法會是為保護團隊的整體產(chǎn)能而進行代碼重構。ScrumMaster的工作是鼓勵團隊朝此方向轉(zhuǎn)變，并保護他們免受外界的非議。

這只是一個例子，或許還有其他很多例子。這里的關鍵區(qū)別在于，傳統(tǒng)項目是以滿足截止日期交付特定功能集為唯一目標進行管理的。敏捷項目當然也可能會承諾功能的最后期限，但與此同時也看重團隊的長期持續(xù)產(chǎn)能。

隨著團隊從成功中獲得自信以及能力的提升，他們需要被以不同的方式進行領導。在正確的時間引入和提煉技巧是至關重要的。

領導是ScrumMaster與其團隊所進行的每次交互的總和：說什么，不說什么，怎么說，如何傾聽。作為一名優(yōu)秀的Scrum團隊領導者，ScrumMaster不要大喊“該死的魚雷！”（譯者注：“該死的魚雷！全速前進！”是美國海軍上將大衛(wèi)法拉格特的命令，這里是指讓團隊全速前進，奮力向前沖），也不要只是安靜地坐在團隊之外聽團隊召開每日立會。取而代之的是，ScrumMaster必須學會如何才能成為一名優(yōu)秀的敏捷領導者——一名優(yōu)秀的ScrumMaster，必須經(jīng)常陪伴著正在學習如何變敏捷的團隊。

提升技能成為一名ScrumMaster和幫助團隊變敏捷并非難事。然而，建立一個關于團隊就緒度和向給定團隊應用領導風格的心理框架，確實是有幫助的。情境領導模式提供了這個框架。隨著團隊從成功中獲得自信以及能力的提升，他們需要被以不同的方式進行領導。 

能力有限且信心有限的團隊，通常需要告知型領導風格。當領導R1團隊時，可以通過引入短沖刺和組織團隊贏得一系列的小目標來增強他們的信心。要引入基本的敏捷實踐，例如增加對測試和持續(xù)集成的關注。從這些實踐中，團隊將會獲得以新的、更敏捷方式工作在技巧和能力上的信心。 

一個能力有限而又有意愿和自信的團隊，會受益于推銷型領導風格。領導R2團隊時，要關注與團隊的關系，而不能只進行任務指導。這類團隊只是需要時間、動力和練習來提升他們的技能。 

為了創(chuàng)造學習機會，要強調(diào)每個沖刺結束時交付高質(zhì)量產(chǎn)品的必要性。通過工作于短迭代，并在每次迭代結束時聚焦于創(chuàng)建潛在可發(fā)布的軟件，團隊成員們會自然而然地探索提升技能的方法。

能力已顯著提升的團隊，已經(jīng)為接受更具有參與性的領導風格做好準備。然而，當團隊必須自己做決策時，他們往往會變得緊張，想知道他們新獲得的技能是否足以勝任。通過在決策中支持R3團隊，以及把自己的關注集中于長期（3-6個月）范圍，使團隊能夠?qū)⑺凶⒁饬劢褂诋斍皼_刺，來引導他們完成這一轉(zhuǎn)變。

要做到這一點，有一種方法是確保沖刺都始終聚焦于下一個發(fā)布版本的目標，即使在每個沖刺開始時都重新排定了工作的優(yōu)先級。同時，通過與產(chǎn)品負責人協(xié)作，對產(chǎn)品待辦列表進行適當?shù)貎?yōu)先級排序，以確保公司為團隊選擇高價值的工作。

一些ScrumMaster非常幸運，能與有能力、有意愿的、已經(jīng)準備好承擔更大責任的R4團隊合作。在這種情況下，應采取授權型領導風格。

在Scrum項目中，需要考慮不局限于單個項目范圍的產(chǎn)能最大化。這意味著要幫助團隊學會延遲決策，以便盡可能長時間地保持各種候選方案都可用。

不同于我的高爾夫球友只會給出“把球打得更遠”的建議，本文介紹了ScrumMaster可以實施的具體事項，這能幫助他們成為更有效的敏捷團隊領導者。雖然這里提及的所有技術都可以應用于任意級別的團隊，但是我結合就緒級別來描述這些技術，我認為這種應用方式是最有益的。

在正確的時間引入和提煉技巧是ScrumMaster 幫助團隊演進到R4級別和授權型領導風格的最佳方式。 

英文版PDF下載鏈接：https://www./blog/tag/scrummaster

作為Mountain Goat軟件公司的創(chuàng)始人，Mike Cohn致力于幫助企業(yè)采用敏捷和改進其對敏捷過程和技術的使用，以打造極高性能的開發(fā)組織。

自從1994年運作首個Scrum項目以來，Mike就一直是大力呼吁支持Scrum的倡導者。Mike擁有20多年的實踐經(jīng)驗，他曾是各種規(guī)模公司（從初創(chuàng)公司到財富40強）的技術主管。

如今，Mike是業(yè)界最受歡迎的認證Scrum培訓師之一。他是三本關于Scrum和敏捷書籍的作者，也是敏捷在線培訓網(wǎng)站（frontrowAgile.com）的創(chuàng)始人。

他還是Scrum聯(lián)盟和敏捷聯(lián)盟的創(chuàng)始成員，經(jīng)常在各種行業(yè)會議和企業(yè)活動上發(fā)表主題演講，是其熱門Scrum和敏捷博客上的思想領袖。