使用现代敏捷和 OKR，跳出“特性工厂”思维

本文要点

• 带着瀑布式目标使用敏捷会让团队变成不关注价值交付的“特性工厂”

• 团队可以通过使用基于价值的 OKR 持续交付价值

• 公司可以通过专注于结果和证据迅速实验和学习，而不是仅凭个人观点。

• 为促成自治，使人们更加卓越，团队的目标必须从“特性交付”转变为“实现基于价值的 OKR”。

• 公司营造安全感的先决条件是，营造心理安全的环境、彻底缩短他们的验证周期、将 OKR 周期作为最终时间期限。

大多数公司采用敏捷是为了交付。大规模框架通常没有什么帮助，因为他们采用的是阻力最小的方式，并以大量实践专注于软件开发的改进，而不是专注于实现业务敏捷。

就设定目标而论，瀑布式的命令和控制思维仍是惯例：组织使用年度、自上而下的过程设立一组静态目标，而这根本就是与敏捷相违背的。

“层层拆解”目标是标准的公司做法。你能想到另一个比“层层拆解”更贴近自上而下瀑布式的例子吗？

瀑布式的目标和度量将团队转变为不专注于交付价值的“特性工厂”，许多开发人员只是“坐在厂房里，草草生产特性，然后发布上线了事”。

Marty Cagan 强调说，特性工厂错失良机：“团队只在那儿关注完善细节，编码测试，而对更大的环境没多少了解，更不必说始终坚信其实有适当解决方案了。”也就是说，最接近工作的人对决策没什么影响力，无法制定帮助客户或利用已有解决方案的决策。

不是让团队自主去打造伟大的产品，而是以由经理审批项目为中心，这是错误的敏捷版本。

Frederick Taylor 看到他的技术至今仍在沿用应该会很高兴吧。“每个工人的工作完全是由管理者至少提前一天安排好的”，他于 1991 年在科学管理的原则中写道。

在从科学管理走向敏捷的路途中，团队仍是交付高管预先规划好的项目和特性。这种瀑布式的计划模型减缓了公司的速度，不仅增加了风险和浪费的情况，同时还很难适应变化。

我们怎么还能称之为敏捷应用呢？实践者清楚，使用敏捷去交付瀑布式的计划没多少好处：该报告表明，调查者中有70% 的人认为他们的团队与组织其他团队关系紧张，同时敏捷应用失败中有63% 的原因是公司文化和哲学与敏捷价值不一致。

更好的方式

不妨拥抱现代敏捷的四个原则，跳出特性工厂的思维。然而，我们该如何去应用它们呢？从现代意义上来说，我们如何“成为”敏捷？

针对业务敏捷，有一个切实可行的工具，如果正确使用，会对四个现代敏捷原则的应用很有帮助。这个工具就是 OKR (目标和关键结果)，是 Intel、Google 和 Spotify 用来设定目标的框架。

这与传统计划制定方法有多大的差异？OKR 是频繁的设定和评估，通常是按季度来。此外，与从高管往下层层拆解相比，OKR 是双向的：在保证与与公司目标相一致的情况下，团队设定他们自己的 OKR，然后与管理者一起用冒泡法签署它们。

这种方式为团队提供了一个更加吸引人的环境，对于自己辅助设立的目标，他们现在能感受到相应的责任感，他们启动快速跟踪，每周一个周期。

设立有挑战性的目标是 OKR 的基本原则，这能带来结果和创造力。正如 Amantha Imber 所报道的，研究表明如果我们把人才安排在有挑战性的岗位，会有 67% 的人表现出超出平均水平的创造力和革新能力。

Dan Montgomery 说得好，“OKR 即组织性敏捷的日常驱动。”

OKR 如何支撑现代敏捷的四大原则？

持续交付价值

扩展敏捷规模很难，因为扩展交付规模并不放大价值。Lean UX 和 Sense 和 Respond 的联合创始人 Jeff Gothelf 说。

Felipe之前在 InfoQ 写道，敏捷宣言是不适当的。第七个原则，“工作的软件是首要进度度量标准”过时了，且容易被人误解。每次当敏捷人士必须说明大家说交付的文档还不够充分时，就会想到它。

“工作的软件是首要进度度量标准”这一陈旧的假设还停留古老的认知上，它相信所有可工作的软件都是有价值的。我们现在清楚，事实并非如此。我们需要提供有价值的软件，正如该宣言的第一原则所说。现代敏捷教我们专注于持续交付实际的价值以帮助我们的客户更加卓越。

现代敏捷清楚，“完成”只在意是否增加了价值，正如John Cutler 所强烈质疑的：“经常忘记最右边的列，它还有效吗？”【译者注：即待办事项表中最右边的一栏：达成的目标结果】

我们需要放弃基于任务的概念，比如完成的定义、燃尽图和生产速率，而去关注价值。我们需要以成功标准取代接收标准。

尽管宣言的措辞容易让人误解，但是它的作者中有些人已经明确声明需要专注于结果：

战胜瀑布式的关键在于认识到敏捷人士应更重视结果而非特性。特性列表是个有价值的工具，但这不意味着它就是最终目标。真正重要的是整体结果，我认为即是给客户提供的价值。 Martin Fowler 说。

因为它只是个框架，OKR 可以被用于度量输出。然而，仅仅测量活动不是 OKR 的合理用法，不符合现代敏捷。

实践现代敏捷需要频繁设立和评估基于价值的OKR ，用以度量向客户或组织交付的价值。

举两个能清楚说明这种差异的例子：

通过采用基于价值的OKR，团队可以专注于价值交付。然而，如何能够“持续地”保持下去呢？

按季度的OKR 周期能起到交付价值的最终时间期限的作用：每个团队必须在该季度创造价值，改进选定的关键业绩。团队专注于假设的检定与实验以及迅速的学习，而不是大规模的发布，它带我们走向下一个原则。

迅速的实验和学习

老式敏捷不是以数据驱动，而是由HiPPO 原则驱动的：即谁拿的钱多，谁的观点最重要，在《重新定义公司：谷歌是如何运营的》一书中对此有精彩阐述：

老式敏捷让大家形成一种错觉，在迭代回顾和演示期间向干系人展示是过程中一个适当的措施，许多公司困顿于此错觉中无法自拔。

如果我们专注于结果和证据而不是个人的意见，那么唯一能做的就是迅速实验和学习。

OKR 用可度量的实验取代了 HIPPO，使团队可以总结完善。它使团队可以采用假设驱动开发之类的实践， Barry O’Reilly 是这样说的：

1. 我们认为 < 这项能力 >

2. 将带来 < 这个结果 >

3. 当 < 我们看到一个可度量的信号 > 时，就有信心继续进行了

如果我们的目的是商业结果，让团队朝着这个目标自由实验，那么小投资也可以带来令人惊叹的结果。有这么一个例子，一个 20 分钟完成的特性“ Know Your Company ”带来了三倍的销售，而 Eric Elliott 交付了“一个使他老板每月赚1 百万美元的Jira ticket ”。

使大家卓越

如果你只是在让工程师编写代码，那么你只得到了他们一半的价值。 Marty Cagan

特性工厂的一个潜在假设是，团队没有能力决定要做什么。这一方法基于的是科学管理中计划与执行分离的原则，它非良策，容易失人丧失动力。

现代敏捷原则“使人卓越”的理论基础是让大家有机会贡献他们最好的想法。

如果你的团队对做什么保持缄默，只是在完成一个又一个的特性列表，那么他们就不能称之为卓越。而且，你也无法得到他们全部的贡献。

为真正使自组织团队自治，你就得让他们自主决定如何实现预期的价值目标。团队的目的必须从“交付干系人想要的特性”改成“实现协定的基于价值的 OKR”。

Henrik Kniberg 有个很好的幻灯片特别强调了这种目的的切换：

在传统敏捷方法中，因为有人说要“Sam”，所以团队做某些事。另一相反的情形，是团队仅仅因为“喜欢”而去做某些事。

为使人卓越，我们需要第三种观点。团队有决心并清楚他们对事情成败有影响。他们能够看清他们的工作与公司战略的关系。

安全感的先决条件

谷歌的研究团队发现，成功团队有别于其他团队的前沿技术就是心理安全：我们在团队中可以毫无顾虑地去冒险吗？我们可以克服恐惧大胆地说出可能有争议的想法或问题吗？

OKR 的其中一个基本原则是团队不应该惩罚追求宏伟目标的人。通过把OKR 与薪酬和升职分离开，公司可以创建心理安全的环境，让人们可以在此尝试大胆的想法。

然而，达成安全感的先决条件是，公司还必须彻底缩短他们的验证周期。在精益创业发布后的几年，大多数组织仍是忙忙碌碌几个月而未向最终用户交付任何成果。

他们掌控团队而将自己暴露于风险之下，团队中的大部分人都是开发人员，他们盲目地增量交付瀑布式待办任务到准生产环境，却没有任何其他形式的验证。

为降低风险公司需要停止盲目地遵从计划，从持续集成演进为持续交付和持续验证。

如果你什么都不学，那么就只有遵循计划这一条路可走。 Kent Beck

更糟糕的是，这些计划大多数都是由产品负责人或经理一手制定的，他们甚至有时都没看看产品数据，那怎么能做出好的决策？这种情况令人有些泄气和不安。《学习精益软件开发》的作者 Mary Poppendieck 写道：

也许，敏捷开发实践最大的短处是团队决策做什么的方式了。[……] 大多数时间，都没考虑由开发团队或 DevOps 团队来回答这些问题。 Mary Poppendieck 说。

OKR 则不同，它的做法是确保团队协作设定目标和决定做什么，并采用较短的反馈周期，降低风险和浪费，从而带来安全感。

就像 David J Bland 所写的，“年度计划和预算的过程与随市场而变的做法相悖……领导最终认识到，要使他们的组织更加敏捷，他们就需要着手调整这些基本职能。”

总结

正如其他计划框架一样，OKR 并不完美，可能会被滥用。我们相信，现代敏捷的四大原则对指导 OKR 实践很有价值，助你切实可行地走上现代敏捷之旅。

将现代敏捷与 OKR 适度结合应用是个轻量级的、愉快的方式，能帮组织让大家取得卓越的成果。

浏览 modernagile.org 和 felipecastro.com 可获得更多的现代敏捷和 OKR 思想。

关于作者

Felipe Castro是一名 Goal Hacker。他帮助组织通过采用 OKR 转变他们使用目标的方式。他发明了“设立—保持一致—达成”周期，是一个避免 OKR 大多数常见陷阱的简单方法。Felipe 在 felipecastro.com 开通了博客。

Alexandre Freire Kawakami 是一名程序员、教练、科学家、学者和老师，他喜欢打破敏捷软件交付的界限。作为 Industrial Logic 的总经理，他专注于交付高品质软件和服务以解决客户的实际问题，提供工具帮团队走向卓越。

查看英文原文： Transcend the “Feature Factory” Mindset Using Modern Agile and OKR