博客列表
/

Sprint计划

Sprint计划

作者:Sjoerd Nijland 全部标签: 技术类
2020年07月24号

原文作者:Sjoerd Nijland

原文地址:https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779

翻译:柴晓燕&付新圆

对于敏捷中的活动有很多,本文先从Sprint计划开始,分享一些方法、建议和注意事项,这些对理解和实践Scrum都很有帮助。

Who?

Sprint计划的参与者:整个Scrum团队。

请注意,Sprint计划是一个积极的、合作的活动。如果需要的话,大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙,在会议期间能收集到更多信息。

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

参与性

并不是每位成员都会在参与活动时表现出积极主动和创造性,有些成员只有在感到自信或舒服时才会加入。

出勤率和参与度低都会降低透明度,并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。

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

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

“给他们提供所需的环境和支持,并信任他们来完成工作。” —敏捷宣言。

有时,参与者可能会占据主导地位,并试图利用一事件来指导和影响团队的方向。这些输入可能非常有价值,但可能会妨碍其他人添加宝贵的输入,参与者应该意识到这一点。当团队成员之间发生不尊重甚至敌对时,Scrum Master应该及时介入。团队要把Scrum Master视为教练,以保护团队环境的安全。

When?

Sprint计划发生在什么时候: Sprint的开始。

这其实是一个很难回答的问题,《Scrum指南》并没有明确指出Sprint计划必须在一开始就进行。 事实上,如果准确地解释的话,在Sprint计划期间计划的工作指的是即将到来的Sprint,而不是当前的或这个Sprint。 Sprint计划不会在两者之间进行,因为Sprint在上一个Sprint结束后立即开始。请记住,Sprint充当的是事件的容器。

《Scrum指南》暗示了这一点。

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

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

“Sprint计划:定时活动,以开始Sprint。” — Scrum词汇表

团队在优化期间准备Sprint计划并不少见。总的来说,Sprint计划在一致的时间和地方开始。

How long ?

如果进行长度为一个月的冲刺,最多需要8个小时来进行冲刺计划 。对于周期短的冲刺, 则花费的时间更少。

团队通常会根据sprint的周期来制定迭代计划 ,一个星期的Sprint可能 需要2个小时的计划时间。请记住,这只是最大时间,没有最小时间。经验丰富的团队很可能在时限到期之前完成计划 。

好的协作与改进能促使sprint计划会议更加迅速,更加有效。就是说,时间并不能决定解决问题的效率 。

准备

Sprint计划时我们要准备以下内容 :

  • 来自Sprint回顾会的反馈和有价值的输入内容 (可能已经加入到产品待办事项列表中)
  • 完善的产品待办列表
  • 在上次迭代回顾会议上确定的至少一项 优先级较高的流程改进
  • 讨论Sprint的潜在目标
  • “完成”的标准,即验收标准。
  • 最近一次的产品增量
  • 最近一次迭代开发团队的表现
  • 冲刺期间开发团队的预计容量

在我的项目中,团队经历了很多次迭代 ,成员们都在呼吁推迟Sprint计划,他们要么不认为上一个Sprint已经完成,要么觉得自己准备不充分 。

那么, 上一个Sprint中 未被认 为“完成”的工作可以重新 规划 到下一个Sprint中。 请记住一个冲刺规定的时间范围结束标志着这个冲刺的结束,当然取消冲刺除外。

无论哪种情况,Sprint计划都不会推迟。如果在Sprint计划之前,上述所有内容都不是透明的,那么Sprint计划的时间范围可能允许在计划期间创造这种透明性。

Ready的解释

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

“可以由开发团队在一个Sprint内“完成”的产品Backlog项被认为是“准备好”的,可以在Sprint计划中进行选择。”—Scrum指南。

目的

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

并且 :

“ 开发团队在Sprint 的第一天 计划的工作将在本次会议结束前被分解。” — Scrum指南(强调)

如果实现了此目的,就达到了Sprint计划的目的 。

为了实现此目的,Sprint计划分为两个部分:

1.此Sprint可以做什么?

Scrum团队共同的 Sprint目标 应该达成一致。 产品负责人不指定Sprint目标,而是讨论Sprint应该实现的目标。最开始的时候团队需要透明性, 每个人对Sprint的目的的理解都需要保持一致。Sprint目标为开发团队选择实施的目标提供了一定程度的灵活性。冲刺目标可能雄心勃勃(毕竟这是一个目标),并有促进集体协作的作用。

产品负责人也将讨论产品待办事项,如果这些事项在Sprint中完成,将达到Sprint目标。

然后,开发团队将创建一个 Forecast (预测) ,这是对产品待办事项的初步选择,基于对产品的认识可以在Sprint中完成任务以达到Sprint目标。

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

开发团队可以要求产品负责人说明并重新协商这些待办事项 。

在第一个Sprint的末尾,开发团队应该了解为什么要构建增量。

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

当协调一致时,开发团队将制定一个交付的初始计划。 这些内容就是Sprint Backlog,它将在整个Sprint中继续出现。请记住,这还包括来自 最近一次 Sprint回顾 会 的改进计划。

温馨提示:预测并非承诺。开发团队创建的预测,应有效的去实施或对有价值的更改进行实践。 虽然开发团队作为专业人员承诺尽其所能, 但质量目标不应降低, 团队也不应为了实现预测而在“完成”的定义上偷工减料。

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

“开发团队在Sprint计划期间以及整个Sprint中根据需要自行组织以进行Sprint Backlog中的工作。” — Scrum指南

透明性

除了为Sprint计划准备输入之外, 团队还有很多方法来完成Sprint计划。在Sprint计划期间,团队的力量在工作中的汇报是显而易见的。

团队来决定如何最好地推动Sprint计划,是非常关键的。

“流程中最重要的是必须对负责结果的人员 可见 。” — Scrum指南

并且 :

“产品负责人的决定在产品待办事项列表的内容和 序列中 可见 。” — Scrum指南

更重要的是:

“ Sprint待办事项是开发团队计划在Sprint期间完成的工作的 高度可见的 实时 影像 ” —《 Scrum指南》

也就是说,我要提醒大家不要仅仅依赖电子看板来实现这种透明性:

有些糟糕的设置,例如:“ 团队会不耐烦地、漫不经心地围坐在一张桌子旁,桌子上的大屏幕正显示着电子看板,团队们 紧盯 着一个人按照指示更新看板…”

S.W.O.T

团队可以考虑的非Scrum技术是一个SWOT画布,在这个画布上,团队可以使重要因素变得透明。依赖关系会带来风险,因此可以在sprint期间跟踪它们。

当然,在Sprint过程中,也会发现或引入新的威胁,如障碍物。Sprint计划可以帮助团队为当时已知的事情做准备,也需要考虑到它未来可能遇到的未知挑战。

分歧

一致性,是我认为的任何Scrum活动的目的(即使Scrum指南中没有使用这个术语),仔细的检查能使团队在实际情况上保持一致,从而形成共同的理解。

通常,在Sprint计划期间会讨论许多主题,如果不是所有成员都在场,或者输入内容不透明,那么团队可能就会做出错误的假设,沟通不畅,从而导致团队不协调。产生了分歧将无法做出最佳决策,从而引入风险且价值无法最大化。

有时候,Scrum团队成员很难真正地在Sprint目标、预测或如何进行工作的计划上保持一致。与任何事件一样,每个人都必须遵守Scrum价值观,每个人都应该能够以尊重的方式表达自己的想法,不同的观点是学习的机会。当团队不能就如何同意或不同意达成一致时,这将在整个开发过程中造成严重的中断。

自组织团队需要学会平和的处理分歧。“不同意但承诺”是团队可以同意的潜在原则,但这可能并不适合每个团队。因此,有多种方法可以达成共识。为了快速检测是否达成共识,团队可以采用诸如 使用手势这样的方式。

请记住,仅在Sprint的第一天就计划好工作就足够了。

Scrum Master对 Sprint计划的作用

作为Scrum Master,可以试着验证团队中每个人是否理解Sprint的目的和方法,并且支持Sprint。

整个团队是否了解如何协作?信心水平是多少?他们实际上是在承诺还是在默默地服从?

从Sprint计划结束时的氛围来看,Scrum Master通常已经可以在某种程度上预测整个Sprint的期望。

请记住,这仅仅是开始。随着Sprint的进步和更多的知识,计划必须进行调整,并且团队的自我组织,实现Sprint目标或创造预期增量的能力可能会受到挑战。

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

Sprint计划在其时间范围到期时结束,或者如果事件的目的实现了,则可以提前结束。

作者:Sjoerd Nijland

出处:Choerodon

欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。