写点什么

Kevin Behr 谈持续改进

  • 2013-12-05
  • 本文字数:1926 字

    阅读完需:约 6 分钟

DevOps Days 于近日在纽约举行。Kevin Behr 是“可视化Ops 手册”的合著者以及“凤凰项目”的创始人之一。他和Jesse Palmer 就如何将持续提升文化逐步导入总是处于过劳状态的运维团队这一问题作了一次演讲

据Kevin 和Jesse 说,通过这个持续提升的过程,团队工作经历了一个根本性转变:Dev 团队和Ops 团队密切合作,不必要的工作及返工均稳步减少。他们认为缺少一种合乎逻辑的表述来指导其工作和任务,当得出这一结论的时候,该过程还帮助团队取得了重大的突破性进展。

他们开始对当前现实进行诊断,其过程基于数个理论框架,如约束理论 Cynefin ,后者作为诊断过程的指导性框架,用于推理复杂系统的演化性质及其内在不确定性。通过使用当前现实树,他们将组织的主要问题映射到导致问题产生的根本原因上。

另外,通过 Mike Rother 在其著作《丰田套路》中提出的名为改善套路的技术,团队开始进行短期、有限的试验。改善套路是一种将科学方法引入组织日常活动的方式,用于解决问题及其根本原因。本例所使用的具体改善套路基于每日站立会议,会上要回答如下五个问题:

  • 目标状态是什么?
  • 当前状态是什么?
  • 要达到目标状态,主要障碍是什么?
  • 今天针对哪个障碍进行试验?
  • 试验如何做以及试验结果如何展示?

例如,一个常见的抱怨是“我们没有足够的时间”。团队进一步挖掘发现,在特定的时间点上,每个人都总是设法找出最有用的事来做,但没有一种全局视野,因此,他们采用了看板。看板允许团队将整个价值流可视化,对流程进行管理,以及为量化试验和进展做好准备。

在这个过程中,团队识别出若干目标状态,如“偿还技术债务”或“管理未计划的工作”。为了达到这些目标状态,团队做了若干试验,如定义关键技术债务项目或者创建简单的项目计划使组织不会忘记较大的活动。这些试验产生了具体的结果:通过进行根本原因分析避免土拨鼠日效应是其中之一。运维团队还开始与开发团队一起解决常见问题,如改善发布过程。由于已经在两个团队之间建立了反馈回路,所以才能做到这一点。

InfoQ 就演讲中提到的部分技术和实践向 Kevin 提了几个问题:

在您演讲过程中,您阐释了那个组织在那样的背景下所采取的改善套路。您总是使用同样的改善套路,还是根据组织背景从多种改善套路里选择一种?

改善套路有许多种形式。通常,在开始时,我们采取的改善套路与 Mike Rother 在其著作《丰田套路》里所描述的改善套路类似。我们的版本称为 Opsflow,是该方法的一部分或者一种更广泛的形式。它使用各种方法和会议从七个维度推动组织学习,以创建一种互适应的创新能力,并在缩短价值交付周期和等待时间的同时,发展 / 培养潜在的才能。

您提到,目标状态不仅仅是一个目标或者 KPI。关于这点,您能详细阐述一下吗?什么是目标状态?

目标太远了,分分秒秒的工作决策难以对其产生影响。与目标相比,挑战可能是完成工作的一个更小单位(数个挑战可能会使团队更接近目标),但目标状态还要小,与工作人员关系也更近:它是对个体工作人员的隐喻工作站或工作中心的一项或多项度量。可以是过程级度量(部件日输出量)或者知识工作度量。考虑一下,在办公桌前如何工作才能够完成一项挑战。弄清楚如何度量所能够达到的状态。这有助于在开始阶段就在这方面进行经常地训练,使它更容易领会和学习。

您通过什么途径来找出目标状态?

我们使用许多技术,但最好是利用组织的目标 / 任务 / 策略 / 计划 / 尝试,不管怎样,管理方法是任务定义。所有的目标状态需要在管理部门建立的通道内——然后他们会给予指导,只为确保这些目标状态能够使我们更接近挑战,进而使我们所有人都更接近目标。

您是如何决定关注什么目标状态的?

我们使用由 Eli Goldratt 的约束理论改编而来的思考工具,如当前现实树、未来现实树、转换树和目标映射。我们还会借助 David Snowden 设计的方法和会议,如“未来倒推(Future Backwards)”、“仪式性异议(Ritual Dissent)”及其它,来避免认知偏见并识别需要改变的基础状态。

对于持续学习或持续调适,最难的是在“持续”部分。很容易出现这样的情况,开始的时候充满动力,但随着时间推移,动力慢慢消失。关于保持长远地持续调适,您有什么建议或技巧吗?

是的!首先保证学习形式正确而深入。通过学习科学方法建立和培育科学家文化。制定能够培养文化守护者的培训和二次培训计划。另外,引入周回顾,讨论失败和庆祝成功。我们看到了持续努力最难的部分,所遇到的每个挑战很快就被另一个代替,这让人觉得像在跑步机上(在同样的地方工作——不过没有一鸣惊人的成功)。由于失败改善比率低,人们会觉得沮丧。当团队定期回顾其成功和经验教训时,他们可以利用成就感来激发更多改善。这是关键。

查看英文原文: Interview with Kevin Behr on Continuous Improvement Kung-Fu

2013-12-05 20:441247
用户头像

发布了 256 篇内容, 共 87.8 次阅读, 收获喜欢 12 次。

关注

评论

发布
暂无评论
发现更多内容

Chrome浏览器多进程架构3个必会知识点

梁龙先森

面试 大前端 浏览器

写一个用例(第四周)

mas

gradle中的build script详解

程序那些事

maven Gradle 程序那些事 构建脚本 构建程序

LeetCode 数据库刷题 - 1179. 重新格式化部门表

小马哥

七日更 二月春节不断更

并发编程系列:线上问题定位

程序员架构进阶

Java 并发 问题排查 七日更 2月春节不断更

熬夜总结了 “HTML5画布” 的知识点(共10条)

我是哪吒

学习 读书笔记 程序员 随笔杂谈 2月春节不断更

Java SE最佳实践

jiangling500

Java 最佳实践 Java SE

盘点关于程序员的那些经典案例

孙叫兽

程序员 程序人生 话题讨论 薪水 计算机原理

第十二周 数据应用一 作业 「架构师训练营 3 期」

胡云飞

Elasticsearch Mapping Overview

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

还傻傻分不清楚equals和==的区别吗?看完就明白了

codevald

Java 源码分析 string Object

9. Python 学习过程的第一个山坡,99%的人都倒在了山坡下

梦想橡皮擦

Python 2月春节不断更 python入门 python学习

日记 2021年2月13日(周六)

Changing Lin

2月春节不断更

杨明越:Kubernetes的下一仗可能是提升标准化程度

杨明越

Scrum Patterns:梳理产品待办列表(译)

Bruce Talk

敏捷开发 译文 Agile Scrum Patterns

Spring框架源码:BeanFactory与Bean的生命周期

程序员架构进阶

Java spring 源码阅读 七日更 2月春节不断更

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

跳蚤

日记 2021年2月14日(周日)

Changing Lin

2月春节不断更

《我们脑中挥之不去的问题》- 卓克科普(1)

石云升

读书笔记 科普 2月春节不断更

机器学习·笔记之:

Nydia

Tomcat速查手册

jiangling500

Java tomcat

「架构师训练营 4 期」 第七周 - 001&2

凯迪

架构师训练营 4 期

《我们脑中挥之不去的问题》 - 卓克科普(2)

石云升

读书笔记 科普 2月春节不断更

深入浅出函数式编程:Stream流水线的实现原理

李尚智

Java 架构 微服务

JDBC速查手册

jiangling500

Java JDBC

【STM32】串口通信---用代码与芯片对话

AXYZdong

硬件 stm32 2月春节不断更

书画装裱物料与选择参考

boshi

业余爱好 七日更

浅谈性能优化

跳蚤

写一个用例(总结)第四周

mas

聊聊大公司创新的机制:饱和攻击

boshi

创新 七日更

架构师训练营 4 期 第7周

引花眠

架构师训练营 4 期

Kevin Behr谈持续改进_DevOps & 平台工程_João Miranda_InfoQ精选文章