在敏捷开发中,你需要具备的提问技巧

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

作为Scrum Master,你必须要会提问题。如果你还不知道该如何提问,那就进文章中来看看,你需要具备哪些提问技巧。

在成为Scrum Master(SM)之前,我曾担任过许多团队的技术负责人。工作内容之一就是做决定,而且我认为自己做得挺好:坚定果断是我性格的一部分。

然而,当我成为Scrum Master之后,这样的性格并没有为我带来多少好处。我开始意识到:要想做一名成功的Scrum Master,我需要从做决策转为提问题。

然而这不符合我一贯的风格,在过去也未给我带来任何成功,因此在一开始的时候我是很挣扎的。

但是,当我不断从提问的过程中受益时,我会很乐意和大家分享我最爱问的问题。其中大部分问题在团队中都很容易被问到,无论你是Scrum Master还是PO。

2个关于估算的问题

我经常会要求团队进行一个粗略的估算,并不是要求让他们按照估算去做(因为我不是要求他们承诺,估算和承诺不是一回事儿),我确实只是需要一个粗略估计。

在这种情况下要做得好,得这样问:我并不是在要求一个具体的估算值,而是当我问你的时候你脑海里浮现出的是什么:几小时、几天、几个星期、几个月或者是几年?

当然,我知道这些时间有些是重叠的——几个星期可能就比一个月长。但是如果从团队那里得到类似“哦,只要几个星期”的估计时,通常已经足够做决定了,包括可能要求团队做出更确切的工作评估。

当我要求确切的工作评估时,我通常会问另一个问题:

你对这个估算有多大的信心?你在这里要去发现:他们对此抱有多大的信心以及团队其他成员是否赞成,一个预估如果有90%的人抱有信心,那么它极有可能是精确的。

3个关于团队决策的问题

作为Scrum Master或是PO,有时候我会想知道团队在做决定的时候做了哪些考虑。

通常我会问这样三个问题:

  • 你在做出决定前你还考虑过其他三个选项吗?
  • 如果我们继续按此方向进行,可能发生的最糟糕的情况是什么?
  • 要做些什么才能让这个决定成为最佳决策?

你可能不问这三个问题,也不在团队每次做决定的时候问同样的问题。你不问这些问题是因为作为一名Scrum Master或PO,你有权利否定团队的决定。但是,你同样有义务去理解团队对此决策的信心。

设计这些问题是为了发现不同的见解,因为当你直接问“要做些什么才能让这个决定成为最好的?”而有人回答说“所有事情”时,这就有可能会出问题。

2个关于开会的问题

我真的不喜欢开会,如果我被扔到一个一头有蛇,另一头在开会的的走廊上,我不确定自己会跑向哪边。所以我会尽量将开会次数及参会人数保持到最少。

而且在会议开始时我会问两个问题:

  1. 在场的各位都需要开这个会吗?
  2. 还有其他人在这里吗?

问第一个问题是想看看:如果少一两个人这个会议是否还能继续?

我经常看见敏捷团队过于追求团队协作,成员总会觉得每次开会他们都需要参加,甚至是和他们不相干的会议。曾经有JavaScript的程序员,参加了关于数据库供应商发布的最新版本是否值得升级的讨论会。

如果你团队成员对开会这件事过分热心,那你需要感谢他们对协同工作的用心,但是要明确告知他们不需要出席每个会议。

建立团队规范,如果团队成员在会议中不能创造价值或者没有收获,那他就不能参加这个会议。

当然,你必须明确告诉大家,这并不代表他们可以选择每个会议(要不要参加),以防止这个规定被滥用。最后,团队作为一个整体有权否决某人不愿意参加某个会议的想法。

第二个问题是为了确定是否有人缺席?

尽管我真的很讨厌开会,但有的时候会议真的需要很多人。尽管我认为开会和开会的人越少越好,但是有的会议是值得的,而这些会议因为有了合适的参与者而产生更多价值。

1个在“闲逛”时提的问题

在成为Scrum Master后,我花了更多时间在交流上,这就是传统的走动式管理。

举例来说:如果我看到程序员和测试员在进行一场重要的谈话,我可能会走过去听他们在说什么,因为也许我能给他们提供一些帮助。(当然了,不要每次都走过去,尤其是他们看起来是在讨论私事的时候)。

有时候我听得到的讨论可能是对其他人有价值的,比如:我认为一个技术作者,应该了解程序员和测试员会怎样做决定。

所以我会问:有其他人需要知道这件事吗?

如果答案是肯定的,那我会尽量找一个人将这些信息分享出去。

1个在每日站会时提的问题

在每日站会中,我会去关注团队的燃尽图,并思考他们怎样在sprint结束时完成所有计划。但是,当我问同一个团队他们是否能完成所有事情时,答案通常是肯定的。

如果我认为他们的预测不现实,我会看着燃尽图并且问道:你知道我想了解的是什么吗?

我可能会得到这样的答复:有成员没有更新自己的工时。或者有人会解释说:他们的进度目前的确有点落后,但是他们已经学会了很多东西而且马上就会提速赶上。(我发现这种说法很少实现,因为我经常听到这样说)。

也许他们认为正在加快速度,但我不是这样想的,这是个发现不同假设的问题。

总结

提问比陈述更能说明问题

在我才刚开始成为Scrum Master,还没有发现提问的作用时,我经常错过了解团队和他们工作内容的机会。直到我发现了提问并认真听取答案是学习的最佳途径。

希望你也像我一样发现这些问题的作用!

 

原文链接:https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking

本文由@行动派小助手 翻译发布于人人都是产品经理,未经许可,禁止转载。

题图来自UNplash,基于cc0协议

评论
欢迎留言讨论~!
  1. 学习了

    回复
圈子
关注微信公众号
大家都在问