19 敏捷与OKR都是为了“拥抱变化”，两者如何无缝整合？
你好，我是黄勇。记得在十多年前，我第一次了解到了“敏捷”的概念，当初我只是把敏捷理解为高效，不过后来才发现，敏捷不只是高效，更多的是适应外界环境的不断变化，并做出灵活调整，这就是我们常说的“拥抱变化”了。
今天，我想和你从“拥抱变化”开始聊起，看看传统敏捷方法所遇到的一些现实问题，以及如何将敏捷与 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 思维，你会怎样解决这些问题？期待你的留言。
最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。
- w*waiting 👍（1） 💬（1）
之前看的所有的OKR需要三个月的期限，这次总算看到更方便实施的方式了，感觉很好，点赞！
2019-08-12 - 西西弗与卡夫卡 👍（1） 💬（1）
目标制订和任务执行相结合，回顾会上再加上Sprint OKR回顾，价值或许更大些。
2019-08-12 - 趣哲 👍（0） 💬（2）
老师将敏捷与OKR结合的思路非常赞，有两个问题想咨询下： 1、看过不少关于技术的OKR，示例诸如您所讲，但公司产品发展还没精细化到这些点，更多的是实现某项业务需求，最终变成了承诺型OKR，实际就是任务按计划实施并交付。对此类情况想咨询下有什么更好的方式去做？ 2、敏捷天生就拥抱变化，规划一个季度的多个O，应是季度初就制定了，我在实际工作中经常遇到中途变更例如优先级更高的任务插入，这类变化敏捷本身可应对，但对于季度中的某个O可能就没办法实施了。这类情况怎样处理会更好？
2019-08-20 - vina 🌸 👍（0） 💬（2）
如果高层战略不清晰，或者说计划不如变化快，OKR怎么落地呢？
2019-08-13 - 行者 👍（0） 💬（2）
敏捷开发规范流程，okr让我们认清主次。 敏捷开发中容易遇到的问题是伪敏捷，为了敏捷而敏捷，忽视了敏捷的本质是交付价值。
2019-08-13 - 许童童 👍（0） 💬（1）
敏捷+OKR，老师真是天才啊。将两者融合，取长补短，相互促进。 老师结合问题思考解决方案的能力实在令人佩服。
2019-08-12 - 敏捷教练夏勇杰 👍（1） 💬（0）
敏捷本身其实并不存在老师说的这些问题，但是OKR可以帮助敏捷强化价值和目标在交付过程中的重要性。
2021-01-11 - 怀揣梦想的学渣 👍（0） 💬（0）
看评论发现，西西老哥很强呀，技术课有见到，这种课也可以见到。
2023-05-26 - Geek_32e76d 👍（0） 💬（0）
我们团队执行的是双月的OKR，APP版本迭代是每月发版一次，发现版本迭代的O的完成是超前的，比如：5-6月是一个OKR周期，版本每月24号发布，那么7月份的版本需要在6月底完成业务和产品方案的产出，但六月底我们才开始确定清楚7-8两个双月的OKR。导致OKR的执行有些混乱，请问这种情况一般如何解决？
2021-06-15 - Geek_0a49b5 👍（0） 💬（0）
老师请问，日常的任务，例如BUG 修复，临时改动怎么制定？
2021-02-24