Scrum指南最新版 2020 Scrum权威指南 游戏规则

Scrum 官方权威指南

收听有声版 | 官网下载PDF

由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护

版本:2020中文版 | 查看旧版本(2017)

Scrum 指南的目的

在 1990 年代初,我们开发了 Scrum。在 2010 年,我们撰写首版 Scrum 指南,以帮助全世界的人们理解 Scrum。自那时起,我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。

Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的,这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则,将掩盖问题并限制 Scrum 的好处,甚至可能变得毫无用途。

我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用,超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大,developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此,我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者,而是为了简化统称。如果您从 Scrum 中获得价值,那么您可以将自己视为其中一员。

在使用 Scrum 时,可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的,因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异,因此不在本文中描述。

Ken Schwaber & Jeff Sutherland 2020 年 11 月

敏捷之旅中国 2020 汇总

敏捷之旅介绍

Agiletour(以下称为敏捷之旅)是一个国际非盈利性组织,于2008年成立,总部位于法国,由帕特里斯·佩蒂特发起。其目的是提供一个高效有趣的敏捷开发学习途径,在全球范围内推广敏捷的思想和实践,帮助企业更好的实施敏捷。

2020 各地敏捷之旅时间

英文官方网站

招募

如果你想为敏捷在中国的推广贡献自己的力量,可以联系 bob@bobjiang.com

如果你想举办所在城市的敏捷之旅,欢迎在下面的issue留言。

提交举办信息(已经确定举办,尚未列在上面)

目标

敏捷之旅的主要目标是:

  • 大量交流敏捷

我们的主要任务是在整个十月和十二月的几个月里,以我们的行为进行一次“大众交流”。我们希望在有受众的任何地方进行交流,以吸引更多对我们新的专业方法的关注

  • 分享我们对敏捷的看法

由于敏捷不断发展,我们希望向新视野开放,同时也为敏捷社区贡献我们的理解,解释和想法

  • 联邦制

鼓励世界各地在敏捷领域中发挥领导作用,同时与敏捷文化和自我组织保持一致

  • 支持

协助我们的同事和当地企业采用敏捷

总而言之,AgileTour敏捷之旅的任务是突出世界各地的领导组织并创建敏捷领导者,并协助大众传播敏捷的好处及其对世界专业人士的影响。因此,AgileTour敏捷之旅旨在帮助所有的组织和企业,这些组织和企业将以敏捷方法论为基础和使命。

以往活动的总结

Scrum指南最新变化 2020版本

Scrum指南

更少的规范性

多年以来,《Scrum指南》变得更具规范性(Prescriptive)。2020版旨在通过删除或软化说明性语言,将其恢复为最低限度的框架。

例如:

  1. 删除了每日Scrum问题,
  2. 软化了围绕PBI属性的语言,
  3. 软化了Sprint待办事项围绕回顾会的语言的条目
  4. 缩短了取消Sprint的部分等。

一个团队专注于一个产品

一个团队专注于一个产品的目的是消除团队内独立团队的概念,这会导致产品负责人(PO)和开发团队之间的“代理”或“我们和他们“的行为。现在只有一个Scrum团队专注于同一个团队目标,具有三组不同的职责:PO,SM和开发人员。

产品目标的介绍

2020版的《Scrum指南》引入了产品目标的概念,为Scrum团队向更大的有价值的目标迈进提供了重点。每个Sprint都应使产品更接近整体产品目标。

冲刺目标,完成的定义和产品目标的目录

之前的《Scrum指南》描述了Sprint目标和完成的定义,但并没有真正给它们提供身份。它们不完全是工件,而是有些附属于工件。除了2020版对产品目标提供了更清晰的说明。现在,每个工件中都包含对它们的“承诺”。

  • 对于产品待办事项列表(Product Backlog),是产品目标;
  • Sprint待办事项列表(Sprint Backlog)则有Sprint目标,
  • 增量(Increment)则有完成的定义(现在不带引号)。

它们的存在是为了带来透明并专注于每个工件的进度。

自我管理超越自我组织 self-managing over self-orgainzing

之前的《Scrum指南》将开发团队称为自组织,团队选择和谁一起工作以及如何完成工作。 2020版本则更着重于Scrum团队,强调了自我管理的Scrum团队,团队选择和谁一起工作、如何做以及做什么。

三个Sprint计划的主题

除了“什么”和“如何”的Sprint计划主题外,2020的《Scrum指南》还强调了第三个主题“为什么”,指的是冲刺目标(Sprint Goal)。

全面简化语言,扩大受众范围

2020版本的《Scrum指南》着重于消除冗余和复杂的陈述,以及消除了余下的对IT工作的任何推断(例如测试,系统,设计,需求等)。现在,《 Scrum指南》不到13页。

加入社区?

加入社区参与讨论?

欢迎报名我的线上课程 - Scrum敏捷精髓

用户故事和任务 | 敏捷小知识 | 敏捷家出品

定义

什么是用户故事

用户故事是一种敏捷的实践,帮助开发团队从写需求的视角切换到与客户交谈需求的视角。敏捷用户故事中会有1-2句话简要描述需求,更重要的是基于这几句话的一系列交谈。

用户故事是从最终用户(或客户)的视角出发,对于他们有价值的特性的简单描述。通常是如下的格式:

作为 <某类用户>, 我想要<达成某个目标> 由于 <某个原因>

什么是任务

a: a usually assigned piece of work often to be finished within a certain time
b: something hard or unpleasant that has to be done

任务的定义,来自于 韦氏词典

  1. 任务,通常是一定时间内要完成的、已分配的工作
  2. 任务,必须要做的,较困难的(令人不愉快的)的事情

这里的任务是通用的定义,在敏捷工作环境中,任务指的是团队为了完成用户故事而拆分更加细粒度的、功能模块的工作。

用户故事和任务的相同点

  • 用户故事和任务都是开发团队必须参与的
  • 用户故事和任务都是为了完成特性(feature)和产品的
  • 用户故事和任务,通常都是较难的、必须完成的工作
  • 用户故事和任务,通常都有截止日期(时间)的要求

用户故事和任务的不同点

  • 用户故事就像裤子,而任务就像内裤
  • 用户故事通常是解释特性的why,而任务通常是实现特性的how
  • 用户故事是面向用户(或客户)的,而任务是面向团队的
  • 用户故事通常是产品负责人(或客户)关注的,而任务通常是开发团队关注的 (注:开发团队也需要关注用户故事)
  • 用户故事通常是以用户的语言进行描述(通俗易懂),而任务通常偏向于技术语言描述(如用python实现某个算法)

社区的回复

  • 需求的价值版本描述和需求的BA-编程行为拆解? – 悟空
  • 用户故事用户能听懂,可以参与。任务是团队自己能理解的功能做拆解。用户故事可以是一个mvp,任务可能只是故事的一个部分,不完整。 – Bruce Wang
  • 任务是用户故事拆分后的子项,有指定的执行者 – 嘿,愉快的人儿啊
  • 用户故事是需求点描述。任务是拆分出来的,用以实现用户故事的条目,任务指导开发团队实施具体的工作。– Fiona W.Y
  • 用户故事是做什么,任务是怎么做 – 她来听我的演唱会
  • 故事管需求及协作沟通维度,Whole Team都要可理解,What or Why;任务涉及执行维度,在迭代执行中产生,是How的角度。– Junn熊
  • 用户故事是需求的描述,任务是实现需求的拆解。– No.1理想
  • 故事是要听的话,任务是要做的事。 把听到的话转换成要做的事,就是故事分解成任务 – 指南针
  • 用户故事 = 业务需求,任务 = 实现业务需求需要做的动作 – Carl
  • 先有故事,再分解任务,一个故事下可以分解包含多个任务 。任务 是具体可被执行的项目,站会上大家关注的就是 “任务”而不是故事 – 沙漠海

加入社区?

加入社区参与讨论?

敏捷教练课程安排计划

敏捷公开课

如果下面的课程计划中没有找到合适的时间和地点,还可以填写表格(表达课程兴趣,足够的人数即可单独联络开课)

CSM 课程计划

  • 成都 2020年10月31日 - 11月01日 | 我要报名
  • 线上 2020年11月07日 - 11月08日
  • 线上 2020年11月14日 - 11月15日 | 我要报名
  • 深圳 2020年12月05日 - 12月06日 | 我要报名

CSPO 课程计划

敏捷教练训练营

  • 上海 2020年12月17日 - 12月20日

课程介绍

敏捷教练训练营2020

为什么要办敏捷教练训练营

自从2016年我开始讲CSM课程以来,总会有学员问拿到CSM证书以后可以做什么,后面如何晋级?
其实证书本身有什么用呢,这个是值得打个问号的。

虽然证书不代表任何内容,证书也不一定有用。但是获得证书的过程,以及共同学习的同学这是一笔很好的回报。
在获得证书的过程中,可以了解到自己的知识有哪些欠缺的地方,可以梳理出知识结构,还可以学习到正宗的Scrum知识。

不论你是否持有CSM证书、PMI-ACP证书或者其他敏捷证书,是否有想过下一步该往哪里去呢?

敏捷教练训练营就是为了给这样的实践者,提供一个晋级的可能性,晋级的可能方向。

在今年(2020)早些时候,我找到Lucy和Lance两位大神,协商我们是否可以一起开发一个课程。目的是为了提高敏捷教练的能力,从而可以让他们能更好的服务于组织和公司。(最初的目的是为了现有的CSP服务,实际上我们不想限制于这个群体,只要是有经验的敏捷教练,都欢迎来参加。)

欢迎各位CSM,CSPO,CSP,PMI-ACP,DOP等等证书持有者,也欢迎各位实践者参与到我们的训练营中来。

敏捷教练训练营包含什么

这个训练营中包含什么内容?

以自我认知和自我成长为基础,重点提升讲授(Teaching)、辅导(Mentoring)、教练(Coaching)、引导(Facilitating)能力。

我要报名

想要了解更多信息

Certified ScrumMaster (CSM) 培训学员总结 - 辛光烁

作者:辛光烁

在艾威的课程班报名了scrum master的培训课程后,我花了一段时间认真的重新将老师的网络课程以及scrum指南回顾学习了一次,以下是我对scrum master的一些感受。

我个人是从事传统汽车行业的,对于传统的汽车开发/甚至是传统的汽车软件开发模式,一般遵循的是瀑布模型,从分析,设计,开发,测试,所有阶段是分开的,当我们结束分析后再去进行设计,设计做好后在做开发,等等。这种模式属于传统和经典模式,在汽车行业中至今仍然在使用。一些车载软件的娱乐系统更新换代的周期在几年以上,在长周期背景下,将每一步做好也可以节省成本。

但是在软件开发中我意识到,如果开发软件的同时也有大量的需求的更改,那么存在两周情况,意识退回去重做,造成延误,二是不能响应市场的需求,这两者在基于互联网开发的背景下是致命缺陷。版本迭代周期过长,没有办法满足用户需求上的变化。于是我想学习一下敏捷开发是如何解决问题的。

通过学习,我自己的认识是,在敏捷中为了解决需求的变化,可以将分析,设计,开发和测试通过不同用户故事的条件下组成不同的开发周期,组成不同的条目,如果要增加需求,那么只需要增加相应的用户条目,由PO进行确认并排序优先级,或者相反的删除需求,对于整体项目的损耗就降低了很多。同时在开发的同时,也有机会对趋势重新进行分析,这样开发的产品永远都可以跟上市场的节奏,可以实现敏捷开发。

在多种敏捷开发的模式中,Scrum是一种敏捷开发的方式,它的特点是:灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。 对于scrum的使用流程,在每一个Scrum开始的时候,需要进行sprint计划会,确定这个Sprint要做的事产品待办列表,随后大家开始执行。在每天开始时,进行每日站会。在这一个周期结束的时候,一般是2-4周后,开sprint审查会议,审查会议之后要开一个回顾会议.以上步骤完成后,再开始下一次的Sprint。

对于scrum中的角色分类,核心团队包括产品负责人、Scrum教练和开发团队。猪队中,最重要的角色就是产品负责人,因为这个项目失败的话,他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责,他只对这个团队是否合理的使用Scrum负责。

对于scrum的框架,包括产品待办列表,要不断的把已知的所有需求记录到这里面来,sprint计划会是对这个Sprint进行规划的会议。它的主要的目标就是从产品待办列表里面选择一些任务,放到Sprint待办列表中。Daily Scrum是一个用于同步进度的会议。会议形式是每日站会来进行昨天做事情,今天做的事情以及遇到挑战的总结。Sprint审查会是一个用于Sprint总结的会议。会议形式会演示产品增量,目的是把之前做的Sprint新功能给大家进行演示。Sprint 回顾会是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。

但同时,在使用scrum的过程中也需要一些注意的方面,包括Scrum绝对不能代替传统软件开发方法,Scrum适合十人左右的团队,Scrum的一个Sprint时间为2周–4周,Scrum需要一个强有力的团队等等。虽然scrum可以实现敏捷开发,但针对传统汽车行业的项目也要确定是否团队适合Scrum应用,外界的需求变化是否会很多多,这是决定使用Scrum的出发点。如果决定了使用scrum,在确定团队,相应的scrum master,找到合适的工具,比如每日看板。

欢迎报名我的线上课程 - Scrum敏捷精髓

超越指责(Beyond Blaming) -- 一致性沟通

超越指责(Beyond Blaming)

©1996年 Jean McLendon 和 Gerald M.Weinberg ,www.satir.orgwww.geraldmweinberg.com

英格兰虽然目前处于非常繁荣的状态,但仍表现出民族衰败的一些症状。向英国人提出任何原则或任何手段,无论多么令人钦佩,您都会发现,英国人的全部努力都是针对于发现困难,缺陷或不可能的地方。如果您对他说剥土豆的机器,他会说这是不可能的。如果在他眼前将马铃薯剥皮,他会宣布马铃薯无用,因为它不会切成菠萝。将相同的原理或同一台机器展示给美国人或我们的一个殖民者,您会发现他的脑海全是在寻找该原理的一些新应用,以及对该仪器的一些新用途。" – 查尔斯-巴贝奇(Charles Babbage),1852年

早在1852年,查尔斯-巴贝奇(Charles Babbage)就能看到衰败的症状,并从中推断出未来的表现。通过这样做,他完美地描述了指责的沟通风格,这种风格出现在"衰败"的组织中,无论是国家还是软件工程组织。什么是"指责的沟通方式"?为什么在系统开发中如此重要?【指责的沟通方式,也严重影响着家庭关系】

什么是一致性?

一致性是一个概念,它描述了内部和外部之间协调一致的人类体验 – 思想和感觉(内部),所说的话及如何说(外部)。

为了在世界上实现一致性的运作,您需要考虑三个普遍因素:自我(内部世界),他人(直接外部世界)和上下文(事物、结构、过程、法律和文化,更大的外部世界)。

  • 自我:您必须考虑自己的需求和能力。假设您是一位不信任任何人的判断的经理,因此您尝试参加每次技术会议。这样做可能会使您的所有可用时间都超负荷,从而无法执行管理工作,或者在任何情况下都无法做出真正的技术贡献。(或者如果你是一位不信任儿子的父母,每次和儿子沟通的时候都是持有怀疑否定的心态,那么沟通就会非常吃力。)
  • 他人:您必须考虑其他人的需求和能力。例如,如果您是一位程序员,编写可读代码的时候拒绝打扰,那么对代码的测试和维护将是一个巨大的负担,因为这是不可能。
  • 上下文: 您必须考虑操作环境的实际情况。 例如,如果您是一位经理,坚持使用不再具有处理任务能力的旧设计,那么不管每个人的工作多么辛苦,您的项目都可能注定要失败。 或者,如果您是一家初创公司的经理,并且花了很多钱,好像该公司拥有10亿美元的现金余额,那么您的组织可能在软件产品投入市场之前就已经倒闭了。

一致性是最基本的诚信,因此对项目及其中的每个人都具有巨大的价值。没有诚信,我们就无法建立信任。没有信任,我们不会感到安全;没有安全,我们很难做到一致性。因此,一致性可以在一个强大的增强回路中强化一致性,从而提高按时、在预算范围内构建高质量产品的机会。

相反地,同一循环会导致不一致,从而加剧不一致。如果一个项目被允许走下坡路,信息的完整性(integrity)就会被破坏。很快,人们都不可能知道真正发生了什么。这样的项目总是失败的,而当它们失败时,总是发现它们保存着两套"书"(这里的“书”指的是信息)。他们的外部形象与他们的内部形象不一致,所以项目死了。更糟糕的是,可能永远活着 – 活死人(the living dead)。

如果一致性对于项目成功是如此重要,那么为什么不是所有项目都一致呢?原因之一是一致性是有代价的。另一个是,一致性通常会带来风险。风险的水平在某种程度上取决于所显示的一致性程度(心理或情感)。

精神上的一致

在美国,相对容易地表达我们的思想而无需过多地承担责任 – 言论自由是该国赖以建立的基础。即使这样,“大声说出来"也可能要付出代价。例如,与同事或当权者在错误的时间发生分歧,可以使我们迅速走上隔离、谴责、减少机会和微妙的关门之路。因此,我们都知道了对在哪里和对谁说的话要小心的重要性。说错话会引起激烈的辩论,然后是关于谁对谁错以及谁好谁坏的声明。到那时,我们已经基本失去了增进理解和有效沟通的可能性。

情感上的一致性

在我们的文化中,情感主要用于体育赛事、庆祝活动、葬礼、临近死亡的经历,深刻感受的精神体验主要体现于战斗以及与亲密的他人之间的交流(可能是小孩或老人)。我们甚至对自己的感觉也会有很多感觉(感觉的感觉),其中最强烈的感觉与羞辱和尴尬有关。感觉是个人的,并且贴近我们的内心,在那里我们温柔而脆弱。难怪我们所有人都变得如此娴熟地​​否认自己的感情,这必然使我们不一致。

假设您是一个开发人员,害怕您无法兑现承诺,从而无法交付产品。您试图告诉您的经理您的恐惧,但是他毫不犹豫地告诉您,如果您不表现出更多的信心会怎样。“你为什么这么消极?你不是团队的一员吗?” 保护自己免受此类负面反应的一种方法是生活在自己的头脑中。也许您会说:“这只是一个估算;我不同意它,“这意味着您不会受到伤害,因为您已经与自己保持足够的距离,可以抵御可能暗示拒绝的任何事物。但是,尽管您否认对经理的恐惧感,但还是感觉到了,被压扁了。您可以背弃自己的想法,但始终保持自己的立场。而且,当然您一直是不一致的。

当您分享自己的感受时,您的内心被暴露在外在世界中 – 暴露在其他元素中。当您害怕并表达恐惧,同时又要考虑他人(您的经理)和上下文(项目)时,您就变得与众不同。您在这里遇到的关键问题是:“我可以分享自己的想法并且仍然可以控制吗?” 如果您的项目环境受到指责,那么如果您说实话,就有可能取消您的控制权 – 因此,对您的想法撒谎的诱惑会增加。这就是为什么责怪文化会导致"双重后果”,也就是导致失败的原因。

什么是指责?

在一致性的组织中,您的经理问:“您的项目进展怎么样?” 您会回答:“恐怕我不会按时完成了。” 这开始了一个解决问题的讨论,你们两个都在其中制定了新的计划,以使项目重回正轨。但是,在指责的组织中,您的经理可能会告诉您,只有劣等人缺乏信心。在这种情况下,解决问题将被避免指责所取代。

从作者的角度来看,一致性的交互作用不是很大。人们只是明智地采取行动,互相体贴,完成工作并享受所做的事情。这种行为可能不如肥皂剧一般的场面,您的经理发脾气而你在角落里哭泣,但这绝对是一个好的项目。

并不是说指责文化会以一种戏剧性的,指责的方式进行每一次互动。在通常情况下,应遵循一致性的应对方法,但如果情况总是很普遍,我们就不需要管理人员。当自尊心低落时,它们会以更加明显的、不协调的典型应对方式表现出来:指责,安抚,过分合理的爱或恨,无所作为。我们不能在简短的文章中解决所有这些问题,因此让我们讨论指责,也许是应对方式中最常见、最直接的破坏方式。

在压力下,人们往往会失去平衡,这三个基本要素可能会被忽略,从而导致一种典型的不一致的应对方式。例如,当人们不考虑他人时,他们就会陷入指责状态。这是您在软件组织中可能会看到的典型的指责行为(斜体字会以这种说话方式强调 – 因为句子中的多个强调字是指责的语言符号):

经理,因为程序员迟到了一次会议:“您总是迟到。您永远不会他人表示任何考虑。”

为什么这不一致呢?如果经理真的感觉到并认为程序员总是迟到并且不考虑周到,那么她是否就这么同意呢?是的,但这不是这位经理所说的。她没有说:“给我的印象是你总是迟到我的会议。” 取而代之的是,她把迟到的感觉说成是科学事实,从不提供程序员可能会有不同印象的可能性。她在会议中总结了经验,就好像这些经验必定适用于所有会议一样,从来没有考虑过她的经验可能不是唯一重要的经验。

如果经理真的感觉到并认为程序员总是迟到并且考虑不周全,她可能会说:“我认为您总是迟到,而且我觉得您没有考虑过我和其他人。这也是你的看法吗?” (并省略强调的单词。)甚至更好的管理风格是使程序员有机会在进行解释之前提供不同的看法。至少,这可以防止在以下情况下的尴尬:

经理,因为程序员迟到了一次会议:“在我看来,您总是很晚。这也是你的看法吗?”

程序员:“是的,我对此感到难过。我总是迟到的原因是,我必须为死于白血病的9岁儿子献血,而他们唯一的一次捐赠就是在这次会议之前。”

经理:“对你儿子感到抱歉。我不知道 让我们找出一个新的会议时间表,这样您就不必迟到了。”

更笼统地说,它考虑到除了该经理之外,还有其他考虑因素。例如,程序员可能有来自与客户的会议,即与经理会议重叠的定期安排的会议。

但是,如果程序员真的总是迟到而又没有合理的解释怎么办?经理不是有权指责程序员吗?并非如此,因为这种情况与权利无关,而与完成项目有关。为此,使用非指责的对抗与不可接受行为有关的事实,可以最有效地解决该问题。通过前述的指责,管理者使沟通保持清晰和开放,从而最大程度地提高了程序员接收预期消息的机会。而且,收到预期的消息会最大程度地解决问题(尽管不能保证)。

指责时,解决问题的可能性较小,因为案件的事实成为次要问题 – 指责的主要问题是"谁重要,谁无关紧要”。当指责时,一个人实际上是在说:“我就是一切,你什么都不是。” 当然,这种立场不是来自真正地思考"我就是一切”,而是相反。将注意力转移到另一个人身上 – 并经常用手指指责–这是一种自我保护的工具,可以使其他人从抱怨者的不适感中分心。

敏捷漫画 011

团队的问题

敏捷漫画:远程办公被错误地归咎为团队协作问题的借口场景

  • 团队进展得怎么样?
  • 实际上并不太好;团队遇到了不少问题。比如……
  • 比如冲刺计划(sprint planning)之前梳理工作;冲刺评审(sprint review)的时候获得有用的客户反馈;团队都同意一个有意义的DoD(完成的定义)【这些问题的原因是什么呢?】
  • 因为现在是新冠疫情,我们都是在远程工作……

作者评论

不要认为你的团队目前像世界上大多数人一样远程办公为借口,认为保持团队合作是平淡无奇的。在这种没人能见面的时代,保持并进一步发展敏捷团队的团队精神比以往任何时候都更为重要。有了合适的在线工具,例如Miro,Zoom,Slack,Teams,Skype或其他工具,这变得可能了。但是,拥有正确的在线工具仅是答案的一半。练习“远程的团结”是另一半。

实现此目的的方法包括:在工作时间内不断开放所有团队成员的交流渠道,以模拟他们坐在一起;安排频繁的虚拟游戏会议以增强团队合作精神并一起玩乐;以及与特定同事计划在线聊天,以保持这些宝贵的临时讨论和交流机会。因此,如果您是Scrum Master或敏捷教练,现在是时候真正踏上第一步,因此即使在这些困难时期,您也可以帮助您的团队成长。

译者评论

疫情大前提下,团队合作变得更难。原来是远程团队还好,原来在办公室的团队,大家都不得不进行远程协作。这对于传统行业更为挑战。所以选择一个(套)好的工具是大前提,其次需要更多的设计团队沟通环节。因为原来团队合作,很多是发生在办公室,潜移默化(悄悄)的。而现在的团队合作,需要提前设计好固定的沟通时间、固定的沟通方式、固定的沟通渠道等等。

最后问一句,你的团队还好吗?

读者评论

对于今天的漫画,你有什么想说的呢?

原文链接

谷歌OKR指南:如何使用OKR制定目标(含OKR模板)

获取OKR模板

介绍

研究表明对目标做出承诺有助于提高员工绩效。更具体地说,研究显示设置具有挑战性的、具体的目标能进一步加强员工实现目标的参与度。谷歌常常使用“目标和关键结果”(OKRs)来制定令人鼓舞的目标并跟踪进展。

OKRs概述

  • 目标是鼓舞人心的并且可能会让人感到有点不舒服
  • 关键结果是可衡量的,易于用数字记分(谷歌使用0-1.0分的数值范围)
  • OKRs是公开的,这样组织内的每个人都能看到别人在做什么
  • OKRs分值的 “最佳点”是60% - 70%;如果一个人一直都能完全实现目标,那么他的OKRs就不够鼓舞人心,他需要考虑一个更大的目标
  • 较低的分数应该被视为有助于改进下一个OKRs的数据
  • OKRs不等于员工评估
  • OKRs不是一个共享的待办事项清单

实践过程中,应用OKRs和其它目标制定技术有所不同,因为OKRs旨在制定令人鼓舞的目标。使用这种方式时,OKRs可以让团队专注于大赌注,完成比团队认为可能的更多的任务,即使他们没有完全达到既定的目标。OKRs帮助团队和个人走出他们的舒适圈,对工作优先排序,从成功和失败中学习。

学习(删减的)OKRs历史

正如英特尔前首席执行官Andy Grove(安迪格鲁夫)在他的书《高产出管理》(High Output Management)中所解释的那样,要想成功建立像OKRs这样的共享目标体系,需要回答两个问题:

  • 我想去哪?这个答案提供了目标。
  • 如果我要到那里(目标)的话,我该如何调整自己的节奏?这个答案提供了里程碑,或关键结果。

谷歌早期的投资者,现在的董事会成员John Doerr在英特尔时从Andy Grove那里了解了OKRs。Doerr说他加入英特尔时,公司正在从一家存储器公司向一家微处理器公司转型,Grove和管理团队需要一个方法帮助员工专注于一系列优先(重要的)事项,以便顺利转型。OKRs帮助他们沟通优先事项,保持对齐,并实现转变。

几十年后的2000年初,Doerr向谷歌的领导层介绍了OKRs,后者(谷歌的领导层)看到了它(OKRs)的价值,并在接下来的几个季度里开始进行尝试。现在,谷歌制定年度和季度的OKRs,并且在每季度召开全公司会议来分享OKRs以及对OKRs打分。

OKRs的应用远不止于硅谷,而是各种各样的组织都在应用。《财富》100强企业西尔斯控股公司向2万名员工推行了OKRs,看到其对销售业绩和个人业绩产生了积极影响。

OKRs和拉伸目标

谷歌经常会制定一些看似不可能的目标,有时称为“拉伸目标”。制定无法实现的目标是很棘手的,因为这可能被视为组建一个失败的团队。然而,这些目标往往能吸引最优秀的人才,创造最令人兴奋的工作环境。此外,当目标高远时,即使失败了目标也能带来实质性的进步。

关键是清楚地传达拉伸目标的本质以及什么是成功的门槛。谷歌喜欢制定OKRs的成功是达到70%的目标,而完全达到这些目标则被认为是非凡的表现。 这样的拉伸目标是实现长期卓越成就的基石,也是“登月计划”。

将OKRs引入你的组织

OKRs的一个重要部分是透明度。把OKRs引入到一个组织中时,弄清楚它们是什么,为什么会有用,以及将如何使用才会有帮助。研究表明当人们对他们的目标做出承诺时,绩效会更高,因此让所有人都参与进来是很重要的。

介绍OKRs的小贴士:

  • 什么是OKRs?覆盖什么是OKRs以及它们是如何工作的基本知识。
  • 为什么使用OKRs?回顾组织现在制定目标的方式,以及这种方式的限制和问题。
  • OKRs如何工作?解释时间线,对每个人的期望,主要的里程碑,以及人们将如何负责。
  • 仍对OKRs存疑?留出提问的时间,特别要强调要提出任何的疑问。

一致性。 一旦组织知道了它关注的是什么,如何衡量成功,个人就更容易将他的项目和组织目标关联在一起。

原则&优先级。 对公司里的任何一个人或团队来说,要对一个好的想法,一个有价值的项目或一个必要的改进说“不”是很难的。一旦所有人都对最重要的目标是什么达成一致,对不那么重要的目标说不就简单多了。说“不”不是一场政治或情感上的辩论,而是对整个组织已经做出的承诺的一种理性回应。

沟通。 OKRs应当在组织内部公开,这样每个员工都知道组织目标以及成功的度量标准。一次采访中,前谷歌人、前推特首席执行官Dick Constolo被问到“你从谷歌学到了什么并应用在推特上”时,他这么说: “我在谷歌看到的,确定也应用到推特上的是OKRs-目标和关键结果。OKRs是一种很好的方法,它可以帮助公司里的每个人了解什么是最重要的以及如何衡量什么是最重要的。从本质上讲,OKRs是一种很棒的沟通战略和衡量战略的好方法。这是我们使用OKRs的方法。公司成长的时候,最困难的事情就是沟通。沟通是非常困难的。OKRs是确保每个人都了解你将如何衡量成功和战略的好方法。”

制定目标和设定关键结果

制定目标时,谷歌经常从组织级OKRs开始,用3~5个目标和每个目标的三个关键结果来对齐优先级。成功的OKRs常常是由自上而下和自下而上的建议相结合,这让组织中的每个人都可以表达他们认为值得花时间去做的事情,以及怎样最好地安排他们的时间。

制定目标的小贴士:

  • 只选3~5个目标–过多的目标会导致团队过度扩张(over-extended)和精力分散。
  • 避免使用那些与追求新成就无关的表达,例如“继续招聘”,“保持市场地位”,“持续做X”
  • 使用描绘终点和状态的表达,例如“攀登这座山”,“吃5个派”,“交付特性Y”。
  • 使用有形的、客观的、明确的术语。对于观察者来说,目标是否已经实现应该是显而易见的。研究表明,更具体的目标可以带来更好的表现和更高的目标达成。

设定关键结果的小贴士:

  • 每个目标确定三个关键结果。
  • 关键结果表明可衡量的里程碑,如果实现,将直接推进目标的实现。
  • 关键结果应该描述效果,而不是活动。如果关键结果包含“咨询”、“帮助”、“分析”、“参与”这样的词,那么是在描述活动。相反,要描述这些活动的效果,例如,“在3月7日发布客户服务满意度的水平”,而不是“评估客户服务满意度”。
  • 可衡量的里程碑应该包括完成的依据,这些依据应该是可用的、可信的和易见的(discoverable)。

避免OKR书写错误

设定OKR,即制定明确的目标,和可衡量的、达成一致的结果,能推动团队取得好的成绩并且使组织专注于最重要的优先事项。写得不好的OKRs会产生混乱的策略,破坏内部指标,导致团队专注在维持现状。

在设定OKRs时,尽量避免以下陷阱:

  • 错误沟通拉伸目标的OKRs–制定拉伸目标需要在目标的交付团队和其他对拉伸目标OKR的一部分工作有依赖的团队之间进行认真地沟通。如果你的项目依赖于其它团队的目标,确保你理解他们的目标制定哲学。如果他们正在使用拉伸目标,你应该期待他们能交付70%所制定的目标。
  • 常态OKRs–OKRs通常是基于团队相信在不改变任何正在做的事情的即可实现来制定的,而不是基于团队或客户真正想要的。为了测试这一点,将团队当前的工作以及新请求的项目按照价值与所需的工作量进行堆栈排序。如果OKRs包含了最高投入工作外的任何东西,那么他们只是常态的OKRs。减少低优先级任务上的投入,重新分配资源到高优先级OKRs上。有些目标会一个又一个季度保持不变,如“确保客户满意度超过XX%”,如果这个目标总是优先级很高的话,也是可以的。但关键结果应当演变,以推动团队继续创新,变得更高效。
  • 沙袋战术–那些不需要整个团队带宽就能实现所有OKRs的团队,可能是在囤积资源,而不是推进团队,或者两者都有。
  • 低价值目标–OKRs应该承诺明确的业务价值,否则,没有理由花资源去做。“低价值目标”即使全部实现了,对组织也不会有太大的影响。问一下,OKR能否在合理的情况下,不提供直接组织利益而得到1.0的分数?如果是的话,重新定义OKR,把重点放在有形的利益上。
  • 目标的关键结果不充分–如果一个既定目标的关键结果不能代表目标完全实现该目标所需要的全部结果,就可能出现OKR的意外缺失。这会导致延迟发现资源需求以及发现目标不能如期完成。

设定团队的OKRs

尽管方法很多,但首先致力于组织目标是有帮助的,这样团队和个人就可以为那些大的目标服务时制定自己的目标。这有助于创建整个组织的一致性。下一个决定是组织中有多少团队级别的OKRs工作–每个部门、单位(功能组织)或小组都需要OKRs吗?

对团队级别的目标而言,要认识到并不是每个组织级别的OKR需要反映在每个团队OKR中。一个团队的OKRs可能只关注一个组织级OKRs。但团队级OKRs会至少和一个组织级OKR之间有关联。

制定团队级OKRs的一种方法是让所有团队领导一起制定目标。在谷歌,团队领导有时会根据公司OKRs来列出下个季度的优先事项。创建优先事项时,关注组织OKRs是有帮助的,并且要检查: