系列文章|OKR与敏捷(二):实现全栈敏捷
OKR与敏捷开发的原理有着相似之处,但已经使用敏捷的团队再用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
文章来源 | Worktile官方博客
文章转载在请注明出处。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
深入理解Java中方法的参数传递机制
形参和实参 我们知道,在Java中定义方法时,是可以定义参数的,比如: public static void main(String[] args){ } 这里的args就是一个字符串数组类型的参数。 在程序设计语言中,参数有形式参数和实际参数之分,先来看下它们的定义: 形式参数:是在定义函数名和函数体的时候使用的参数,目的是用来接收调用该函数时传入的参数,简称“形参”。 实际参数:在主调函数中调用一个函数时,函数名后面括号中的参数称为“实际参数”,简称“实参”。 举个栗子: public class ParamTest { public static void main(String[] args) { ParamTest pt = new ParamTest(); // 实际参数为“张三” pt.sout("张三"); } public void sout(String name) { // 形式参数为 name System.out.print(name); } } 上面例子中,ParamTest类中定义了一个sout方法,该方法有个String类型的参数name,该参数即为形参...
- 下一篇
维护一个开源软件的历程和喜悦
第一节 我在2015年4月份开始做这个开源软件之前, 已经研究了很长一段时间的浏览器开发技术了 那个时候我还只是打算为博客园写个文章发布工具而已, 觉得技术上可行, 也能为常年写博客的人乃至博客平台提供一些帮助 于是就动手做了 做了之后,发布出来,一直自己用, 也没管别人的想法, 那个时候,工作和生活上的事情非常多,也实在抽不出精力来仔细维护这个软件 在各个平台下,各种不同的博客设置下,BUG很多; 很多人找我问这个软件的事情 我也是能推脱的就推掉了。 后来断断续续更新过几个版本。 直到今年1月份,我开始把大部分精力投注到这个东西身上来, 第一个版本发布后,大部分人都觉得挺好的,但还是有负面的声音: 这位网友批评虽然用语激烈一些,但基本上还是中肯的; 这哪里是烂尾一年的轮子呀,这是烂尾四年的轮子了; 我之所以没有另启版本号,就是为了时时警示自己,不忘初心,方得始终! 当然,也有支持者: 我想,做一个东西,其中有一个乐趣必定是有人在讨论你这个东西吧! 有好的声音,有不好的声音,都是你持续做下去的动力。 第二节 我以前管一个团队, 是整个公司的研发中心, 不是做项目和产品的,是专门做r...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19