前沿拓展：scum女性服装代码
本文根据电子书《Scrum-Master-Interview-Questions-4th-Edition-2018-by-Age-of-Product
》由“一起学敏捷”翻译而来，仅用于学习用，翻译可能有不当之处请自行甄别。春节没回家从大年三十一直熬到早晨忙着翻译，欢迎一起交流学习，关注号"一起学敏捷"。
这不只是问题，每一个问题就是一个真实场景；每一个答案，就是解决现实中遇到问题的技巧；学习38问不是为了面试找工作，而是通过38个问题掌握scrum框架，间接的学到处理问题的经验技巧。
Scrum Master面试38问
一、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帮助，以更好地应对大量想法，建议和要求。小的待办项可以避免不当的分配资源；大的待办项意味着浪费。
候选人应该明确的表明他们将支持产品经理进行待办项的规模的管理，并且处理来自干系人的输入。
三、Sprint计划1. 背景知识点产品经理在sprint计划期间将会向scrum团队解释产品待办项中的高价值用户故事，然后，团队将这些内容转换为更详细的用户故事，并估算一连串故事。但是，敏捷从业者之间已经达成共识，即在单独的待办事项提炼和评估会议中处理这些高级用户故事——在sprint计划会之前-实际上可以提高故事质量，从而提高团队工作成果。
Sprint计划可以使Scrum团队成员对sprint待办事项中的项目做出有承诺，从而营造一种主人翁感， 但这只有在消除了团队对他们收到的用户故事性质的不确定性之后，才会发生。为了确定他们的团队可以确定的，Scrum master应该每周进行产品待办项细化和估算会议， 只允许在冲刺计划中满足团队对就绪的标准定义的用户故事。
Sprint计划会通常应该分成两场：
Sprint计划I：在Sprint计划的第一场，产品经理向scrum团队介绍其从产品待办项选出的有价值的用户故事并排序成表，团队从列表的顶部往下选择他们承诺可以在sprint结束时完成的故事——考虑他们当前的制约因素，例如可用的生产率，在同一次Sprint中需要解决的必需技术任务。
Sprint计划II：在Sprint的第二场，scrum团队对sprint代办项的故事增加详细的描述(例如，把用户故事分成任务，辨认出那些故事需要进一步澄清，同意谁将从事哪些任务)。产品经理并非必须参加第二场sprint计划会，但是需要回答团队可能遇到的问题。
如果用户故事准备工作处理得当，则整个Sprint计划会话可能会在2到3个小时内完成。
高的sprint计划需要一个健康的Scrum团队, 功能缺失的团队将无法达到所需的合作水平，功能缺失的团队的sprint计划只会导致无用和痛苦的活动。
Scrum团队通常应避免将其能力的80％以上分配给新任务-包括用户案例，技术任务，bug以及可能的峰值， 流理论表明，可用容量的90％或更高分配不会导致团队达到高绩。
Bug、重构和研究需要定期关注，以避免积累技术债务，一个高的scrum团队至少会将容量的25%分配给这些任务。
准备不完整的和不好的用户故事严重的阻碍scrum团队的率，这样的故事坚决不能选在sprint待办项，而应在待办项细化和估算会期间进行整理。
2. 问答问题 18
Scrum master如何以使Scrum团队仅处理有价值的用户故事的方式为Sprint计划做出贡献？
通过在产品待办项中确定有价值的用户故事并对其进行排序来定义即将开始的sprint范围是产品经理的特权。在此过程中支持产品经理是scrum master的职责。
因此，对于scrum master来说，团队为有价值的用户故事工作的好的方式是：
1) scrum团队在起初阶段参与产品的需求过程。
2) scrum 团队和产品经理都能更好的理解产品待办项细化的过程(例如，应该通过为用户故事创建就绪规范的定义来支持这一点)。
3) 所有的用户故事的创建是产品经理和scrum团队共同协作的结果(其目的是对用户故事有共同的理解，从而共同拥有)。
候选人应该注意到尽管产品经理定义sprint范围和sprint目标，但在这个sprint期间，scrum团队有权解决技术债务和bugs(团队应当分配其25%的容量用在此事)。
问题 19
你使用什么指标评估用户故事的价值？
有定量和定性的度量方法可用于来评估用户故事的价值或投资是否值得，包含下面几个方面：
1)收入增加
2)成本消减得益于内部流程的改进
3)提高客户的满意度
4)增加新产品的签约
5)客户服务团队收到客户积极的反馈
问题 20
你如何以选择有价值的用户故事，用这种方式促进用户故事的选择，而又不会推翻Scrum团队定义自己的承诺的特权？
如果scrum团队足够早的参与用户故事的选择 (好与产品负责人共同创建故事)，或者产品需求，scrum master也许对选择有价值用户故事的选择不需要提供指导，团队将会支持产品经理选择特定sprint的用户故事。
在sprint计划期间，如果团队采取了挑剔(cherry picking)——仅选择个人偏好的用户故事，这样的话，待办项细化过程需要严格的检查， 因为产品经理极有可能选择的用户故事并没有使客户价值大化。
问题 21
你认为在常规sprint期间Scrum团队的容量是多少才足以进行重构？修订重要bug？探索新技术或新想法 ？
除了冲刺之外，还有一些严重而紧迫的任务需要解决(例如，修复已经出现的网站掉线问题)，一个好的法则是15-10-5分配scrum团队的容量来重构、修复和探索新知识。具体的说，这意味着：
1)15%的团队容积用于技术债
2)10%的团队容积用于修复bug
3)5%的团队容积用作探索
当涉及到个别冲刺时，Scrum团队当然可能会偏离这一点，但是，通常一贯地做这样的分配能够满足大多数应用程序代码质量和维护要求。
问题 22
产品经理能否向scrum团队的成员分配用户故事或任务？
产品经理向scrum团队成员分派用户故事是伪敏捷，如果产品经理有这种行为需要停止，因为scrum团队是一个自组织团队，scrum 团队成员之间分配用户故事或者指派任务是scrum团队自己的权利。制止这种错误行为是scrum master紧迫问题之一。
问题23
你怎样处理团队成员挑剔任务的行为？
Scrum团队在其成员选择分配任务的方式上具有自主权，因此，假设团队成员对任务的挑剔实际上可能是团队绩途径中的有价值的重要组成部分。然而，如果团队成员抱怨其他人如何选择任务，Scrum主管需要解决该问题。额外的培训可能会帮助一些团队成员完成更多的任务，或者，也许其他的团队成员需要悄悄的离开他们的舒适区域，以便他们能更乐意的选择他们不同类型的任务，而不是他们习惯的任务。
问题 24
用户故事缺少终的用户界面设计，但设计团队承诺在即将到来的sprint的第二天交付，团队的产品经理对此感到满意，并促使把此用户故事添加到sprint代办项。你对这个情景有什么看法？
是否应将不完整的用户故事添加到sprint待办事项中，取决于团队目前的关注和经验，这种情形将会导致故事无法满足他们对就绪的定义的情况。例如，在用户界面（UI）设计不完整或缺失的情况下，如果设计团队几乎可以肯定会交付，因为他们过去曾这样做过，并且用户故事具有很高的价值， 尽管UI交付迟到，但故事仍要在sprint中完成，如果团队同意这样做，那么可以接受例外情况。
谨防这种例外变成为公认惯例的趋势，有敏捷意向的组织不应该绕过待办项的细化和sprint计划过程。候选人应当意识到这种情形是不能站得住脚的，此外，如果执行这样的例外的用户故事将会遭受失败，此时，没有人会花费时间去阅读细则并承认已经做出例外，相反地，他们极有可能会敏捷的过程本身视为失败的原因。
候选人也许可以接受或者拒绝敏捷过程的例外，但他们应该能够分析产生这种例外的情况，并解释scrum团队可能遭受的附加破坏。
问题 25
一名成员Scrum团队中不想参与print计划会，并且认为开会是浪费时间。你怎样处理这种态度？
如果一名成员Scrum团队中不想参与print计划会，并且认为开会是浪费时间，他们表现出一种消极的攻击性行为。尽管并非只针对Scrum，但这是一个问题，因为基本的态度有毒，会影响团队建设和团队绩。
当Scrum团队成员的行为符合描述时，scrum master需要采取行动，如果团队要继续运作，适得其反的行为既不能忽略也不容忍。有的行动可能需要一系列逐步升级的步骤：
1) Scrum管理员应首先私下与团队成员交谈以讨论他们的保留意见，并可能需要更多的教练或更长的培训时间。
2) 私下讨论后，通过将团队成员的保留作为一个或多个回顾期间的讨论主题，可以使整个团队参与进来，从而使团队提供他们的支持。
3) 如果仍然不能改变团队成员的态度，建议团队成员与职能经理开会。
4) 如果仍然没有任何改变，则有可能将团队成员重新分配给另一个团队，迫使团队成员走出他们的舒适区。
四、每日站会1.背景知识点站会又叫每日scrum会，适用于讨论当前的sprint进展：是否一切都按计划进行，还是需要Scrum团队调整？
每日站会是scrum团队和项目干系人会面和交流的便利时间。
站立无法解决的问题包括：组织失调，Scrum团队失调，不充分的产品待办项，sprint计划会议出了错，低质量的用户故事或缺失产品愿景。
如果Scrum团队已经很好地进行了协作，并且已经准备好了产品待办项和sprint计划等基础工作，那么每日站会就很有价值。
当Scrum团队经验越丰富，内部沟通越好，每日站会似乎是一项耗时，价值不高的仪式。
高级Scrum团队可以考虑使用虚拟会议，而不是使用松散的实际会议。
两个人的Scrum团队没必要进行正式的站立，利用-喝咖啡时间碰面将是一种实际的选择。
Scrum团队出了点问题，他们在每次站起来之前都没有与他们的Scrum主管沟通障碍，这样的团队很可能看起来更像是一组朋友而不是一个scrum团队。
每日站会不是对产品经理或者参会的干系人的报告会。
线下的物理板是非诚有价值的：亲身拿卡片和移动卡片灌输了对故事卡片的一种所有权。
2. 问答问题26
无论规模或经验水平，你会为所有团队推荐正式的站会吗？
在回答这个问题时，候选人应表现出关于正式站立的常识，站会是scrum的重要组成部分，但并不是所有的站会都需要正式的会，一个小的、经验丰富的、和坐在一起办公的团队可以利用他们的咖啡休息时间来开展站会。
但是，对于拥有几个初级成员的大型团队，采用一种轻松，非正式的方式进行站起来，可能不会取得任何成就-如果它首先不会陷入混乱。 对于大型团队，需要召开正式会议以提供格式和指导。
对于很难在一起喝咖啡碰面的分布式团队，进行正式的站立以适应技术限制很有必要，并且必须以有组织的方式安排和进行。
问题 27
您是否希望经验丰富的团队成员等到下一次站起来才能寻求帮助来克服障碍？
当障碍出现时，scrum团队成员千万不要等到到下一个站会或者其他任何会议才寻求帮助。等待寻求帮助的团队就是拖延进度的团队。富有经验的scrum团队在等待下一个站会前先寻求帮助或者自行解决障碍，这需要scrum master事先做好团队建设的工作。
问题 28
你如何处理将站会变成自己的报告会议的团队成员？
Scrum中没有正式的领导角色，但是，一些Scrum团队的某些成员担任领导职位并不少见，这种情况通常发生在特定的团队成员具有卓越的专业知识、沟通技能，或只是更大程度的参与。
所有团队都经历了塔克曼小组发展的各个阶段：组建，动荡，规范和执行。 Scrum团队也不例外
重要的是，当Scrum团队的成员担任领导职务时，不要导致导致其他成员向他们报告。Scrum master 必须保持警惕并在必要时进行干预，以所有团队成员本着Scrum的精神沟通和一起工作（在站立时或其他情况下）
问题 29
你如何管理团队成员，他们认为站会浪费时间，因此要么迟到，不合作，要么干脆不参加？
参考问题25，详细讨论了解决类似态度和行为问题的步骤。候选人的回答要点和问题25相同。
问题 30
没有干系人参与团队的站会，你怎样改变这种情况？
提出这个问题很容易引发关于是否应允许干系人参加Scrum团队的站会口水战，尽量避免这种情况。
如果利益相关者参与团队的站立，是否有可能导致某种形式的报告规避混乱规则？不一定，可以对Scrum进行一些调整以使其适用于组织是很好的，如果团队认为可以接受，则无需排除允干系人参与站会。事实上，如果干系人经常参加站会，这总是显著的改良了团队和干系人之间的沟通。
那么scrum master怎样鼓励干系人参与站会呢？scrum master可以有多种方式来实现：例如，他们可以给干系人提供学习新产品或特性的早期详细信息的机会，或者可以选择给干系人直接向工程师提问的机会(不需要通过产品经理)。
问题 31
你怎样与分布的团队开站会？
scrum团队成员分散在不同办公室或者远程工作的团队和在一起办公的团队的站会没有太大的不同。的例外在于，如果团队使用线下的物理板，共享板活动时需要借助视频会议互相反映。
如果scrum团队使用的在线任务管理或者像Jira一样的计划软件，团队的板可以在线或者通过屏幕更新，这通常使得分布式团队看板活动更加容易，有了在线板，通过网络视频电话足够让分布式团队开展站会了。
问题 32
你们立即画出scrum团队的物理kanban示例图吗？
在这个问题中，合格的kanban是个难题，但每个应试者的角色是scum master应当能画出简单的物理kanban。物理看板通常有五列：
1)待办项
2)进行中
3)代码评审
4)质量
5)完成
额外的一些信息可以包含或附加到线上或者物理板上，例如：
1)Sprint或开会日期
2)用户可接受的测试
3)就绪的定义
4)燃尽图
5)停车场（未来讨论的主题）
候选人应该提及scrum master 没有义务向Scrum团队提供离线物理板，但是，如果团队中没有人熟悉离线的物理板，scrum master应该提供有关该主题的工作坊式的介绍。
五、回顾会1.背景知识点回顾应该鼓励自我表达，从而使Scrum团队更容易发现其成员可能存在的担忧和挫折感，从而可以制定克服这些担忧的策略。
只有当团队认为这些会议是提供诚实和建设性反馈的场所时，回顾会议才能改良团队的协作和绩
责备是没有帮助， 在回顾期间，Scrum团队的成员应集中精力于如何改良情况，并避免互相指责。
一些Scrum团队总是将产品经理包括在回顾中，而其他团队则坚持应明确邀请产品所有者。
好不要在团队的工作场所举行回顾，距离更容易使团队成员思考sprint, 经常的更换开会场所是很有帮助的，在新的环境有助于防止厌烦。
Scrum团队的回顾个税应该经常得改变，相同格式的运行次数不应超过两次。
回顾中不应允许使用智能手机，平板电脑和笔记本电脑，以使Scrum团队的成员不会分心，而可以专注于为会议做贡献。
所有问题，疑虑和挫败感都应记录在案-即使只是暂时使用便签纸。 好保留正式的文档或文件。
回顾总要为特定的问题产生答案，"经典"问题集包括：
1)过去那些是做的好的？
2)过去那些是是做的不好的？
3)那些是将来需要修改的？
可代替的一组问题是"海星"回顾：
1)采用什么？2)保持做什么？
3)停止做什么？
4)该做什么？
5)不该做什么？
在回顾提问的一种替代方法是采用Mad Sad Glad技术。 在以下任一情况下，此技术果佳：
1)间隔很长（例如，在年末）
2)重大变化
3)重大缺陷
4)异常压力
5)团队取得的突出的成就
根据戴安娜·拉尔森（Diana Larsen）和埃斯特·德比（Esther Derby）在他们的《敏捷回顾：使团队从到卓越》中的书，进行回顾需要五个阶段：准备阶段，收集数据，产生见解，决定做什么并结束回顾。
回顾应为行动项目（要完成的任务）设定SMART目标：
1)行动的事项是具体的和可测量的
2)每个行动项目都应由Scrum团队的一名成员负责
3)每个行动项目应包括何时可以产生预期的估计。
4)应将操作项放在板上，以使跟踪进度更加直观和突出。
5)每个新的回顾都应从评审上一次回顾中决定的行动项目的状态开始。
问题 33
谁应该参加回顾？
只有Scrum团队的直属成员才能参加该团队的回顾，尤其重要的是，团队成员的经理是不能参加回顾的。
产品经理是的例外，通常将产品经理纳入scrum团队的回顾是一个好的注意，因为产品经理是大团队的一个重要成员。但并不是强制的，有些团队可能希望产品负责人不参加–必须始终考虑团队的意愿。
问题 34
你应该在回顾期间检查团队的健康状况，还是没有必要这样做？ 如果这样做，您将如何处理？
测量Scrum团队的健康状况-即了解当前的敬业度和满意度水平-对于确定可能影响生产力的趋势很有用。
测量scrum团队健康的一个有方法是在团队回顾中发放多项选择的调查表，只需两分钟即可完成并针对每个问题使用简单衡量的问卷，例如：
1)糟糕的
2)差劲的
3)中立的
4)的
5)杰出的
在回顾期间，团队在完成问卷调查后应讨论结果，以发现他们可能怀有的任何疑虑或沮丧。
问题35
你过去使用过那些回顾的格式？
通常有很多种回顾的格式，并且每个都是为了适应不同的情况，如果候选人有应用过这些格式中多于一种的经验，并且应该能够分享这样做的逻辑。
1)经典格式
那些是我们做的好的？
那些是我们做的更好的？
2)小船型格式
那些是推动我们前进的？
那些是使我们退缩的？
3)海星型回顾
开始做….
少做….
多做….
停止做….
继续做….
4)戴安娜·拉森和埃丝特·德比模式
设置舞台
收集数据
产生见解
决定做什么
关闭回顾
问题 36
你怎样防止回顾期间无聊？
当需要参加无聊的回顾时，Scrum团队的成员会变得无聊。
有很多变化的可选方法能够防止回顾乏味，和团队成员变得无聊。不同的位置，不同的格式以及缩短或延长分配的时间盒正是可以尝试的一些变体。Scrum master 可能还会使用团队选择的行动条目来鼓励和组织讨论有关团队的重要问题，从而通过认可创建参与度。诸如Retromat之类的网站提供了数百种不同的游戏和练习，使回顾对于整个团队来说都是愉快而有价值的。
对于无聊这个问题，没有单一的解决方案，因此也没有单一的正确答案。重要的是，候选人意识到常规的无聊可能会成为一个问题，并且有多种方法可以解决它。
问题 37
如果你的团队选择了合理的任务条目而不是交付，你将如何解决这种情况？
在回顾期间，scrum团队通常希望认领一系列行动条目（要做的任务），但后来如果这些任务条目并没有及时的完成，此时scrum aster需要跟进。
由于受到外部的障碍，团队有时可能无法完成他们认领的任务，如果是这种情况，scrum master必须解决问题，并且团队需要在接下来的sprint期间赶上。Raner，如果不是外部障碍，这种情况很可能是团队的动机，态度和个人问题造成的，。如果是后者，scrum master 需要的向有问题的团队成员提供足够的鼓励或动力来克服问题-然后看到他们兑现了自己的承诺。
如果团队不能完成他们认领的任务，而且这个问题终不能够解决，那么认领任务就变成了一个没有意义的活动，团队而因此蒙受辛苦而出不了成绩。
问题 38
Scrum master怎样建议跟进认领的工作？
Scrum master希望跟进scrum团队成员在回顾期间认领的任务，scrum master跟进的一个好方式是在每个新的回顾认领新任务前先开始讨论上一个回顾会上团队成员认领的任务的状态。如果讨论发现上一个回顾上认领的任务没有按预期完成，如果需要弄明白为什么完成，防止下次再出现类似的问题。
拓展知识：scum女性服装代码
预约医院医生
咨询整形价格
免费评估报价