起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識在敏捷開發中，你需要具備的提問技巧
作為Scrum Master，你必須要會提問題。如果你還不知道該如何提問，那就進文章中來看看，你需要具備哪些提問技巧。
在成為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結束時完成所有計劃。但是，當我問同一個團隊他們是否能完成所有事情時，答案通常是肯定的。
如果我認為他們的預測不現實，我會看著燃盡圖并且問道：你知道我想了解的是什么嗎？
我可能會得到這樣的答復：有成員沒有更新自己的工時?；蛘哂腥藭忉屨f：他們的進度目前的確有點落后，但是他們已經學會了很多東西而且馬上就會提速趕上。（我發現這種說法很少實現，因為我經常聽到這樣說）。
也許他們認為正在加快速度，但我不是這樣想的，這是個發現不同假設的問題。
總結
提問比陳述更能說明問題
在我才剛開始成為Scrum Master，還沒有發現提問的作用時，我經常錯過了解團隊和他們工作內容的機會。直到我發現了提問并認真聽取答案是學習的最佳途徑。
希望你也像我一樣發現這些問題的作用！
原文鏈接：https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking
本文由@行動派小助手 翻譯發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自UNplash，基于cc0協議
學習了