Scrum与OKR融合实践经验分享

很多软件公司的研发团队都喜欢用Scrum管理研发流程,Scrum是一个诞生于20世纪90年代的敏捷方法论,CORNERSTONE内部也一直在使用这一方法。 相较于瀑布式开发的其他传统方法,Scrum最大的优点...

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


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

 

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


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


image.png


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

 

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

 

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


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


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


 image.png


其实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目标的行动方案。


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


image.png


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


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

 

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

 

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


image.png

  • 发表于 2019-12-30 15:51
  • 阅读 ( 1965 )

你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
CORNERSTONE
CORNERSTONE

72 篇文章

作家榜 »

  1. omicsgene 702 文章
  2. 安生水 350 文章
  3. Daitoue 167 文章
  4. 生物女学霸 120 文章
  5. xun 82 文章
  6. rzx 78 文章
  7. 红橙子 78 文章
  8. CORNERSTONE 72 文章