Scrum 与 OKR 融合实践经验分享

很多软件公司的研发团队都喜欢用 Scrum 管理研发流程，Scrum 是一个诞生于 20 世纪 90 年代的敏捷方法论，CORNERSTONE 内部也一直在使用这一方法。

相较于瀑布式开发的其他传统方法，Scrum 最大的优点是关注持续快速迭代以及对变化的适应性。如果使用瀑布式开发，在项目一开始就要确定项目结果，并且要对此达成一致，通常还要有详细的计划和项目规范。项目计划是从这些规范中产生的，通过以项目在未来的完成情况为出发点，向后推进，以线形的方式规划出时间、预算和各阶段的联系性。

瀑布式开发的成品是一份路线图，能推算出一款软件到推出之日为止，需要完成的所有开发工作，而不足之处就是如果在软件开发过程中出现了变动，包括时间线或各阶段连接时出现问题，甚至在很多时候连预算都需要完全重做，实际上这就破坏了计划。

Scrum 关注的是为了达到一个理想终点的持续快速迭代。取代详细计划的是精益管理或者是需求和回顾会议，这些会衡量每一次迭代成果。回顾会议的目的应该围绕一个问题： “我们所做的工作有没有让我们离目标需求更近？”

Scrum 的力量来自于它能够管理工作，实现一个未知的、独特的、或者前所未有的结果。这一方法能系统地、渐进式地解决在研发过程中产生的问题。瀑布式开发只有在其涉及的过程和工作都是可预测的、并且此前已经有人尝试过的情况下，才能发挥最大功效。

这其中的差别犹如建一座桥和建一艘火箭搭载船的差别。火箭技术相对较新，建造一艘火箭搭载船要有很多增量步骤，重复多次才能获得成功。美国太空探索技术公司（ SpaceX ）为了能让火箭在船上着陆所做的工作就是一个很好的例子。

反之，人们对建桥的流程已经驾轻就熟且无数次成功地实践过了。建桥不需要重复很多次，对时间和成本规划的要求高，这就是瀑布式开发经常应用的领域。

OKR 和 Scrum 的相似之处在于两种方法都需要有一人专门管理实施情况，我们称之为“Scrum Master”或“OKR 负责人”，他们的责任就是保证团队依照规则行事。

Scrum 是一种高度规范的方法论，有明确的职责和流程。Scrum 的益处包括透明性、项目可见性以及频繁沟通。团队集体决定他们在为期两周的一个 sprint 内能够完成什么样的工作，这也使 Scrum 变得很有民主性。

其实 OKR 也有一套规则，这些规则决定什么是目标 O，什么是关键结果 KR，以及如何把二者结合起来衡量目标的实现。

和 Scrum 一样，OKR 有时间表——季度和年度，这比为期两周的 sprint 要长得多。设定 OKR 首先要做的是公司领导决定需要实现何种目标，接着，团队设定自己的 OKR，并确保团队的 OKR 与公司的目标保持一致。

只要每个人都清楚两种方法的范围和参数，OKR 和 Scrum 可以成功地结合在一起使用，效果也确实不错。我们在确立公司 OKR 后，会进一步落实实现 OKR 的行动方案。Sprint 和行动方案能在行动周期内有机结合，促进团队 OKR 的达成。

为了能让这两种方法合拍，很重要的一点是在每个季度开始的时候，一位 OKR 负责人和一位 Scrum 负责人与他们的研发团队坐在一起，决定需要在这个季度完成的最重要的事情（通常为 3 项）。

由于 OKR 周期更长，目标更宏观，而 Sprint 涉及的更具体的执行层面工作，因此需要首先考虑 OKR。要让 OKR 在这一阶段就能有效开展，相对于强调对结果实现的追求，更应关注对结果的衡量。

比如，如果你的目标是解决软件的 bug，让产品更完善，那么，统计消灭了多少个软件 bug 并不是一个有效的关键结果。每修复一个 bug，bug 的数量就少了一个，但是如果有更多的软件 bug 被报出来，你就没有让软件变得更完善，你仅仅是在数自己修复了多少个 bug。

设定了 OKR 的目标和关键结果后，就可以开始规划 Sprint。在这个阶段，最重要的是决定 Sprint 的周期。如果一个 Sprint 为期一个月，那一个单一的 Sprint 目标很可能会直接对应开发团队 3 个 OKR 目标的其中一个。至于更常见的为期两周的 Sprint，那它的 Sprint 目标则可能会变成 OKR 目标的行动方案。

关键结果项目化之后，还需要将工作进一步细化，将项目细化为一个个具体的任务，并确保每个任务都有负责人及截止时间，这样才能确保每项工作都落到实处还可以最大限度的避免工作延期。

(图为CORNERSTONE可视化任务看板)

我们更推荐第二种方法，因为这种方法在连接两个框架的同时还保持了二者最初的目标，即 Sprint 管理生产和代码传输，而 OKR 设定目标，衡量评估工作结果。

但是，这也意味着每一个 OKR 都需要有自己的 Sprint 时间线。如果你有一个大型的开发团队在一个产品的不同领域开展工作，比如前期工作、后期工作和系统管理，这一方法就能发挥很好的效果。使用这种方法的话，每一个领域引导 1 个 OKR 和 1 条 Sprint 时间线，而整个小组内部有 3 个 OKRs。

对于规模较小，没有能力运转 3 条 Sprint 时间线的开发团队，我们也推荐这种方法，但是只需要专注一个单一的 OKR 即可。CORNERSTONE提供了包括任务 /需求 /测试管理、迭代规划、缺陷追踪、报表统计、团队协作、WIKI、共享文件和日历等功能模块,20 人以下团队可免费使用,点击即可免费注册CORNERSTONE。