在我职业生涯的早期，我曾在多个团队担任技术主管。在这些团队中，我的部分工作就是做决策。我认为我做得很好。果断和自信是我性格的一部分。
但这些性格特征在我成为Scrum Master，以及后来成为产品负责人时并没有太大帮助。作为一名新手Scrum Master，我犯过许多错误（产品负责人也会犯这些错误），其中之一就是断言太多。要想取得成功，我需要问更多的问题。因为那不是我的自然风格，也不是我职业生涯中取得成功的原因，所以我一开始非常困扰。
但通过不懈的坚持，我问问题的能力提高了。我想和大家分享一些我最喜欢问的问题，无论你是 Scrum Master 还是产品负责人，这些都会有所帮助。
估算时：问题 1 和 2
我经常需要Scrum 团队给出一个非常粗略的估算 。我不会让他们严格遵守。
（我不是在要求承诺。估算和承诺不是一回事。）
我真的只是想要一个粗略的估算。我发现在这种情况下，真正有效的方法是问：
1. 我不需要一个估算值。但如果我要求做估算，你们会想到什么单位：小时、天、周、月还是年？
是的，我知道这些单位有重叠——很多周可能超过一个月。但是从团队那里得到一个估算，比如“哦，几周吧”，通常就足以做出决策，包括决定要求团队以更全面的方式正式评估这项工作。
当我从团队获得正式的估算结果时，我经常会问的另一个问题是：
2. 你对这个估算有多大信心？
你在这里要寻找的是信心程度以及团队成员是否达成了一致。如果大多数人都有90%的信心，那么这个估算更有可能是准确的，而如果信心水平各不相同且普遍较低，则估算的准确性会打折扣。
团队成员在估算的信心上存在分歧也可能表明团队在创建估算时有些仓促。这可能是可以接受的，但应考虑该估算的可靠性会较低。
团队决策时：问题 3、4 和 5
作为Scrum Master或产品负责人，我有时想要了解一个团队在做决策时考虑得有多周全。以下是三个我经常问的问题：
3. 在做出这个决定之前，你还考虑了哪三个其他选择？
4. 如果我们选择这个方向，可能发生的最糟糕的情况是什么？
5. 要使这个决定成为最佳决定，哪些事情必须顺利进行？
你可能并不想问所有这些问题，也不必对团队做出的每一个决定都问同样的问题。
此外，你问这些问题并不是因为你（作为Scrum Master或产品负责人）有权否决团队的决定。但是，你确实有权了解团队对决策的信心程度以及他们对决策的认同程度。
这些问题的目的是揭示分歧。“为了使这成为最好的决定，哪些事情必须顺利进行？”而有人回答说“所有事情！”这就可能表明存在问题。
会议时：问题 6 和 7
我真的不喜欢开会。如果我被丢在一条走廊里，走廊一头有蛇，另一头有会议，我不知道我会往哪个方向跑。
所以我尽量将会议次数和会议参加人数保持在最低限度。因此，在会议开始时，我经常会问两个问题：
6. 我们需要现在在场的每个人吗？
7. 还有其他人应该在场吗？
第一个问题旨在看看我们是否能在没有一两个人的情况下顺利完成任务。我经常看到敏捷团队在追求团队合作和协作方面走得太远。团队成员会觉得他们需要参加每一次会议，即使是与他们完全无关的会议。例如，想象一下，一位 JavaScript 开发人员参加了一场关于数据库供应商的最新版本是否值得升级的会议。
如果团队成员过于热衷于参加会议，请感谢他们致力于合作，但向他们保证他们不需要参加每一次会议。建立一个团队规范，如果团队成员的参与不能增加或从中获得足够的价值，那他们就不应该参加这场会议。
（是的，这可能会被滥用。你必须告诉一些人，这并不意味着他们可以选择不参加任何会议。最终，整个团队应该有权否决一个人不想参加会议的意愿。）
沿着这个思路，上面的第二个问题（也是我们列表中的第七个问题）将有助于确定是否有缺席会议的人应该在场。是的，尽管我讨厌开会（我可能会跑向蛇），但有时我们需要让更多人参加。
偏向于减少会议次数和参与人数，但有些会议是值得开的。而这些会议如果能有合适的参与者，就会更有价值。
闲逛时：问题 8
我的风格之一就是花很多时间参与谈话。这就是传统上所谓的“走动式管理”。
例如，如果我看到程序员和测试员正在进行一场似乎很重要的谈话，我可能会走过去听一听，看看是否能提供什么帮助。
（并不是每次他们交谈时我都这样做，如果看起来像是私人对话，我不会打扰。）
有时我听到的讨论可能对其他人有价值。例如，也许我认为技术写作者应该了解程序员和测试人员的决定。所以我会问：
8. 还有其他人需要知道这件事吗？
如果有，我会主动提出去分享信息，如果我可以的话。如果不可以，我会主动去找那个人，让他们可以立即加入谈话。
每日站会时：问题 9
在每日站会期间，我经常会查看团队的Sprint燃尽图，想知道他们将如何在计划的Sprint结束前完成所有工作。但当我问这个团队他们是否会完成所有工作时，他们的回答通常是“会”。
如果我不认为他们的预测是现实的，我会回顾燃尽图并询问：
9. 你知道什么我不知道的信息？
我可能会得到这样的答案：某个团队成员还没有更新他们使用的工具中的工作时间。或者有人会解释说，虽然他们目前落后了，但他们学到了很多东西，事情很快就会加快速度。（我发现这种观点很少成立，但我经常听到这种说法。）
向团队询问他们知道而我不知道的事情，这为同步假设创造了绝佳的机会。也许他们认为事情会加速，而我却不是。这是一个揭示不同假设的好问题。
提问比陈述更能揭示信息
当我刚成为Scrum Master时，我还没有认识到提问的力量，我经常错过了解我的团队及其工作的机会。直到一段时间后，我才发现，对我来说，学习事物的最佳方式是提出问题，然后认真倾听答案。
希望你也和我一样，发现这些问题能很好的帮助到你。你有什么样的好问题？欢迎在评论区分享你的观点。
