你好，我是黄勇。记得在十多年前，我第一次了解到了“敏捷”的概念，当初我只是把敏捷理解为高效，不过后来才发现，敏捷不只是高效，更多的是适应外界环境的不断变化，并做出灵活调整，这就是我们常说的“拥抱变化”了。

今天，我想和你从“拥抱变化”开始聊起，看看传统敏捷方法所遇到的一些现实问题，以及如何将敏捷与 OKR 相结合，进而发挥出更大的效用。

为何敏捷可以拥抱变化？

在此之前，我先来给你讲讲什么是“敏捷”。其实，敏捷概念提出之初，人们就一直在关注并探讨敏捷的落地问题，首先是《敏捷宣言》的诞生，它正式宣传了“四大价值”这些软件开发方法：

什么是敏捷？

由上述讲述内容可知，敏捷强调个体之间的互动，要求能够发布可以工作的成果，提倡跟客户建立合作共赢，也推崇拥抱变化的思维。

在十多年前来看，敏捷确实是一套先进的方法论，虽然在传统软件开发领域，其实大家更在意的是流程、工具、文档、合同、计划这类不变的东西，但是人们所处的外界环境在不断变化，面对的业务也在不断变化，人们常说“唯一不变的就是变化”。逐渐地，人们开始接受敏捷，并认同它所主导的核心价值。

另外，在敏捷宣言提出后，业界也出现了一些偏实践的敏捷方法，例如：XP 极限编程、Scrum 敏捷方法、看板等。而这些敏捷方法中包括了很多有价值的工具，比如，每日站会、结对编程、代码评审、持续集成、测试驱动、计划扑克等。

Scrum 敏捷方法

尤其是 Scrum 敏捷方法，还提出了团队的角色分工和协同流程。

比如，由 Product Owner（产品负责人）负责维护 Product Backlog（需求池），由 Scurm Master（项目负责人）召开 Sprint Plan Meeting（计划会议）和 Daily Scrum Meeting（站立会议），最后全员一起参与 Sprint Retrospective Meeting（回顾会议）。

实质上，Scrum 敏捷方法的核心思想，就是将不断变化的业务需求放入 Product Backlog， Product Owner 从 Product Backlog 中取出优先级较高的需求并将其放入 Sprint 迭代中，随后定期发布一次迭代，每次发布都需向客户交付可以工作的软件。

此外，Scrum 的会议也在此过程中扮演了重要的角色，不仅跟踪了进度，也能起到计划和复盘的作用。

可见，每次 Sprint 的迭代都是一个固定的阶段，该阶段包括了一些具体的任务，我们通过完成这些任务去实现阶段性的目标。这样一来，基于“任务驱动”的方式看似敏捷，而在实际应用过程中，往往又会遇到一些现实问题。

传统敏捷方法有何问题？

以我们团队为例，曾经使用 Scrum 敏捷方法进行软件开发，不过经历了几次迭代后，我却发现似乎团队伙伴们更关注每次迭代中的任务本身和实现细节，而且技术团队就像一台机器，在周期性地运转，并不断地对外交付客户所需要的成果 —— 代码。

发现问题

技术团队疲于奔命，不过一旦发现自己交付的成果无法体现自身价值时，整个技术团队的士气都会受一定影响。

比如，技术团队完成了 2 周的迭代，上线了一个新功能，但发现上线后 2 个月内都很少看到用户在使用功能，更别说积累大量数据了。

此时，技术团队就会认为产品团队当初接受了业务团队当初提出的“伪需求”，让技术团队花大量精力去做了一件没有意义的事情，长此以往，技术、产品、业务三个团队之间就容易产生一些分歧甚至争吵。我觉得这样的事情不应该频繁发生，而是应该依靠一种机制来解决。

分析问题

既然问题已经出现，那么就不妨仔细分析一下 Scrum 敏捷方法的价值。其实，Scrum 敏捷方法划分出许多 Sprint 迭代，这样操作的价值主要体现在以下几个方面：

让 Sprint 迭代周期更短，更能适应外部环境带来的变化或影响，实现“小步快跑”的节奏。
让 Sprint 迭代变得更有规律性，从而提升团队协同工作效率。
让每一次的Sprint 迭代的目标变得更加聚焦。

那么，迭代周期到底需要多短？如何让每次迭代都更有规律、更加聚焦呢？

解决问题

不难发现，当我们学习了 OKR 之后，很容易就会发现，OKR 和敏捷所提倡的方法类似。同样地，实施 OKR 也是要固定周期、小步快跑、一步一个脚印的。通过团队使用 OKR，可帮助伙伴们围绕团队目标不断努力，做出贡献，让团队精力更加聚焦。

可见，OKR 和敏捷之间存在了大量的相似性，是否能在敏捷中使用 OKR，从而让敏捷迭代的目标更加聚焦，让团队更有激情地去实现所迭代的目标呢？于是，我自行设计了一套基于 OKR 的敏捷方法，下面我将详细介绍它的用法。

如何在敏捷中使用 OKR？

敏捷过程中的许多环节都涉及到开一些重要会议，比如，项目启动时有计划会议，项目执行过程中每天都有站立会议，项目结束后还有回顾会议。此外，敏捷也需要团队内部高度协同。可见，OKR 执行过程中也是类似。

开季度会

在每个季度开始之前，技术、产品、业务三个团队的负责人会在一起开一次重要的会议，在会上主要讨论的是：本季度业务遇到的用户痛点有哪些；业务上优先级最高的需求是什么；要想解决这些需求，能对公司年度 OKR 的哪些方面有所支持或贡献。

接下来，产品和技术团队也会聊聊自己部门季度 OKR 是什么，以及与公司年度 OKR 对齐的逻辑是什么。

最后，大家将在会上决定本季度即将发布几次迭代，以及每次迭代的目标是什么。

其中，会议组织者往往是产品负责人，他将引导大家一起制定出每次迭代的 OKR，以及迭代 OKR 中包含哪些 O，以及能支撑 O 的 KR 是什么。

经验输出

我的经验是，一般设置 2 周 1 次迭代，为了目标更加聚焦，每次迭代 OKR 仅包含 1 个 O。也就是说，每个季度差不多有 6 次迭代，总共将实现 6 个目标。

比如，Sprint1 的目标是提高用户注册率；Sprint2 的目标是提高付费转化率；Sprint3 的目标则是改善程序性能问题；而Sprint4 的目标是解决数据安全问题；Sprint5 的目标是为了解决高并发问题；Sprint6 的目标是为了解决系统稳定性问题。

下面是 Sprint1 迭代的 OKR：

Sprint1 OKR

O：提高用户注册率

KR：
1）每日网站平均 UV 为 10000 次
2）每周吸引新用户注册 1000 人
3）将用户注册率从 0.1% 提升到 1%

在设置迭代所对应的目标时，我们会根据公司年度 OKR 和部门季度 OKR 进行考虑，最终给出一份技术、产品、业务三个团队都认可的迭代 OKR。

深度协同

在每次迭代中，技术团队都要深刻理解产品团队给出的需求文档，并在此基础上拆分为多个任务。

比如，Sprint1 是为了提高用户注册率，我们将重点放在提高潜在用户数和吸引用户注册这两件事情上，而对于提高潜在用户数而言，我们将会在多种不同的渠道上进行引流，包括在网站上改善用户注册入口的用户体验，以及做一些营销工具等小型应用程序。

高度融合

此外，项目负责人会将迭代中的任务与迭代 OKR 中的 KR 进行关联，比如，改善用户注册入口的用户体验将对 Sprint1 OKR 的 KR2 有推动作用。

这也就是说，项目成员在完成自己所负责的任务时，就知道自己的工作对本次迭代有何贡献。通过完成任务来驱动 KR 进度更新，从而促进 O 的完成，这种感受会有效加强项目团队的参与感和成就感，进而产生激励效果。

当迭代发布后，我们将基于此 Sprint1 OKR 对 Sprint1 的目标做出评估，技术、产品、业务三个团队的负责人将在一起复盘本次迭代的过程和结果，最终会看到我们投入了多少成本，又将成本投入到了哪些地方，以及所对应的价值产出。

可见，OKR 与敏捷具有高度融合性，OKR 让敏捷变得更加敏捷。

总结

敏捷虽好，但它更加聚焦于软件开发本身，能帮助技术团队加快开发节奏，以小步快跑的方式去拥抱业务的变化。但是，敏捷毕竟也不是完美的，除了技术团队，其他人不会关心我们用了什么开发方法，而更关心的则是用户需求和自身诉求能否得到满足。

此外，当需求池积累得越来越多时，技术团队将坠入“生产代码”的陷阱中，我们生产的是代码，而不是价值。如何让我们生产的代码变得有价值呢？必须确保我们做的事情是在建立共识情况下进行的。

因此，我们需要在敏捷过程中学会管理迭代的目标，使用 OKR 工作法将有效解决这个问题，不仅让技术、产品、业务等团队的目标更加聚焦，还能让技术团队所交付的成果，更容易验证出它的价值。

从我的实践经验来讲，OKR 可与敏捷过程无缝整合，敏捷关注迭代，迭代关注任务，任务由人去执行，人更关心产出，产出可推进 KR 的完成，KR 可推进 O 的完成，O 完成了对人产生激励效果。

今天的核心内容可归纳为以下三点：

任何看似完美的方法，实质上都有自身缺陷，关键在于灵活应用，敏捷和 OKR 都不例外。
只有结合问题思考解决方案，并努力创新实践，才有可能从根源上解决问题。
敏捷一般应用于软件开发领域，而 OKR 可应用于任何领域，两者结合，值得尝试。

祝愿你也能敏捷与 OKR 结合之路上产生更多的收获，沉淀出更多有价值的实践经验。

思考时间

你在敏捷开发过程中还遇到过哪些问题？借助 OKR 思维，你会怎样解决这些问题？期待你的留言。

最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。