系列文章｜OKR与敏捷（二）：实现全栈敏捷

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。

想要实现业务的敏捷性，公司需要确保各层级的敏捷性。以此来替换公司传统组织架构的各个层级：

在全栈敏捷中，组织各个层级的架构转变为：

Worktile敏捷开发示意图

技术债是大多数软件工程师都熟知的问题。 技术债的来源主要是团队想走捷径，而技术债将导致代码难以更改且无法扩展。

技术债是要偿还的，并且还有利息。

为了解决技术债问题，团队需要重构代码，在不添加新功能的情况下完善内部架构。

渗透了敏捷交付思维的瀑布模型将导致组织债务，就像技术债那样，组织债务会导致公司变革艰难且需要付出代价。

为了实现全栈敏捷，公司需要填补组织债务，因此需要重构各层级的组织架构。但是说起来容易做起来难，许多公司的尝试均以失败告终。

那么，最好的办法是什么？

许多敏捷开发圈子的人都认为，解决问题的唯一方法是思维模式的转变。好像只要我们改变了组织的思维模式，所有的问题就可以迎刃而解。

仅关注思维模式的转变是很危险的，因为它不具备行动性。

“‘思维模式’好像已经取代了‘价值’和‘使命’，成为避免老生常谈的最新行动” ，戴夫·斯诺登（Dave Snowden）曾写道。

另一种解决方法是专注于能够改变公司运作方式的实际行动。

斯坦福大学詹姆斯·马奇（James March）教授提醒我们说：“领导力不仅涉及诗和远方（愿景）还要注重体系架构。” 当然“诗和远方（愿景）”确实很重要，但很多公司却忘了体系架构：也就是公司的体系和流程的建设。

改变公司的体系架构流程复杂还有花费很多时间，但成功之后，收益远大于付出。

有一个工具可以帮助改变‘组织的体系架构’并实现业务敏捷性。 这个工具就是OKR（目标与关键结果法） ，这一目标架构已被谷歌和Spotify（流媒体音乐平台）等公司采用。

Worktile OKR示意图

OKR与传统计划方法的最大区别是什么呢？ OKR需要定期设定及评估——通常每季度一次。此外，与自上而下的单向目标设定流程不同的是，OKR是双向的。

这就意味着团队可以根据公司的总体目标来设定自己的OKR，并在与上级沟通和探讨后使用。

这种管理模式营造了一个鼓励团队参与目标设定的大环境。他们对自己参与设定的目标具有更强的责任感，并且还会每周一次进行跟踪和复盘。

如运用得当，OKR能够帮助公司实现全栈敏捷。

实现全栈敏捷的关键就在于要专注于价值。

问题在于，整个公司的架构以完成上级规定的任务为重点。而敏捷则以交付为重点，二者结合将导致公司沦为以交付产品功能为重点的功能工厂。

这种对交付的痴迷由来已久。从软件开发行业将可运行的软件作为衡量进度的标准开始一直持续到现在。

正如杰夫·萨瑟兰（Jeff Sutherland）的书名所说，Scrum是“一门能够让软件开发事半功倍的艺术”。因此，看板上实际少了一栏，即“可行性”，如下面来自约翰·卡特（John Cutler）的图所示：

只有在增加价值的情况下，“完成”才具有意义。

事实上，未改进指标的功能可能会产生负面效果：新提交的代码可能存在缺陷，需要维护，并且会导致产品变得更加复杂。

尽管《敏捷宣言》存在误导性，但其中一位作者马丁·福勒也对成果进行了论述：

“解决瀑布模型问题的关键是要认识到，敏捷主义者更重视成果而非功能。功能列表是非常有价值的工具，但并不意味着最终目标。真正重要的是总体的成果，因为我认为这对客户来说才是有价值的。”

关于团队激励，亨里克·克里伯格（Henrik Kniberg）展示过一张很棒的PPT：

第一个团队代表了功能工厂。 这种模式下团队无法自主确定应该做什么，团队之所以从事某种工作是因为有人要求他们这么做。这种模式遵循泰勒管理模式中的计划和执行相分离的原则，这既会让团队丧失动力，也无法激励创新。

而第二个团队则走了另外一个极端，即仅凭“直觉”行事。

而第三个则是价值驱动团队。 这样的团队会专注于价值的交付，并且知道如何才能发挥最大作用。他们有清晰的目标，并且能够让自己的工作与公司战略保持一致。

TBC......

原文作者｜Felipe Castro
内容编译｜Worktile
翻译｜彭相珍