SM干货篇：你应该具备的提问技巧！

在成为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

巴特西