在成為Scrum Master（SM）之前，我曾擔任過許多團隊的技術負責人。工作內容之一就是做決定，而且我認為自己做得挺好：堅定果斷是我性格的一部分。
然而，當我成為Scrum Master之后，這樣的性格並沒有為我帶來多少好處。我開始意識到，要想做一名成功的Scrum Master，我需要從做決策轉為提問題。然而這不符合我一貫的風格，在過去也未給我帶來任何成功，因此在一開始的時候我是很掙扎的。
但是，當我不斷從提問的過程中受益時，我會很樂意和大家分享我最愛問的問題。其中大部分問題在團隊中都很容易被問到，無論你是Scrum Master還是PO。
2個關於估算的問題
我經常會要求團隊進行一個粗略的估算，並不是要求讓他們按照估算去做（因為我不是要求他們承諾，估算和承諾不是一回事兒）。我確實只是需要一個粗略估計。在這種情況下要做得好，得這樣問：
我並不是在要求一個具體的估算值，而是當我問你的時候你腦海里浮現出的是什么：幾小時、幾天、幾個星期、幾個月或者是幾年？
當然，我知道這些時間有些是重疊的——幾個星期可能就比一個月長。但是如果從團隊那里得到類似“哦，只要幾個星期”的估計時，通常已經足夠做決定了。包括可能要求團隊做出更確切的工作評估。
當我要求確切的工作評估時，我通常會問另一個問題：
你對這個估算有多大的信心？
你在這里要去發現他們對此抱有多大的信心以及團隊其他成員是否贊成，一個預估如果有90%的人抱有信心，那么它極有可能是精確的。
3個關於團隊決策的問題
作為Scrum Master或是PO，有時候我會想知道團隊在做決定的時候做了哪些考慮。通常我會問這樣三個問題：
-
你在做出決定前你還考慮過其他三個選項嗎？
-
如果我們繼續按此方向進行，可能發生的最糟糕的情況是什么？
-
要做些什么才能讓這個決定成為最佳決策？
你可能不問這三個問題，也不在團隊每次做決定的時候問同樣的問題。你不問這些問題是因為作為一名Scrum Master或PO，你有權利否定團隊的決定。但是，你同樣有義務去理解團隊對此決策的信心。
設計這些問題是為了發現不同的見解，因為當你直接問“要做些什么才能讓這個決定成為最好的？”而有人回答說“所有事情”時，這就有可能會出問題。
2個關於開會的問題
我真的不喜歡開會。如果我被扔到一個一頭有蛇，另一頭在開會的的走廊上，我不確定自己會跑向哪邊。
所以我會盡量將開會次數及參會人數保持到最少。而且在會議開始時我會問兩個問題：
-
在場的各位都需要開這個會嗎？
-
還有其他人在這里嗎？
問第一個問題是想看看如果少一兩個人這個會議是否還能繼續。我經常看見敏捷團隊過於追求團隊協作，成員總會覺得每次開會他們都需要參加，甚至是和他們不相干的會議。曾經有JavaScript的程序員參加了關於數據庫供應商發布的最新版本是否值得升級的討論會。
如果你團隊成員對開會這件事過分熱心，那你需要感謝他們對協同工作的用心，但是要明確告知他們不需要出席每個會議。
建立團隊規范，如果團隊成員在會議中不能創造價值或者沒有收獲，那他就不能參加這個會議。
當然，你必須明確告訴大家這並不代表他們可以選擇每個會議（要不要參加），以防止這個規定被濫用。最后，團隊作為一個整體有權否決某人不願意參加某個會議的想法。
第二個問題是為了確定是否有人缺席。盡管我真的很討厭開會，但有的時候會議真的需要很多人。
盡管我認為開會和開會的人越少越好。但是有的會議是值得的，而這些會議因為有了合適的參與者而產生更多價值。
1個在“閑逛”時提的問題
在成為Scrum Master后，我花了更多時間在交流上。這就是傳統的走動式管理。舉例來說，如果我看到程序員和測試員在進行一場重要的談話，我可能會走過去聽他們在說什么，因為也許我能給他們提供一些幫助。（當然了，不要每次都走過去，尤其是他們看起來是在討論私事的時候）。
有時候我聽得到的討論可能是對其他人有價值的。比如我認為一個技術作者應該了解程序員和測試員會怎樣做決定。所以我會問：
有其他人需要知道這件事嗎？
如果答案是肯定的，那我會盡量找一個人將這些信息分享出去。
1個在每日站會時提的問題
在每日站會中，我會去關注團隊的燃盡圖，並思考他們怎樣在sprint結束時完成所有計划。但是，當我問同一個團隊他們是否能完成所有事情時，答案通常是肯定的。
如果我認為他們的預測不現實，我會看着燃盡圖並且問道：
你知道我想了解的是什么嗎？
我可能會得到這樣的答復：有成員沒有更新自己的工時。或者有人會解釋說他們的進度目前的確有點落后，但是他們已經學會了很多東西而且馬上就會提速趕上。（我發現這種說法很少實現，因為我經常聽到這樣說）。也許他們認為正在加快速度，但我不是這樣想的。這是個發現不同假設的問題。
總結
提問比陳述更能說明問題
在我才剛開始成為Scrum Master，還沒有發現提問的作用時，我經常錯過了解團隊和他們工作內容的機會。直到我發現了提問並認真聽取答案是學習的最佳途徑。
希望你也像我一樣發現這些問題的作用！
英文原文網址：https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking