从看板到 Scrum,我们是如何选择敏捷的

为什么 Atlassian 的 Micros Scale 团队从看板转向 Scrum

Nelly Sattari 作者:Nelly Sattari
浏览主题

成为一支健康的工程团队的一部分就是成为一支自我组织的团队!这是一个角色和职责明确的团队,致力于通过深思熟虑的计划来交付项目。

去年,我们创建了一个名为 Micros Scale 的新团队,专注于创建 Atlassian 的内部 平台即服务 (PaaS),即我们的开发人员体验平台。由于我们的工作范围固定,时间线明确,因此我们更加致力于完成更多工作,更加集中,以目标为导向,并做到积极主动。

但是,之前我们的团队接到了大量临时的操作工作,这使我们无法正确计划冲刺。至少 55% 的团队能力被分配给保持运转 (KTLO) 轮换。这使看板成为当时最适合我们的方法。

值得注意的是,根据 Tuckman 模型,Micros Scale 团队处于组建阶段,有一些需要改进的领域,包括能力规划、冲刺规划、目标设定、团队反思、梳理和故事阐述、估计、项目分解等。

tuckman 模型图片

哪种敏捷方法适合我们?

Micros Scale 有两个高度复杂的重大项目,截止日期是向我们的客户公开宣布的。这意味着更快的交付至关重要。我们需要对我们的交付方法充满信心,并希望像敏捷专业人士一样进行规划。我们希望我们的团队能够自我组织,实现共同的目标,并以经验为基础。

我们根据以下问题重新评估了我们的敏捷方法:

  • 是否有可能为每次迭代设定目标,以实现具有独特主题的目标?
  • 我们能否承诺一两周的交付时间?
  • 我们能否详细说明并锁定我们需要解决的要求?
  • 临时请求变更任务优先级的频率是否较低,我们发生重大变更的可能性是否较小?
  • 我们的团队是新的,在敏捷流程方面还不那么成熟吗?


由于这些问题的答案是肯定的,我们意识到 Scrum 是我们团队最好的敏捷方法。以下是我们用来为决策提供依据的其他详细信息:

 

 

 

 

敏捷方法

这是关于什么的?

它对我们有帮助吗?

为什么?

Scrum

Scrum 是关于清晰的路线图和按优先顺序排列的工作块,而看板是关于可视化您的工作,这是针对团队临时提出的。

我们有清晰的预定义待办事项列表,需要完善和优先排序。我们的工作是可预测的,这与之前的团队不同,之前的团队充满了惊喜和高优先级请求。

故事不应该在冲刺中途变更。

我们可以采取更灵活的方法,在本例中为 scrumban(Scrum 和看板的混合体)。

对于仍在学习功能领先的敏捷团队来说,Scrum 更容易采用。Scrum 的规范性更强,并且有常规程序和时间范围提供保障。

我们有一支由新成员组成的新团队,仍处于组建和头脑风暴阶段,因此 Scrum 可以帮助我们变得更加成熟。阅读 Tuckman 模型

看板

限制正在进行的工作,并专注于缩短项目周期时间。用例是您的团队没有工作时间限制和既定时间线。该请求会尽快提交给团队并得到解决(例如服务台团队的 SLA)。

其他团队依赖我们,因此我们需要预估的时间线来帮助其他人做出相应的计划。我们向 Atlassian 客户公开做出了一些承诺,因此我们需要谨慎行事并为之做好计划。我们没有很多像服务台这样的短时请求。

非常适合有大量传入运营请求的团队,请求的优先级和大小各不相同。

我们没有沉重的 KTLO 负载,工作流由团队成员轮换管理。如果我们愿意,我们可以把那个被打扰的角色当成看板。

我们选择了 Scrum

我完全意识到,工程经理的主要特征之一就是像指挥家一样行事,同时他也是联系人、指南针和教练。所以我同样需要锻炼指挥家能力。以下是我实现这个目标的方式:

了解更多敏捷信息

Atlassian 的内部学习资源帮助我提高了敏捷实践方面的技能。我参加了大量的敏捷课程,并咨询了敏捷教练。我还采访了几位工程经理,学习其他组织和团队的经验。

使用 DACI

DACI 决策框架——代表“推动者、审批者、贡献者、知情者”——用于做出有效和高效的小组决策。我向我的团队介绍了 DACI 变更提案,以确保获得他们的意见、同意和支持。

使用冲刺模板

我想出了一个管理我们冲刺的流程,并为每个冲刺建立了一个模板,以帮助进行更合理的规划。冲刺计划模板包括:

  • 如何回顾之前的冲刺,确保我们清楚自己取得的成就并进行庆祝。
  • 如何回顾之前的冲刺,并将我们的学习应用到下一个冲刺中。
  • 什么是冲刺节奏、名称、目标和目的?
  • 我们承诺交付多少故事?冲刺范围是什么?
  • 如何根据人们的可用性进行能力规划。
  • 我们需要在冲刺中期进行哪些活动才能为下一次冲刺做好充分准备?
  • 如何写故事、阐述要求以及解决问题的解决方案。
  • 如何跟踪我们承诺的故事状态以及如何处理未完成的故事。

我们还有一篇关于如何在 Jira Software 中进行冲刺的精彩教程

转向 Scrum 是值得的

以下是我们转向 scrum 所做的改进:

速度改进

在敏捷中,衡量团队生产力的因素之一是速度,也就是说 Scrum 团队在冲刺期间完成的平均工作量。我们使用速度图来了解我们的团队的承诺和交付的内容。在下方速度图中,灰色列显示了团队根据能力承诺的故事点数。我们将其与蓝列进行比较,蓝列是他们实际交付了多少故事点。然后,团队可以用它来调整对未来冲刺的预测。

速率表

及早发现风险

能够及早发现风险并提出拟议的解决方案是项目成功的关键。

通过定义目标和冲刺主题,我们选择了有凝聚力的故事来实现目标。在冲刺中期会话,我们的团队整理、完善和详细阐述了故事。在详细阐述过程中,我们提出了以下问题:

  • 需要做些什么?
  • 我们为什么要做这项工作?
  • 它会增加什么业务价值?

这有助于我们的工程师识别依赖关系,并对影响较大的请求单进行优先排序,以消除障碍。它还促使我们改变了工作方式,使每个项目都更加专注于团队。

庆祝!我们成功交付

能力规划和目标设定为我们带来了有意义的动力,也为我们带来了保持承诺透明的挑战。我们成功交付了 Atlassian PaaS 账户分片的一个关键阶段。我们还即将交付数据驻留项目的第一阶段,以覆盖更多 AWS 区域,以实现可靠性、灵活性和合规性。

从“组建”过渡到“规范”

正如我上面提到的,Micros Scale 团队相对较新,根据 Tuckman 模型,往往处于组建阶段。

为团队定义统一的目标能够推动每个人团结一致和相互支持,以实现团队目标并提高团队动力。我们失败、反思、吸取教训,然后变得更好。三个半月后,我们又为 Micros Scale 扩招了 50% 的员工,并且我仍然很自豪地将该团队视为一支规范团队。

沟通改进

制定计划并在每次冲刺期间全神贯注,这提高了我们计划为整个团队做的事情的可见度,也使我们能够保持同步。对于工程经理和利益相关者来说,跟踪项目障碍和进展要容易得多。

如何选择敏捷方法

  1. 如果发现问题,请立即查看您的流程。以敏捷的方式思考:人员、流程和工具。
  2. 评估您的团队项目和职责,找到最适合您团队的敏捷方法。请查看我们的看板与 scrum 页面,了解有关这些方法的更多信息。
  3. 如果您决定转向 Scrum,我建议使用 Jira Scrum 板或者在 Confluence 或您最喜欢的工具上创建一个模板。

对于每个冲刺,创建一个冲刺计划页面,以回顾和反思上一次冲刺,并根据团队的能力和冲刺目标为下一次冲刺做计划。这是我的个人 Confluence 模板:

冲刺计划模板图片

这是我的能力规划模板,包含在我的整个 Scrum 模板中:

Scrum 可用性

还有我的冲刺目标和范围模板:

冲刺目标图片

在冲刺中期,最好再用一页来跟踪团队在过去一周的表现,根据当前的冲刺进度决定需要将哪些故事延续到下一个冲刺中(整理),并详细说明您整理的故事(故事优化)。这是我的冲刺中期待办事项整理和优化模板:

待办事项梳理

每个团队都不一样,对我们有用的东西可能对其他团队不起作用。Scrum、看板或两者兼而有之,比如 scrumban 和 kanplan,可能就是更好的方法。评估团队的特定需求并了解哪种方法对他们有用,这一点至关重要。