Skip to content

2019-12-22 冲刺计划会

4094 字
   

谁?

整个Scrum团队。

请注意,这是一个活跃的、协作的仪式。人们可以飞来飞去查找东西,或者在需要时进行小规模验证。开发团队可以要求其他人提供帮助。会议期间可以主动收集更多信息。

“开发团队还可以邀请其他人参加以提供技术或领域建议。” — Scrum指南

参与

并非每个成员在参加活动时都会积极主动和富有创造力。有些成员只有在感到自信或感到自在时才会跳出来。

Scrum Master 可能会认为每个人都有参加和参与的责任。确实,糟糕的出勤率和参与度低会降低透明度并带来风险。然而,

“ Scrum Master确保活动能够进行,并且参与者了解其目的。” — Scrum指南

我认为,解释出勤和参与的价值,同时创造一个舒适、愉悦、平静和尊重的环境,是Scrum Master激励团队成员参与的最佳方法。

“为他们提供所需的环境和支持,并相信他们能够完成工作。” —敏捷宣言。

有时,参与者可能会占据主导地位,并试图利用这一事件来指导和影响团队的方向。此输入可能非常有价值,但可能会阻止其他人添加其宝贵的输入。参与者应注意这一点。无论如何,我相信当团队成员不尊重甚至敌对时,Scrum Master应该介入。一个团队将视Scrum Master为教练,以保护环境安全。

何时?

冲刺的开始。

这实际上很难回答。《 Scrum指南》里面没有明确的定义,即必须在开始时进行Sprint计划。实际上,如果准确解释,则在冲刺计划期间,要做的工作是规划即将到来的冲刺,而不是当前或本次冲刺,也不是安排下一个冲刺要做什么具体的工作类型。请记住,把冲刺作为充当仪式的容器冲刺计划会并不是发生在两次冲刺期间,而冲刺计划会是一个冲刺的第一个仪式,冲刺是一个接着一个的发生。

Scrum指南通过告诉我们在何时取消某个冲刺,为我们提供了一点提示,

“每个人都在另一个冲刺计划中重组,以开始另一个冲刺” —《 Scrum指南》。

幸运的是,Scrum.org的Scrum词汇表更为具体:

“ 冲刺计划会:定时活动[..],以开始某个冲刺。” — Scrum词汇表 “Sprint Planning: time-boxed event [..], to start a Sprint.” — Scrum Glossary

团队在产品积压表梳理期间准备冲刺计划,其实很常见。无论如何,冲刺计划应该在相同的时间和相同的地方开始。必须准时开始。

多久?

对于冲刺周期为一个月的冲刺,最长时间为8小时。如果冲刺的持续时间更短,则会议的持续时间也更短。

对于团队实际情况,冲刺的持续时间越少,相对的冲刺计划时间也会正常的减少。持续一星期的冲刺,可能冲刺计划会只要2小时。请记住,这是最大时间,不存在最小时间。经验丰富的团队可能在预设的时间耗尽之前就完成所需的内容。

协作水平越高,筹备越完善通常冲刺计划会也会更短,活动有效性也越高。就是说,理论上成熟团队的冲刺计划会可能15分钟就完成了。

准备。

在冲刺计划会仪式中值得准备以下内容:

  • 来自冲刺评审会中的宝贵输入信息与反馈(可能已经处理到产品待办事项列表 Product Backlog中)

  • 提炼产品积压表 refine

  • 上次回顾会议确定了的至少一项高度优先的流程改进

  • 待讨论的潜在冲刺目标

  • “完成”的定义 DOD

  • 最新的产品增量

  • 开发团队的过往表现

  • 冲刺期间开发团队的预计能力

现在,我经历了很多次,并且可以想象其他人也有过,成员呼吁推迟冲刺计划。他们要么不认为之前的冲刺已经完成,要么他们认为自己准备不足。

上一个冲刺中未视为“完成”的工作,可以重新计划到下一个冲刺中。请记住,冲刺在其时间范围到期时结束,但冲刺取消是例外。

不论哪种情况,都不会推迟冲刺计划。如果在进行冲刺计划之前,上述所有条件都不处于透明状态,冲刺计划会的时间需要调整,以便大家讨论完上述的关键内容,再开启冲刺。

如何定义“就绪”?

一些团队使用“就绪”的定义。Scrum仅规定了一个定义(尽管这并不排除团队引入诸如INVEST标准之类的其他定义):

“Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.” — The Scrum Guide.

“由开发团队确认的产品积压表中的项目,如果可以在某个冲刺中“完成”,则可以在冲刺计划中被定义为“就绪”。” —《 Scrum指南》。

目的。

“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.” — The Scrum Guide

“在冲刺计划结束时,开发团队应该能够向产品负责人和Scrum Master解释其打算如何作为自组织团队来实现冲刺目标并创建预期的增量。”—— Scrum指南

以及:

“Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting” — The Scrum Guide (emphasis added)

“开发团队在冲刺的头几天计划的工作将在本次会议结束前被分解” —《 Scrum指南》(强调)

如果达成了此目的,则可以实现冲刺计划会的目的。

为了实现此目的,冲刺计划会分为两个部分:

1. 这个冲刺可以完成什么?

Scrum团队共同协商冲刺的目标(Sprint Goal)应该是什么。产品负责人并不决定冲刺的目标(Sprint Goal),但需要负责讨论得出应实现的小目标(objects)。这个最初的小练习,会提升透明度,因为每个人都将自己对冲刺目标的理解统一起来。冲刺目标为开发团队选择实施的目标,提供了一定程度的灵活性。冲刺目标可能雄心勃勃(毕竟这是一个目标),并且可以促进集体协作。

产品负责人也将讨论产品待办事项,如果这些事项在冲刺内完成,就可以达到冲刺目标。

然后,开发团队将创建一个预测( Forecast),这是产品积压表的项目中进行初步选择,基于团队认为可以在冲刺中完成,以达到冲刺目标的工作单。

“Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — The Scrum Guide

“只有开发团队才能评估在即将到来的冲刺中可以完成的工作。” — Scrum指南

开发团队可能会要求产品负责人澄清并重新协商这些项目。 在第一部分的末尾,开发团队应该了解为什么需要构建这些增量。

2. 所选工作将如何完成?

协调一致后,开发团队将为交付这些产品制定初始计划。这些总和就是冲刺积压表,它将贯穿在整个冲刺中。请记住,这里还需要包含至少一个来自上一次冲刺回顾会的流程改进项目。

温馨提示:预测并非承诺。**开发团队创建的预测不应使它们僵化或对有价值的更改视而不见。**尽管开发团队承诺作为专业人士尽其所能,但质量目标不应降低,团队也不应在其“完成”的定义上走捷径,来做到向预测描述的一样。

在此活动期间,开发团队可能已经自组织并承担了工作:

“The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.” — The Scrum Guide

“开发团队会自行组织,以推进在冲刺积压表中的工作,无论是冲刺计划会上的内容还是冲刺过程中新衍生的内容。” — Scrum指南

可见性。

“Significant aspects of the process must be visible to those responsible for the outcome.” — The Scrum Guide (emphasis added)

“过程的重要方面必须对负责结果的人员可见。” — Scrum指南(强调)

除了准备冲刺计划的输入外,团队可能有多种方式来执行此事件。集体展示团队在冲刺计划期间正在做什么的工作很有意义。

尽管完全由团队决定如何最好地推动此事件,但是可见性是关键。

以及:

“The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.” — The Scrum Guide (emphasis added)

“产品负责人的决定在产品积压表的内容和顺序中可见。” —《 Scrum指南》(添加了重点)

更重要的是:

“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint” — The Scrum Guide (emphasis added)

“ 冲刺积压表是开发团队计划在冲刺期间完成的工作的高度可见的实时图片” —《 Scrum指南》(添加了重点)

就是说,我要劝解大家避免使用数字板作为实现这种可见性的手段:

“I’ve seen a lot of ridiculous setups where teams would sit impatiently and inattentively around a table, with JIRA on screen, cringingly watching one person follow instructions to update the board…” — We have to use JIRA

“我看到了很多荒谬的情况,团队会不耐烦和不专心地坐在桌子旁,屏幕上显示JIRA,勉强看着一个人按照指示更新板子……” ——我们必须使用JIRA

S.W.O.T. 画布

团队可以考虑的非Scrum技术的SWOT画布,可以在该画布上制定重要的因素,使其透明化。依赖关系会带来风险,因此可以在冲刺期间对其进行跟踪。现在,许多Scrum团队将发现许多方法,以最有效地促进该活动的开展。

很自然的,在冲刺期间,可能会发现或引入诸如障碍的新威胁。 冲刺计划可以帮助团队为当时已知的事情做准备,但也可能考虑到它将遇到未知的挑战。

分歧与错位

对齐(Alignment)是我强调的任何Scrum活动的目的(即使Scrum指南中未使用此术语)。仔细的检查可以使团队根据实际情况进行调整,从而形成共识。

通常,在冲刺计划期间,会讨论许多主题。如果不是所有成员都在场,或者输入内容不透明,那么团队将做出错误的假设,沟通不畅,从而导致团队错位。它将无法做出最佳决策,带来风险,还无法最大化价值。

有时,Scrum团队成员将难以真正根据冲刺目标,预测或计划进行工作。与任何事件一样,每个人都必须遵守Scrum价值观。每个人都应该能够以尊重的方式发表自己的想法。不同的观点是学习的机会。

自组织团队将学会通过求同存异的方式努力工作。 “不同意但承诺(Disagree-and-commit )” 是团队应该同意的潜在原则,但这可能并不适合每个团队。因此,还有有多种方法可以达成共识。为了快速检测是否达成共识,团队可以使用手势。

如果团队无法就如何同意或不同意达成一致,这将在整个开发过程中造成严重的破坏。

定义简单的后续步骤通常就足够了。接着就是放手去做。相信你一定能解决的。请记住,在冲刺的头几天做好工作规划就足够了。

打包并行动

作为Scrum Master,请尝试确认每个人是否都了解冲刺目的和方法,并且能够跟进它。

整个团队是否了解如何合作? 信心水平是多少? 他们实际上是在承诺还是在被动接受?

通常,Scrum Master已经可以从冲刺计划结束时的氛围中某种程度上预测整个冲刺的期望值。

请记住,这仅仅是开始。 随着冲刺的推进和更多的发现,计划必须进行调整,并且团队的自组织能力,实现冲刺目标或创建预期增量的能力,可能会面临挑战。

另外,作为Scrum Master,重要的是提醒Scrum团队他们的改进目标,并且在制定计划时也要考虑这一点。

请记住,冲刺计划在其时间范围到期时结束,或者在达到事件目的时更早结束。

参考链接