为什么敏捷可以拥抱变化？

 

什么是敏捷？

敏捷不只是高效，更多的是适应外界环境的不断变化，并做出灵活调整

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

在敏捷宣言提出后，业界也出现了一些偏实践的敏捷方法，例如：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 敏捷方法进行软件开发，不过经历了几次迭代后，我却发现似乎团队伙伴们更关注每次迭代中的任务本身和实现细节，而且技术团队就像一台机器，在周期性地运转，并不断地对外交付客户所需要的成果 —— 代码。

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

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

• 分析问题

Scrum 敏捷方法划分出许多 Sprint 迭代，这样操作的价值主要体现在以下几个方面：

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

• 解决问题

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 的目标是为了解决系统稳定性问题。

• 深度协同

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

• 高度融合

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

总结：

敏捷虽好，但它更加聚焦于软件开发本身，能帮助技术团队加快开发节奏，以小步快跑的方式去拥抱业务的变化。但是，敏捷毕竟也不是完美的，除了技术团队，其他人不会关心我们用了什么开发方法，而更关心的则是用户需求和自身诉求能否得到满足。
此外，当需求池积累得越来越多时，技术团队将坠入“生产代码”的陷阱中，我们生产的是代码，而不是价值。如何让我们生产的代码变得有价值呢？必须确保我们做的事情是在建立共识情况下进行的。
因此，我们需要在敏捷过程中学会管理迭代的目标，使用 OKR 工作法将有效解决这个问题，不仅让技术、产品、业务等团队的目标更加聚焦，还能让技术团队所交付的成果，更容易验证出它的价值。

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

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