三、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跟进的一个好方式是在每个新的回顾认领新任务前先开始讨论上一个回顾会上团队成员认领的任务的状态。如果讨论发现上一个回顾上认领的任务没有按预期完成，如果需要弄明白为什么完成，防止下次再出现类似的问题。
粤公网安备 44010602010970