Scrum Master面试38问(一)

Scrum Master面试38问-第四版    

Scrum-Master-Interview-Questions-4th-Edition-2018-by-Age-of-Product  

本文根据电子书《Scrum-Master-Interview-Questions-4th-Edition-2018-by-Age-of-Product》由南天亮翻译而来，仅用于学习，翻译可能有不当之处请自行甄别。欢迎一起交流学习，可以关注头条号”一起学敏捷”。Email:381281541@163.com 

这不只是问题，每一个问题就是一个真实场景；每一个答案，就是解决现实中遇到问题的技巧；学习38问不是为了面试找工作，而是通过38个问题掌握scrum框架，间接的学到处理问题的经验技巧。  

一、Scrum Master的角色

1. 知识点背景

1) Scrum 不是方法学，而是一个框架。没有适用于每一种情景的规则，只有其他工作组以前曾经采用过的最佳实践。

其他组的最佳实践不能简单的拷贝到自己组使用，每个组的最佳实践只有在特定的环境下才能正常工作。

2)Scrum团队是一个敏捷团队，当有人为敏捷团队招聘时，你需要自己确定团队有什么样的工作，这是过程，而不是目标。

3)Scrum Master的主要角色是领导力和教练中其一，并不是管理层角色。

4)Scrum Master应当认识到scrum 团队开发的不同阶段需要不同的方法：有时需要训练，有时需要教练，有时需要导师。

5)Scrum Master应当很熟悉学习新技术的Shu-Ha-Ri方法。

6)Scrum Master的主要目标应该是通过使Scrum团队能够自我组织和自我管理，使自己摆脱日常运营。

7)作为Scrum Master不一定要强制执行流程。

8)Scrum 并不是bean 计数器，尽管某些指标在理解scrum团队健康时很有用。通常，坚持让团队达到特定的KPI并不起作用。

9)Scrum没有详细说你使产品经理对产品化代办列表添加有价值的，用用的和可行的用户故事的过程。使用设计思维，精益启动或精益UX方法进行产品发现也许是有帮助的，但无论如何，优秀的Scrum管理员都会希望Scrum团队成为这个过程的一部分。

10)Scrum 团队和干系人的沟通不应该通过如产品经理这个的守门人来进行，因为这样会破坏透明性，消极地影响团队的能力和效率。相反，Sprint审核是与干系人保持密切联系并展示团队在先前每个Sprint中交付的价值的好方法。

2. 问答

问题01

敏捷宣言里隐射出人胜于过程，是不是Scrum Master（其角色旨在执行该过程）因此是矛盾的吗？

Scrum Master并没有执掌任何真实的权利，Scrum团队也不会向其报告。这个问题的目的是帮助揭示您的候选人是否理解他们的角色是领导团队而不是管理团队，提出这个问题首先也很可能揭示您的候选人为什么对ScrumMaster的角色感兴趣。

可接受的答案应强调促进和支持：

1)我是scrum 团队对的促进者，我的工作是使他们成功。

2)我既不是项目经理，也不是人事经理，我是支持scrum 团队实现自我管理，我并不会告诉团队要做什么。

3)我是scrum团队的促进者，充当着老师，教练或者导师，鼓励他们成为一个优秀的敏捷团队。

问题02

有哪些可能的指标表明敏捷实践对您的组织有效，以及哪些将证明您在敏捷方面的努力是成功的？

没有“敏捷成功”的标准或一般定义可用于衡量组织的敏捷性，每个组织必要开发自己标准。团队的成长速度通常不被认为是一个有效的指标。

然而，尽管大多数情况是间接的，但仍有各种指标可能对确定成功是有用的：

1)通过减少流失和增加成员推荐数量可以提高团队的幸福感。

2)通过有经验的人愿意加入组织的增长数量来证明人才争夺的竞争力。

3)交付给客户的产品产生更高的保有率，更好的转换率，提高生命周期价值，并对业务进行类似的改进。

4)通过减少可衡量的技术债务，更少的bug，更少的维护时间来提升软件的质量。

5)从验证想法到发布产品的生产时间已缩短。

6)对假设的验证周期已经缩短。

7)对低价值的产品减少资源的分配。

8)干系人对IT团队有更高的尊重。

9)利益相关者越来越多地参加敏捷会议，尤其是在冲洗demo演示期间。

问题03

Scrum管理员是否应该代表Scrum团队消除障碍？

Scrum Master不应该关心“代表scrum团队消除障碍”，不管在招聘广告中多么频繁的提到这样的要求。如果一个scrum Master扮演的是scrum 妈妈的角色，那么他们的团队永远不会实现自组织。

Scrum团队必须自己做决定。当团队学习新知识时，这几乎不可避免地导致失败，死胡同以及其他计划外的工作。因此，一开始，团队将需要Scrum主管比平时更多的指导，而这与物理板绘制或Jira卡片更新是不同的。但是，这种指导不应成为保护性养育的一种练习，必须让团队从失败中吸取教训。

问题 04

Scrum Master和产品经理以什么样的方式及交流？

Scrum Master想获得产品经理的协作的最好方式是真诚的和公开的交流。两者都必须充当领导者而不要具有权威性，并且每个人都相互依靠对方来确保Scrum团队的成功，他们与尊重指导组织变得敏捷，并且保持敏捷结盟。

产品经理的责任是快速提供来自市场的反馈，澄清需求，并且确保整个交付团队能理解产品的愿景。

作为Scrum Master，作为回报支持产品所有者建立高价值的产品待办清单，因此，必要促进产品经理和scrum团队之间有效的协作。

问题05

Scrum团队是否应该参与产品需求收集过程？如果是，如何进行？

有两个主要的原因，为什么scrum Master应该尽可能早的参与产品需求过程：

1）工程师越早参与产品需求过程，如果参与的越晚，寻求在技术上不可行或不会导致投资回报的解决方案的机会越少。

2）尽早让Scrum团队参与进来，可确保团队及其产品所有者对将要构建的内容形成共识和所有权，这将极大地有助于将资源分配给正确的问题，为客户创造最大价值，并降低投资风险。

Scrum团队的工程师在过程的早起参与进来以确保他们开发需要买入的设备，工具和开发环境等需求，并且团队愿意参与产品开发的所有阶段。这将激励团队当在为了实现定义的每个冲刺目标或产品交付而必须做出改变时参与。

问题 06

产品经理的角色是设计的障碍，你怎样支持产品经理以使价值最大化？

这个问题重温了前面的问题，作为scrum Master的候选人，你必须聚焦在为什么scrum团队尽早的参与产品的需求阶段对产品经理和组织都是有好处的，本质上，团队要么一起赢，要么一起输。

问题07

你怎样确保scrum团队接近产品的干系人？

在回答这个问题时，作为候选人应该解释没有容易的方式确保团队接近干系人。作为候选人也许会建议鼓励干系人采用高效,透明，有用的交流方式。冲洗评审是对交流来说一个非常有用的会场，并且互动通常可以促进不同部门和业务部门之间的更好关系。

问题08

您如何在部门范围内和整个组织内以及在追求中促进敏捷思维,为此，指导不熟悉IT的干系人时你的策略是什么？

有多种策略scrum Master可以用来鼓励干系人参与scrum：

1)Scrum Master应该当场宣读敏捷宣言的原则，这一点非常重要。他们应该与参与产品开发的组织中的每个人交谈，并且对他们所做的工作保持透明。

2)产品和开发团队可以通过演示或其他方式提供展示，在演示文稿或其他方面，向利益相关者证明，从构思到产品发布的交付，scrum显著的较少了产品的交货时间。

3)产品和开发团队可以论证Scrum可以减轻风险（即预测何时可以提供新功能），从而有助于其他部门在计划和执行方面取得成功。

4)Scrum团队可以透明地尊重他们的工作，并通过邀请利益相关者参加会议来积极参与会议，冲刺评审，和其他一些团队交流活动或进展的相关事件。

5)培训组织中的每一个人，尤其是培训干系人显得很重要。一种实践方法是组织研讨会，旨在为非技术同事教授敏捷技术。

问题09

你怎样向高级管理层介绍scrum?

这是一个故意设置的开放式问题，意在鼓励讨论。在回答这个问题的时候，您的候选人应详细说明如何在整个组织中传播敏捷的思维方式，或者更理想地，更具体地说，是如何创建一个包含实验的学习型组织，以便为其客户确定最佳产品。

一个好的候选人可能会讨论为了赢得干系人的认可向组织推销敏捷的重要性。在转变的开始，所有的组织都会对改变表现出惰性，所以要战胜这些抵抗的高管和干系人需要在他们做出承诺之前，让他们知道敏捷将如何让他们受益。

向高级管理人员介绍Scrum时，一种实用的方法是组织C级管理层组织一个研讨会，如果组织scrum团队，则高管、甚至潜在的董事都可以获得有关敏捷方法的直接经验。

这个问题没有正确或者错误答案，最佳做法需要考虑组织的文化，规模，产品成熟度，法律和合规性要求，以及组织所在的行业。

问题10

你已经经为项目的干系人提供了scrum的培训，当在尝试应用scrum观念的初始阶段之后，遇到第一个障碍时一些干系人开始抵制继续采用，您在处理这种情况的策略和经验是什么？

这个问题的目的是鼓励人们就克服组织内部对敏捷的抵抗力时交流思想和汲取的经验教训。熟悉许多组织常见的敏捷失败模型能够证实候选人的经验。您的候选人还应该熟悉中层管理人员在向敏捷实践转变时面临的特殊挑战， 从命令和控制风格转变成服务型领导风格，因此放弃泰勒的原则-并不适合所有人。

二、待办项的改进和估算

1. 背景知识点

虽然产品经理掌管产品待办项以交付最大价值，但他们需整个团队的帮助，于是对每个scrum团队来说，估算和待办项改进是极其重要的任务。

跨职能且在一起办公的Scrum团队独立于其他团队工作是理想的方案，现实中许多scrum团队经常依赖于其他团队的发布（如API 端），以及UX或UI部门的发布。

良好的scrum 团队表现有两个基本要素：

01 整个团队编写用户故事。当要构建某产品时，产品经理首先需要解释为什么要做此产品，并且提供必要的背景（例如. 市场情报，实验结果，用户访谈，统计数据）. 因此，编写用户故事是整个Scrum团队的一项相应的协作工作，该过程应该团队对将要构建的内容以及原因有了解(产品经理提供为什么做，scrum团队详述怎么做，共同定义做什么)，并且分享团队成员的主人翁意识。

02 达成就绪的定义。为了确保开发过程中精心编写的用户故事流程，scrum团队和产品经理需要对用户故事就绪的定义达成一致。此定义是关于需要为用户故事提供哪些内容以使其准备好进行评估的约定。如果甚至没有满足所定义的要求之一，则用户故事还无法评估。没有前期估算的用户故事是一个未知实体，因此，不能当做冲刺待办项的一部分，因为scrum团队不能对冲刺中的一个未知实体做出承诺，所以，scrum团队必须学会说”No”。

梳理整洁的产品代办项很可能有对2到3个冲刺的详细的用户故事，并且这些故事中可能只有不到一半符合Scrum团队对“准备就绪”的定义。可能还有其他的用户故事，在这一刻，除了产品经理，没有人在从事此工作。

2. 问答

问题 11

产品负责人向scrum团队经常将从利益相关者那里收到的需求文档转换为故事卡片，并要求你对其进行估算。 你对此程序感觉如何？

产品经理从不应该把从干系人哪里收到的文档转换成故事卡片，scrum Master决不能接受这种流程。这是用伪敏捷方法来掩饰瀑布方法。

如果组织应该专注于为客户提供价值，则必须放弃由项目经理将涉及“要求”的任何流程下放给工程师的过程， 如果项目经理冒充产品所有者，则没有任何区别， 相反，组织应开始将每个人都包括在产品需求过程中， 从而确保对需要构建的内容有共同的看法。

问题 12

您需要产品负责人提供什么样的信息，以便为您的团队提供有关产品和市场情况的最新信息？

Scrum master可能需要产品经理在更新其产品团队时所需要的信息，或者市场对该产品的反应，这些信息可能包括任何可以使Scrum团队了解为什么某些东西对客户有价值的信息。这些信息可能具有定性的性质(例如，描述如何利用流程的分析数据或用户测试会话中的成报告单，截屏视频或视频)。

对于你的候选人而言，一个很好的建议是让Scrum团队通过参与用户访谈来参与收集定性信号。

问题 13

谁应当编写用户故事？

编写用户故事应该是Scrum团队所有成员的共同努力， 如果不是，团队可能不会觉得自己拥有故事的所有权，不可避免地导致团队成员少承诺，或者不承诺，动力减少，最终导致产品质量降低。

问题14

好的用户故事是什么样的？它的结构是什么样的？

好的用户故事应当具备以下特征：

1)包含描述

2)具有可接受标准定义

3)能够在单个冲刺中交付

4)具有所有可用的UI交付物

5)具有所有（可能的）依赖项确认

6)具有性能标准的定义

7)具有跟踪标准的定义

8)是整个scrum 团队估算的

问题 15

就绪的定义应包括什么？

“准备就绪”是Scrum团队和产品所有者之间就用户故事中必须包含的内容达成的协议（在可以将故事视为准备好进行评估之前）。 它定义了一个好的用户故事应该是什么样的。

第14个问题已经含括了一个好的用户故事应该包含哪些信息的大纲，另一种方法是对用户故事使用框架，例如INVEST mnemonic Bill Wake的助记符：

1)独立的——用户故事应当是自包含的，没有对其他故事内在的依赖。

2)流通的——在成为冲刺迭代的一部分之前，用户故事始终可以更改和重写的。

3)有价值的——用户故事对终端用户必须带来价值。

4)可估算的——必须能够估算用户故事的大小。

5)小——用户故事不应太大而无法确定，计划，确定任务和确定优先次序。

6)可测试的—— 用户故事（或其相关描述）必须提供必要的信息以使测试开发成为可能。

问题 16

为什么不能简单按工时估算用户故事？

以人-小时的方式估算用户故事向来不是一个好的注意。它有意地将重点从估算过程的真正目的转移了：在Scrum团队的所有成员之间建立对未来任务的共识。因此，估算本身只是副产品。

当在下面几种情形，估算通常是棘手的：

1)涉及遗留软件。

2)团队面临巨大的技术债务。

3)一个团队主要由初级成员组成。

在所有情况下，故事点都比工时更适合估算，尤其是在棘手的情况下，因为它们可以准确地反映出任务的复杂性和完成任务所需的精力。用工时代替故事点来估算典型的把注意力从对用户创造的价值转向传统的成本和预算项目管理，实际上实施了瀑布式流程。

问题 17

你的Scrum团队的产品负经理倾向于将各种想法添加到产品待办事项列表中，工作下一个阶段工作的提醒，随着时间的累积，导致在过个阶段累积了200多个卡片，你对这种情况有什么想法？一个scrum团队能够从事200个故事卡吗？

任何一个产品的待办项大于2到3个冲刺的范围是无法管理的，滥用产品待办项增加了上百个条目，这个明确的信号表明产品经理需要来自scrum团队或scrum master帮助，以更好地应对大量想法，建议和要求。小的待办项可以避免不当的分配资源；大的待办项意味着浪费。

候选人应该明确的表明他们将支持产品经理进行待办项的规模的管理，并且处理来自干系人的输入。

未完，待续....