持续交付 2.0 的组织文化

简介: 持续交付 2.0 的组织文化

《持续交付 2.0》读书笔记

企业领导者必须成为这一变革的领导者,建立与之相适应的企业文化,使得“持续交付 2.0”成为企业的基因,才能够持续获得它带来的收益。

安全、信任与持续改善

“持续交付2.0” 强调 “持续探索” 和 “快速验证”,而探索必然会伴随着失败,失败会令人产生挫败感与不安全感。而学习与成长也通常发生在失败之后。这就要求组织必须建立“安全、互相信任和持续改善”的组织文化。

失败是安全的

组织是一个复杂系统,它的改进比较复杂。如果组织成员发现,在组织中“犯错”是个很糟糕的事情,会受惩罚,那么,为了避免出错受到惩罚,组织成员就会放弃做出有风险的决策。在一个高度不确定的环境中,没有人能够保证自己的决策不会出错。如果无法让组织成员感到“失败是安全的”,那么组织成员的行为就会倾向于避免犯错,各扫门前雪,逃避责任,缺少合作。

相互信任

相互信任是高效合作的基础,也是组织凝聚力和成员士气的基础。成员之间的相互信任既包括对彼此个人品质的信任,同时也包含对专业能力的信任。这种信任是相互的,赢得他人信任的同时,也要信任他人,认可他人的个人品质与专业素养。如果组织成员之间缺乏信任,那么很容易出现相互猜忌、相互指责的现象,用不了多久,就会影响成员在组织内的安全感,降低工作效率。在过去的十多年中,很多组织采纳敏捷软件开发方法,但是并没有取得企业所预期的效果,除一些技术改进的原因以外,一个不可忽视的原因就是“相互信任”文化的缺失。当这种文化缺失时,常常会让人感受到“产品人员抱怨开发人员不给力”和“开发人员认为产品人员不靠谱”这种潜在的暗示。

持续改善

《丰田套路》一书中指出:“丰田之所以取得傲人业绩,并不是源于我们可以看到的那些工具和方法,而是源于丰田的行为习惯 - 通过不断地试验而持续改进。”只有那些善于“持续改善”,并使之形成一种自身文化的企业才会不断进步。持续改善文化的特点是“人人参与”和“时时改善”。“人人参与”是指“持续改善”不应该只是组织中某个角色的责任,而应该是所有人的责任。“时时改善”是指“持续改善”应该是一项日常工作,而不应该只在特定时间或条件下才发生,例如只在事故发生之后才进行分析和改进。

文化塑造四步法

文化是无形的,很难改变。它在影响组织成员行为的同时,也会受组织成员的行为影响而发生变化。《精益企业》一书中指出,组织成员的行动和对事情做出的反应,主要由组织领导者和管理者的行为所决定。例如,人们是否有行动自主性,并获得信任,承担其风险与责任,面对失败的时候,人们是否会受到惩罚,是否鼓励跨部门的沟通等。

行为决定文化

通过改变行为来改变思想。四步法:

  1. 定义我们想要做的事情;
  2. 定义我们期望的做事方式或方法;
  3. 提供相应的培训,使员工具备完成其工作的能力;
  4. 设计一些必要的机制或措施来强化我们所鼓励的那些行为;

通过这 4 个步骤,企业可以让员工成功掌握完成自己工作的方法。最终,文化就会被改变。组织文化是一系列行为结果的展现,体现在人与人之间的日常工作交互中,因此我们无法直接改变“组织文化”。但是,我们可以通过培训企业员工具备必要的能力,同时规范员工的做事方式,而达到塑造企业文化的目的。

谷歌的工程师质量文化

建立工程师质量文化,做法也可以总结为以下 4 步:一、定义想要做的事情

  • 提高代码质量,减少生产问题,减少手工测试工作量,快速发布软件。

二、定义期望的做事方法

  • 开发团队编写自动化测试;
  • 主动运行自动化测试用例;
  • 做代码评审;

三、提供相应的培训

  • 在公司范围内组织代码设计与自动化测试培训;
  • 为每个团队指派自动化测试教练,帮助团队提高自动化测试技能;

四、做些必需的事情来强化那些行为

  • 建立团队测试认证机制,用于评估每个软件产品团队的测试成熟度;
  • 建立自动化测试组和测试教练组,帮助团队提升自动化测试能力;
  • 建立代码评审资质证书;
  • 代码合入版本仓库之前强制做代码评审;
  • 代码评审之前,必须运行自动化测试用例,并提交报告给代码评审者;

Etsy 的持续试验文化

Etsy 鼓励“持续试验”的文化,做法也可以总结为以下 4 步:一、定义想要做的事情

  • 不必害怕失败,快速发布,持续试验。

二、定义期望的做事方法

  • 每天向生产环境多次部署;
  • 部署后立即进行数据收集和统计分析;

三、提供相应的培训

  • 在每一个新员工入职第一天,让其知道如何登录自己的虚拟机,把代码放在哪里,如何运行自动化测试,以及如何部署代码到生产环境,在哪里查看度量仪表盘,确保部署后一切都运行正常。让新员工一开始就了解部署过程,不至于对部署产生畏惧。

四、做些必需的事情来强化那些行为

  • 每次业务变更都要进行数据衡量;
  • 从真实数据中学习,无论是失败还是成功;
  • 开发相应工具,提高部署和数据收集分析能力;

行动原则

价值导向

所有人都会一致同意,“我们做事情时,应该价值导向”。然而,这却是在工作中经常被忽视的一点,也是最难判断的一点。即便进行了充分的沟通与讨论,面对同一个问题的多种解决方案,我们可能也无法达成一致意见。此时,我们可以采用行动原则的第二原则,即“快速验证”。

快速验证

在高度不确定的环境中,并不是所有的方案都能很容易提前对其价值进行准确判断,因此我们需要快速验证。通过快速实施,得到真实反愦,从而做出决策。在一个安全的工作环境中,只要我们能够主动拥抱“快速验证”原则,充分发挥员工的主观能动性,就可以找到很多快速试验方案。对于与组织管理相关的改进,也可以使用快速验证方式。例如,针对具体问题,选择不同的试点团队进行快速实施,根据团队实际运行效果进行调优、验证。

持续学习

我们无法保证每个决策都是正确的。团队应当将每一次反馈作为一次学习的机会,结合从中学习到的新知识,总结成功经验或失败教训。除了通过业务试验产生的业务结果对业务领域进行深入了解和学习,还要保持对做事过程的学习与反思,不断优化工作流程,提升各环节的效率。

度量原则

“如果不能度量,就无法改进。”作为管理者,我们也必须承认,在日常工作当中,仍旧有一些我们现在还无法度量但必须进行管理的事情,尤其是在一个高度不确定的环境当中。

度量指标的 4 类属性

度量指标分为引领性指标、滞后性指标、可观测性指标和可行动性指标。下面就来分别介绍一下。一、引领性指标与滞后性指标引领性指标是指那些对达成预定目标有着重要作用的指标。通常,一个好的引领性指标有以下两个基本特点:第一,它具有预见性。第二,团队成员可以影响这些指标。滞后性指标是指那些为了达成最重要目标的跟踪性指标,如销售收入、利润率、市场份额、客户满意度等研究分析都属于滞后性指标。当你得到这些结果的时候,导致这些结果的事情早已结束,你得到的都是历史性结果数据。例如,在其他因素相同的情况下,假如软件质量与性能越好,则软件的市场竞争力越强,客户就越愿意为之买单,软件销售量就会越高。对于软件销售这件事情,软件销售量就是一个滞后性指标,而软件质量与性能就是一个引领性指标。我们可以通过优化软件性能,提升软件质量来影响软件销售量,但无法确保一定达成软件销售量这一滞后性指标。企业的终极后验性指标是客户价值,相对于这一滞后性指标来说,其他指标均可认为是引领性指标。二、可观测性指标与可行动性指标可观测性指标是指可以被客观监测到,但无法通过直接行动来改变的指标。可行动性指标是指在能力可触达范围内,通过团队努力,可以设法直接改变的指标。例如,千行代码缺陷率就是一种可观测性指标。我们无法以非常直接的方式来改变它,只能通过更全面的质量保障活动(写出高质量的代码、做更加完整的测试等活动)来影响这一指标。代码规范符合度、代码圈复杂度、重复代码率则既是可观测性指标,也是可行动性指标,因为团队可以直接通过修改代码来直接影响和改变这些指标,但无法确保一定达成“千行代码缺陷率”这一后验性可观测性指标。

8a5d324e526bf2e6783f0bdf9a2a1692.png

度量的目标是改善

我们可以通过设法管理过程指标来改善我们的工作过程,并将最终的效果与我们期望的结果指标做对比,从而发现改进是否有效,并判断是否需要改变改进方向,还是继续向前。我们需要不断依据反馈的度量结果做出分析后再确定改进的方向,是继续向前,还是另寻他法。度量是一柄双刃剑,对可行动性的过程指标来说,“你衡量什么,就会得到什么”,但并不一定是以你想要的方式达成的。例如,当度量单元测试覆盖率时,工程师可以通过写出无用的单元测试(如没有断言),达成单元测试覆盖率指标,但是这种测试覆盖率已没有任何意义。因此,管理者需要记住,度量的目标是为了组织改善。如果达不到度量目的,则要么改用其他度量项,要么做好管理工作。

“改善套路”进行持续改进

迈克·鲁斯在《丰田套路:转变我们对领导力与管理的认知》一书中介绍了一种“改善套路”,它包含4个阶段,以循环方式不断重复。

  1. 第一阶段:明确方向。管理者需要明白,企业必须始终以愿景为工作目标,并持续不断地改进。在前进的路上,必然会遇到问题。我们需要通过不断试验与迭代,才能达成目标。
  2. 第二阶段:掌握当前状态。团队要掌握当前的状态,获得事实与数据,才能充分认识自己,以对下一步目标状态进行合理的描述。
  3. 第三阶段:定义下一个目标状态。目标状态就是确定团队希望达到的状态,设置期望达到该状态的日期,并定义可衡量的指标项。
  4. 第四阶段:迭代改进。遵循戴明环,不断迭代试验,发现、实施、评估并改善方案,直到达成目标状态。戴明环,又叫 PDCA 循环,是由美国统计学家戴明博士提出来的,它反映了质量管理活动的规律。P (Plan)表示计划,D (Do)表示执行, C (Check)表示检查,A (Action)表示处理。PDCA 循环是提高产品质量、改善企业经营管理的重要方法,是质量保证体系运转的基本方式。

小结

在本章讨论了企业采纳持续交付所需的文化氛围,并根据新联合汽车公司的案例提取了建立企业文化的 4 个步骤。

  1. 第一步:定义想要做的事情。
  2. 第二步:定义期望的做事方法。
  3. 第三步:提供相应的培训。
  4. 第四步:做些必需的事情来强化那些行为。

与此同时,为了提升“持续交付 2.0 能力”,企业或组织应该遵守 3 个行动原则:

  1. 价值导向
  2. 快速验证
  3. 持续学习

企业应当根据“改善套路”,在设定目标后,从简单之处开始行动,通过不断优化,达成提升“持续交付 2.0 能力”的目的。

推荐阅读

  1. 持续交付 2.0
  2. 价值探索环
  3. 快速验证环
目录
相关文章
|
1月前
|
运维 Devops jenkins
DevOps文化:持续交付与持续反馈的文化构建与实践
【10月更文挑战第27天】DevOps文化强调开发和运维的紧密合作,以实现快速、高质量的软件交付。核心在于持续交付和持续反馈。本文探讨了如何通过改变组织结构、构建跨功能团队、使用自动化工具(如Jenkins)和积极收集用户反馈,来构建和实践DevOps文化。
56 0
|
4月前
|
运维 监控 Devops
DevOps 文化建设:促进跨职能团队合作
【8月更文第30天】在当今快速变化的商业环境中,组织需要更快地交付高质量的产品和服务来满足客户需求。DevOps作为一种文化和实践,旨在通过改进开发(Dev)和运维(Ops)团队之间的协作来提高软件交付的速度和质量。本文将探讨如何构建一个积极的DevOps文化,并提供具体的策略和工具来加强团队间的沟通与协作。
358 2
|
敏捷开发 项目管理
Scrum敏捷开发内训, 互联网转型, 敏捷产品开发培训
Leangoo领歌除了是敏捷工具之外,也提供专业的敏捷培训、敏捷认证以及敏捷咨询的服务,权威课程包括:官方权威Scrum认证培训课程(CSM,CSPO,CSD,A-CSM等)、大规模敏捷SAFe及LeSS认证培训,以及量身定制的Scrum敏捷开发企业级实训课程培训, 敏捷工程技术实践课程等。
|
敏捷开发 运维 Devops
DevOps文化与团队协作:实现持续交付的关键要素的实践
在现代软件开发中,实现持续交付是一个至关重要的目标。为了实现持续交付,开发团队需要采用一种协作性强、自动化程度高的文化,这就是DevOps文化。DevOps不仅仅关注开发和运维的合作,还强调开发团队中各个角色之间的协作与沟通。本文将介绍实现持续交付的关键要素,并提供实例代码来说明这些要素的实际应用。
146 0
|
运维 安全 Devops
了解DevOps文化和一些实施方法
太多的错误,太多的时间投入生产功能,编码了数周,太多可避免的事件,今天每个人都意识到了:开发人员和运维必须相互交谈。好的。但是一旦我们说了那句话,具体我们该怎么做呢?本文的目的是告诉您更多有关DevOps 的信息,以及如何在业务中实施 DevOps。
212 0
了解DevOps文化和一些实施方法
|
测试技术 项目管理
艾伟也谈项目管理,在团队中如何推行一项新的实践
在一个老团队中,推行一项新的实践是非常不易的。     如果要求,每天10点站立会议增强团队成员之间沟通。大家会心里先衡量一下,恩,不就是每天站个十几分钟,自己说几句话,然后听别人说嘛,不难做到。
1132 0
|
敏捷开发 前端开发 测试技术
创业公司如何实施敏捷开发
转载自LANCEYAN.COM 说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。
1466 0
|
程序员 开发者
团队文化
代码所有权应该由所谓的“非私利编程”进行平衡。“非私利编程”的观点是指,团队拥有代码,每个开发成员对代码负责,但每个开发人员都不应对他人写的代码有个人攻击的意味对代码进行指责。如果一个开发者对批评指责过于敏感,他有可能不会成长进步得那么快,相对于那些能对有建设性的批评有很好把握的人。
1527 0
下一篇
DataWorks