【作法】

将 Sprint 冲刺的目的定成目标 Object, 然后为这个目标设定三个关键的结果（key result），每个结果都必须能够量化成数据（由0.0到1）, 对那些不易量化的结果则预先设定达成何种成果就给它相对的分数，并以难易度来给分。

（给分依据：很难几乎不可能达成的给1分，必须很努力才能达成的给 0.7，稍稍努力就能作到的给0.5，循正常工作就能达到的给0.3，而完全没作到的就给0分）。

然后在「计画会议」时由团队一起来设定关键结果，再在最后作「回顾会议」时一起来打分数（花上3～5分钟）。

然后在每天的站立会议时过一下团队进度与预期目标的达成状态，进行检讨。

这么作你便能运用 OKR 的设定来量化 Sprint 的目标了。

啰嗦一下:

Sprint 的结果无法被量化一直是管理人员的困扰，我们也都相信完成故事点的多少并不能做为开发效能的依据（注1，这里挑战了你对敏捷的认知，不要太迷信于故事点），而故事点的多寡最多只能用来看待团队所面临负荷大小的参考而已。但在日常的 Sprint 运行上，我们又常常会面对到一些需要量化才能回答的问题，例如:

• （高层总是担心）

团队到底是表现得好还是不好?

我们作对了吗? 现在的开发方式需要改变吗? 要怎么变?

• （Scrum Master 则常常收到）

PO 经常抱怨开发团队只会埋头苦干，没有商业价值的观念。

团队每个 Sprint 周期，都是以完成所有工作为目标，而不是以达成商业价值为目标。

老实说：这些问题都很难给出明确的答案，即便是团队现在显得工作的很愉快，自组织的味道也逐渐在成型，但这还是不足以回答他们到底表现得如何?接下来又会往哪里去的问题。面对这些疑惑，运用 OKR（Object & Key Result） 正好可以拿来正本清源。

目标导向理论是激励理论的一种。是要求领导者排除达成目标的障碍，使其顺利达到目标，并在过程中，给予员工满足多种多样需要的机会。

– wiki

OKR 是一种目标导向的引导工具

---

它是在敏捷宣言诞生之前就存在的一种敏捷理念，安迪 · 葛洛夫（Andy Grove） 于1990年在担任英特尔执行长时所推行的一种简化版的目标管理法（MBO 注 2. 来自管理学大师 彼得 · 德鲁克），是一种比 Scrum 还要简单的引导理论，但却能够成功的解开 Sprint 难以度量的问题，还能够依据成果导向来激励团队开发的冲刺效果，所以我把它跟 Sprint 的过程画在一起，让我们来看看如何融合OKR 于 Sprint 的冲刺过程中的做法。

为一个 Sprint 冲刺设定目标及 Key Result

首先；让 OKR 的目标与 Sprint 的冲刺目标对齐，让「关键结果」成为DoD.

它会让 Sprint 冲刺的目标更加明确，有很好的聚焦效果，工程师也会因此而开始关注 Sprint 所要达成的商业价值。

做法是让团队在 Sprint 计划会议时依据Sprint 所要达成的目标，团队一起定下「关键结果」Key Result，这样作可以让这个冲刺期间能够更加关注项目的定义完成 DoD（Definition of Done），这会让每个工作单完成的定义，变得更为明确。

上图描述的是将专案分成为多个 Sprint 的目标，然后在计画会议时针对这个目标来制定它的关键结果 Key Result，再持续用它来做为评估是否达成目标的依据。

好处是：工程师会依据目标是否达成而开始关注目标的商业价值，它聚焦了Sprint的冲刺目标，当目标达成时，剩余的工作单就值得讨论是否该抛弃或下一次再作了。

Object : 我们想作什麽？
Key result : 我们如何知道是否已达成了目标.

– 开始时不能忽略的提问

每日检讨；让团队成员以一周为单位设立个人目标。每周周一赋责，周五庆功，并于每日的站立会议加入报告第四件事: 也就是目标达成的状态说明。能够即时更新检讨实施的成果，便于修正改善。

而缺点是每个人都设定自己目标，常常容易导致团队目标失焦。

因为目标设定多了、太细了花太多时间在目标设定上而少了真正的工作时间。

人们很容易便会只专注于自己的使命，而忽略了团队的使命（建议先实行团队的OKR，待团队成熟后再来尝试个人的OKR，因为个人OKR往往会被导向个人绩效的评核，容易走偏了，请谨慎为之）。

OKR 的神奇力量，来自0.7的给分标准

好的 KR 应该是定量的、有挑战的、具体而有驱动性的

---

好的关键结果（Key Result）可以协助我们衡量达成目标的距离，然后进行快速的检讨和进行行为的修正(一般称这个动作为复盘，game review 注3.)

如何制定高效 OKR 的 CRAFT 法则

一个提前完成的 Sprint，一个以 OKR 驱动提前完成的 Sprint

---

如果我们能够不用作完全部的需求就已经达到 Sprint 所设定的目标（商业价值）时，就叫它是一个「以OKR驱动提前完成的Sprint」，它因为已经达成目标了，所以就提前结束了(剩下来的需求，就由团队一起讨论是抛弃它呢?还是要把它继续做完)，Sprint 完成了，但不是团队作完了所有的需求，试问这有什么差别吗?

这是成功 Scrum 团队的一大步，它代表了Sprint是以商业目标驱动来决定Sprint 的开发周期的，它超越了1到4周的固定周期式的开发方式，而是视所要达成的目标来调整开发周期，团队具有一种意识能够判断开发功能与商业价值之间关连性的能力，才能够摒弃多出来的需求单。

这是一种理想化达成的Sprint 冲刺目标。也就是不以作完所有需求为目标，而是以达成商业价值为依归。

结语

---

在过去自己所带领的团队里，PO经常想尽办法与开发团队进行沟通，就是希望工程师在开发时能够以商业目的为主来进行产品新增功能的开发作业，但最后总是落到抱怨开发团队只会埋头苦干，一点商业价值的观念都没有的地步。

这一点，其实是不能责怪工程师的，因为将使用者故事拆分成一个个工作（Task）的过程，就是要简化需求让它成为单纯的功能项目，只有如此工程师才能专注的来进行开发工作。

因此要求工程师同时又能兼顾商业价值观是一件二难的事，但有了OKR的目标导向规范，不但这个问题得以克服，更由于对 Key result 的设定，让我们能够用数量化来衡量目标的达成与否，也间接的得以评估团队的状态，真是一举数得。

OKR 是一套明确可追踪目标及其完成情况的管理工具和方法，它易懂又简单，但实施起来需要先弄清楚许多事情。那些事呢? 完全看你要在哪一种层级来运行OKR。

如果把它运用在公司层级，则可能需要先弄清楚公司的使命、愿景。

如果运用在Sprint的冲刺上，则可能需要先弄清楚专案的目标、方向，前提是在一堆待完成的目标裡识别出现在最需要聚焦的一个，然后设定偏高的衡量标准，在激励自己尽全力去达成它。

最后补上OKR的定义如下: （此为 Paul R. Niven和Ben Lamorte的版本）

OKR 的定义说明

注1. 故事点的多少并不能做为团队开发效能的依据.（http://www.scrumcn.com/agile/scrum/19837.html）

因为故事点只是估算时的参考值，无法换算成绝对的数值，因此不能成为依据。

注2. MBO（Management by Objectives）来自管理学大师彼得·德鲁克 Peter Drucker 在上世纪60年代即提出来的MBO的思想

注3. 复盘，game review

复盘是围棋中的一种学习方法，指的是在下完一盘棋之后，要重新摆一遍，看看哪里下得好，哪里下得不好，对下得好和不好的，都要进行分析和推演。是一种极致的回顾方式。

【补充资料】

仅仅用在专案上，有人又称之 MOKR（ Mission OKR）

参考自《OKR：源于英特尔和谷歌的目标管理利器》，稍加了补充。

一种超越敏捷的激励力量（Google有团队订成0.75，就更有趣了）

如果运用在公司层面上，订定”使命“便成了第一步，应该多参考别人的使命。

参考自《OKR工作法：谷歌、领英等*公司的高绩效秘籍》的好方法