Close

Scrum

了解如何利用相关最佳实践来使用 Scrum

浏览主题

什么是 Scrum?

Scrum 是一个帮助团队协同工作的框架。就像橄榄球队(其名字也源于此)为准备大型比赛而进行培训那样,Scrum 鼓励团队吸取经验,在处理问题时进行自我组织,并通过反思得失实现持续改进。

虽然我谈论的 Scrum 是软件开发团队最常用的工具,但它的原则和经验教训可用于各种团队合作。这是 Scrum 如此受欢迎的原因之一。Scrum 通常被认为是一个敏捷开发项目管理框架,它描述了一组协同工作的会议、工具和角色,以帮助团队组织和管理其工作。

在本文中,我们将在 Scrum 指南和 Scrum.org 首席执行官 David West 的帮助下,讨论如何构建传统的 Scrum 框架。我们还将举例说明我们如何看待客户偏离这些基本原则以满足其特定需求。为此,我们的 Jira Software 集团产品经理、前敏捷开发教练 Megan Cook 将在我们的敏捷开发教练系列视频中介绍一些提示和技巧:

Scrum 文章

[续]

框架

人们通常认为 Scrum 和敏捷开发是同一回事,因为 Scrum 关注持续改进,而这是敏捷开发的核心原则。但是,Scrum 是完成工作的一种框架,而敏捷开发是一种思维模式。您无法真正“敏捷化”,因为这需要整个团队一致努力才能改变其向客户交付价值的思维方式。但是,您可以使用 Scrum 等框架来协助您开始思考这一方式,并在日常沟通和工作中实践如何构建敏捷工作流原则。

Scrum 框架是一种基于持续学习和波动因素调整的启发式框架。它承认团队在项目开始时并不了解所有内容,并通过吸取经验教训不断发展。Scrum 的结构旨在帮助团队自然而然地适应不断变化的条件和用户要求,并在流程和较短的发布周期中重新调整优先级,以便您的团队不断学习和改进。

Scrum 框架 | Atlassian 敏捷教练

虽然 Scrum 是结构化框架,但它并不是完全僵化的。您可以根据组织需求调整其执行。关于 Scrum 团队如何才能成功,有许多理论。但是,十多年来,在帮助 Atlassian 敏捷开发团队完成工作的过程中,我们发现,无论您选择何种框架,清晰的沟通、透明度和致力于持续改进始终都是框架的核心。剩下的,就得靠您自己了。

Scrum 工件

让我们从确定 Scrum 的三个工件开始。工件是我们制造的东西,就像是解决问题的工具。在 Scrum 中,这三个工件分别是产品待办事项、冲刺待办事项,以及您对“已完成”定义的增量变化。它们是 Scrum 团队中的三个常量,我们会不断地对其进行重新审视,并投入额外的时间进行改进。

  • 产品待办事项是产品负责人或产品经理需要完成的主要工作列表。它是功能、要求、增强功能和修复的动态列表,并用作冲刺待办事项的输入。本质上,这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护,因为随着我们了解的更多或随着市场的变化,列表中的项目可能不再相关,或是可能会以其他方式解决问题。
  • 冲刺待办事项是开发团队为实现当前冲刺周期而选择的项目、用户故事或缺陷修复列表。每次冲刺之前,在冲刺规划会议(我们将在后文进行讨论)中,团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活,可以在冲刺期间发展。但是,基本的冲刺目标(团队希望通过在当前冲刺中实现的目标)不能受到影响。
  • 增量(或冲刺目标)是冲刺阶段中可用的最终产品。在 Atlassian,我们通常会在冲刺结束演示期间展示“增量”,而团队则会展示在冲刺期间完成的内容。在此领域之外,您可能不会听到“增量”一词,因为它通常是指团队对“已完成”、里程碑、冲刺目标,甚至是完整版本或已交付长篇故事的定义。这只取决于您的团队如何定义“已完成”以及您如何定义冲刺目标。例如,某些团队选择在每次冲刺结束时向客户发布某些东西。因此,他们对“已完成”的定义将是“已发货”。但对其他团队而言,则可能并非如此。假设您使用的是基于服务器的产品,该产品只能每季度发送给客户。您仍可选择在为期 2 周的冲刺中工作,但是,您对“已完成”的定义可能只是完成您计划一起发布的更大版本的其中一部分。当然,发布软件所需的时间越长,软件错过标记的风险就越高。

如您所知,您的团队可以选择定义很多变体,即使是在工件内也是如此。这便是为何必须对工件维护方式保持开放态度的原因。也许您对“已完成”的定义会给您团队减压,且您需要返回并选择一个新的定义。

专业提示

您应该像处理产品一样敏捷地处理框架。花一些必要的时间来检查事务的进展情况,并在必要时做出调整,而不要仅仅为了一致性而强迫自己执行某些事项。

Scrum 仪式或事件

Scrum 框架中一些更为人所知的组件包括 Scrum 团队定期举行的一系列连续活动、仪式或会议。在这些仪式中,我们可以看到团队之间的最大差异。例如,有些团队发现举行所有这些仪式既繁琐又重复,而另一些团队则将这些仪式作为必要的登记手段。我们的建议是,在两次冲刺阶段使用所有仪式,然后看看其效果。接着,您可以进行快速回顾,看看可能需要进行哪些调整。

以下是 Scrum 团队可能参加的所有重要仪式清单:

  1. 组织待办事项列表:有时也被称为待办事项梳理,它由产品负责人负责。产品负责人的主要工作是协助实现产品愿景,并持续关注市场和客户。因此,客户可根据用户和开发团队的反馈来维护此列表,以协助确定列表的优先级并保持整洁,同时准备在任意给定时间进行工作。您可在此处了解有关维护正常待办事项列表的更多信息。

  2. 冲刺规划:由整个开发团队在本次会议期间规划当前冲刺期间要执行的工作(范围)。本次会议由 Scrum 主管主持,而团队则在会议期间决定冲刺目标。接着,可将产品待办事项中的特定用途故事添加到冲刺中。这些故事应与目标始终保持一致,且 Scrum 团队也承诺可在冲刺期间进行实施。

    在规划会议结束时,每位 Scrum 成员均需清楚在冲刺期间可以交付的内容,以及如何交付增量变化。

  3. 冲刺:冲刺是 Scrum 团队共同完成增量的实际时间段。两周是一个相当典型的冲刺时长,尽管某些团队发现一周更容易确定范围,或是一个月更容易提供有价值的增量变化。Scrum.org 的 Dave West 建议,工作越复杂,未知因素就越多,而冲刺就应该越短。但事实上,这取决于您团队;而如果不起作用,您也不应畏惧改变!在此期间,必要时可由产品负责人和开发团队重新协商范围。这构成了 Scrum 经验本质的关键。

    所有事件(从规划到回顾)都是在冲刺期间发生的。一旦确定了冲刺的特定时间间隔,就必须在整个开发期间保持一致。这有助于团队吸取经验教训,并将这些洞察应用于未来的冲刺。

  4. 每日 Scrum 或简短例会:这是每天在同一时间(通常是早晨)和地点举行的超短例会,以确保此会议简洁明了。很多团队试图在 15 分钟内完成会议,但这只是一个参考。此会议也被称为“每日短会”,它强调需快速举行会议。每日 Scrum 旨在让团队中的每一个成员都保持同步,共同朝着冲刺目标努力,并制定未来 24 小时的计划。

    您可在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的问题。

    每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题:

    • 我昨天做了什么?
    • 我今天打算做什么?
    • 是否存在障碍?

    然而,我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是,它可以分散日常会议的注意力,这样团队就可以在当天剩下的时间里专注于工作。因此,如果它不幸沦为了每日日程表阅读会,则应果断做出改变以求创新。

  5. 冲刺审核:在冲刺结束时,团队聚集在一起进行非正式会议,以观看增量演示或检查增量。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项,以征求他们的反馈意见。尽管在多数情况下都会发布增量,但产品负责人仍可决定是否发布增量。

    此次审核会议也是产品负责人根据当前冲刺重新处理产品待办事项之时,当前冲刺可为下一次冲刺规划会议提供相关信息。对于为期一个月的冲刺,可考虑将您的冲刺审核时间限制为最长四个小时。

  6. 冲刺回顾回顾是指团队聚集在一起共同记录和讨论冲刺、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。我们的思路是创造一个地方,让团队能够专注于哪些工作进展顺利和哪些地方有待改进,而不是专注于出了什么问题。

Scrum 获得成功所需的三个重要角色

Scrum 团队需要三个特定角色:产品负责人、Scrum 主管和开发团队。由于 Scrum 团队为跨职能部门,因此除开发人员之外,开发团队还包括测试人员、设计人员、用户体验 (UX) 专家和运营工程师。

Scrum 产品负责人

产品负责人是产品方面的佼佼者。他们专注于了解业务、客户和市场要求,然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能:

  • 构建和管理产品待办事项。
  • 与企业和团队密切合作,以确保所有人都能了解产品待办事项中的工作项。
  • 明确指导团队接下来提供哪些功能。
  • 确定何时发布产品,且倾向于更频繁地交付产品。

产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外,产品负责人是一个个体,这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。

Scrum 主管

Scrum 主管是其团队中在 Scrum 方面的佼佼者。他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训,并寻找方法细调他们在此方面的实践。

高效的 Scrum 主管应深入了解团队正在执行的工作,并可协助团队优化其透明度和交付流程。作为首席推动者,此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源(人力和物力)。

Scrum 开发团队

Scrum 团队是具体工作的执行者。他们是可持续发展实践方面的佼佼者。效率最高的 Scrum 团队关系紧密、同地协作,且成员通常为 5 到 7 名。确定团队规模的一种方法是遵循 Amazon 首席执行官 Jeff Bezos 提出的著名“两个披萨原则”(团队应该足够小,以便分享两个披萨)。

团队成员具有不同的技能,并且彼此互相锤炼,因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队遵循自我组织原则,且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助,以确保成功完成冲刺。

Scrum 团队可推进每个冲刺的计划。他们将自己的历史速度用作指导,预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈,进而使其能随着时间的推移做出更加准确的预测。

Scrum、看板和敏捷开发

Scrum 是一种非常流行的敏捷开发框架,以至于 Scrum 和敏捷开发经常被误认为是同一回事。此外,还有一些框架(如看板)也是较受欢迎的选择。某些公司甚至选择使用 Scrum 和看板的混合模式,后者也亦称为“Scrumban”或“Kanplan”,这是一种附带待办事项列表的看板

Scrum 和看板都采用可视化方法(例如 Scrum 板或看板)来跟踪工作进度。两者都强调效率,并将复杂的任务分成可管理的较小工作,但它们实现目标的方法却各有不同。

Scrum 专注于固定长度的小型迭代。一旦最终确定冲刺的时间段,便可确定在此冲刺周期内可实施的故事或产品待办事项条目。但在看板中,首先需确定当前周期内要实施的任务数量或正在进行的工作(WIP 限制)。然后,向后计算实施这些功能所需的时间。

看板的结构化程度不如 Scrum。除了 WIP 限制之外,它的解释是相当开放的。但是,Scrum 在实现过程中必须强制实施几个明确的概念,如冲刺审核、回顾、每日 Scrum 等。此外,它还坚持跨职能。换言之,Scrum 团队无需依赖外部成员就能够实现目标。组建跨职能团队并非易事。从此意义而言,看板更容易适应,而 Scrum 则可视为开发团队思维过程和运作方式的根本性转变。

但是,为什么要使用 Scrum?

Scrum 框架本身很简单。规则、工件、事件和角色都不难理解。其半规范性方法实际上有助于消除开发过程中的歧义,同时可为公司提供足够的空间来引入自己的个性风格。

Scrum 可将复杂的任务组织成易于管理的用户故事,是棘手项目的理想之选。此外,明确划分角色和规划开展的活动可确保整个开发周期的透明度和集体自主权。快速发布可保持团队的积极性和用户满意度,因为他们可以在短时间内看到工作进展。

但是,我们可能需要时间才能充分了解 Scrum,特别是在开发团队适应典型的瀑布模型时。小型迭代、每日 Scrum 会议、冲刺审核和确定 Scrum 主管的概念对于新团队来说可能是具有挑战性的文化转变。


但是,长期的好处远远超过最初的学习曲线。Scrum 在跨不同行业和垂直领域开发复杂的硬件和软件产品方面取得的成功,使其成为满足贵组织需求的卓越框架。

Claire Drumond
Claire Drumond

Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.

Up Next
Sprints