僵化的详细长期计划(根据消耗的预算跟踪进度)正在敏捷组织中迅速成为对过去的褪色怀旧记忆,这由预测和非静态路线图代替.定期在这些可视化文件前聚会,您将能够学习.共享并触发重要的对话,解决依赖性并邀请服务型领导的行为.使您的OKR和预测计划共存! 在这个博客中,我想给出带有可视化示例以及伴随的重复仪式.可视化和伴随的仪式可以共享进度,并确保持续解决和减轻障碍和依赖性.它还将预测变成对话(与被视为承诺的项目计划中捕获的固定估计相反). 参与团队回答的核心问题是: 敲黑板 - 划重点(译者注) "您是否…

OKR与敏捷开发的原理有着相似之处,但已经使用敏捷的团队再用OKR感觉会显得多余.这种误解的根源就在于对这两种模式不够了解,运用得当的情况下,OKR和敏捷可以形成强强联合的效果,他们可以创造出以价值为驱动的团队,改变团队的工作方式. 本文是OKR与敏捷系列文章的第二部分. 回顾第一部分请点这里:系列文章|OKR与敏捷(一):瀑布式目标与敏捷的冲突 全栈敏捷 想要实现业务的敏捷性,公司需要确保各层级的敏捷性.以此来替换公司传统组织架构的各个层级: 在全栈敏捷中,组织各个层级的架构转变为: 文化以激…

OKR 实践指南:知乎任向晖.雷明灿作品 (知乎「一小时」系列) 作者所在的公司已经实施了OKR十个季度了.算是目前少有的OKR老司机.书中介绍的是作者的实践经验,在目前的OKR中文书中这本算是比较少见的. 书中的两个重要观点:1:OKR的作用是帮助企业聚焦战略目标避免跑偏:2:KPI同绩效挂钩是管理水平低劣的表现. 总体评价4星,很有价值. 以下是书中一些内容的摘抄: 1:或者准确地说,OKR在中国的关注度几乎和美国是同步的.在Google时代之前,也只有极少数的美国企业对OKR感兴趣.#49…

什么是OKR 近几年OKR的概念在国内开始流行起来了,之前公司也有人想实施OKR,但现在看来之前的OKR实施者只是在哪儿看了一下OKR的资料,本着跟老板邀功的想法比较功利的在推进,所以基本没有效果,今年换了一个不错的团队,比较幸运的成为了技术部(150人左右)OKR实践的操盘手,于是整个对OKR的认识便不太一样了,这里分享一些心得出来与各位交流,互相促进. OKR(Objectives and Key Results)即目标与关键成果法,是一套帮助我们明确目标,并且有一套跟踪完成情况的路径,这里…

上一篇「 互联网公司目标管理OKR和绩效考核的误区 」介绍了使用 OKR 时要澄清的一些概念,但是实际使用中又如何呢?我们快手也是很大的互联网公司,大家都是年轻人,思维活跃,容易接受新事物,敢尝试,但即便是这样,我们在使用OKR的时候也遇到了很多的困难.下面是我们在使用 OKR 中的一些实践和我的一些反思. OKR的目的 从上篇文章中,我们总结了 OKR 到底是什么和使用OKR 的主要作用,我们简单回顾一下. OKR是主动承接上级战略目标,分解公司的主要战略目标,使公司的战略落地.OKR中列出了…

转自本人运营的公众号“ 携程技术中心PMO”(ID:cso_pmo)       经常有人抱怨的一个问题:敏捷会让团队自组织,要求团队能“一方有难,八方支援”,但是为什么总感觉自己团队虽然实践了敏捷,但还是觉得人心很散,队伍不好带?为什么总是不能做到“上下同欲”?   遇见这样的问题,我常常会去观察团队,试着从透过结果找原因,最终你会发现一个共性,那就是在这样抱怨的团队中,你最常看到的现象是:总有一个所谓的“团队负责人”在无时无刻的安排工作,在 Plan 会议上分发任务.团队没有产品愿景,需求没…

OKR与敏捷开发的原理有着相似之处,但已经使用敏捷的团队再用OKR感觉会显得多余.这种误解的根源就在于对这两种模式不够了解,运用得当的情况下,OKR和敏捷可以形成强强联合的效果,他们可以创造出以价值为驱动的团队,改变团队的工作方式. 本文第一部分介绍了瀑布式目标与敏捷之间的冲突. 功能工厂 敏捷的诞生是为了确保软件的交付,可以替代瀑布式开发来管理软件项目.敏捷模式注重的是可交付成果(开发需求或软件功能)而非项目价值(业务成果)的管理. 事实上,敏捷中并没有单独跟踪结果的规范. <敏捷宣言>本身…

每日站立会议是敏捷流程scrum中的很重要的一个制度之一. 功能:     1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展.      2.给每个人一种精神压力,信守承诺.这是一种面对面的精神压力,直面项目进展.     3.培养团队的文化,让每个人意识到:我不是一个人在战斗,我们是一个团队.    站立会议的目的: 1.让所有人了解其他人在做什么,当前项目计划进展如何 2.帮助大家解决那些阻碍做事情的问题,以及共享承诺这些都非常有利于提高团队合作精神的. 注意…

介绍: 在敏捷软件开发中,从代码的产生速度上来看,要比 传统Waterfall产生速度高很多.因为我们把时间安排的更加紧凑了.那么这么多的代码,如何能保证这些代码质量呢?很多人可能直接想到静态代码检测 工具.没错,那些是可以定义一个代码检查规则来确保代码的质量,但是那个仅仅是从语言角度,那么逻辑是否已经最优化了?可重用性是否已经优化到极致了?这 些是静态代码工具不能完成的,所以我们需要Code Review 实现方式: 对于已经在项目组很久的人来说: 虽然传统的code review就是把代码从…

介绍: 在敏捷开发模式中,Sprint Retrospective Meeting 也是一个必不可少的环节,它通常发生在每个Sprint的结尾,其主要作用是对于当前的迭代周期做一个阶段性的总结,包括好的方面和不好的方面,然后我们 可以在接下来的迭代中扬长避短,所以这对于一个团队的健康发展也是有好处的. 实现方式: 一般我们项目组是通过圆桌会议来完成Sprint Retrospective Meeting ,会有相应的人(一般是项目组的人按照名字序列轮流)记录好Meeting Minutes. 我…