DevOps成为BizDevOps：4个步骤，为您的工作增添更多价值

只有在开发和运营与专业部门和管理人员共同开发增值产品的情况下才能发挥DevOps的全部潜力。代替DevOps，应将其称为BizDevOps。本文介绍了业务和DevOps的集成如何改变公司的合作，组织和流程。

将开发和运营紧密结合在一起，以提高业务产出。很多企业依靠DevOps来实现这一目标。IT职能部门之间的组织边界正在逐渐消失。

现在，有跨学科团队追求共同的目标，并借助新的可用技术来创造更具吸引力的服务产品。除DevOps之外，敏捷方法和自动化流程还有助于加快为创新业务模型提供集成服务的速度。

但这不是一件简单的事情-此过程需要进行很多更改，这对于某些IT组织而言确实是一项实力考验。如“ 2017年DevOps状况报告” [1]所示，这仍然值得努力。根据该报告，在3,200多名受访者中，高绩效人员提供新代码的频率提高了46倍。他们还可以更快地实现440倍的更改，同时将平均恢复时间减少96倍，并将更改的错误率减少5倍。

根据这些数字，问题不再是DevOps是否有意义，而是如何实际实施该概念。

没有业务的DevOps不会取得太大成就

有一个共同的经验，由多个客户项目共享：如果专家部门在没有实际IT部门参与的情况下快速安排提案，则IT中的DevOps方法将无济于事。作为对这些动作的反应，IT采取了立即反应的态度，这通常是瓶颈情况。

相反，企业需要的是改变公司所有部门之间的态度和工作方法。这些更改涵盖了各个业务部门以及IT开发和运营。因此，我们谈到BizDevOps。它是IT和业务部门用来驱动企业数字化转型的一系列相互关联的文化变化。

可以通过日常业务生活中经常遇到的情况来描述可能发生的困难以及如何最好地解决这些困难：对IT的误解是误解。

上下文更改是一项昂贵的事务

许多企业将IT开发和运营团队视为阻碍者，这是很常见的。这是有原因的：IT部门已经完全占用了所有正在进行的项目和业务变更请求，因此他们不得不例行拒绝新请求。这当然会有后果。单一的专家部门将尝试尽可能长时间地束缚并保留资源IT，以便他们可以实现各自的议程。现在他们也正在阻止IT。这样的情况经常以这样的方式发展：开发团队通常不会同时处理多个项目。

这种持续的上下文变化是非常耗时的事情。通过上下文更改[2]测量时间损失的经验法则如下：10％乘以所有同时进行的项目的数量。这是什么意思？这意味着，如果一个开发人员同时从事三个项目，那么他会浪费30％的时间。

效率低下的原因是，开发团队必须在不了解更高目标或计划的情况下优先考虑项目和变更（已开发应用程序的服务操作）的优先级。还有Eliyahu Goldratt的约束理论[3]要考虑在内。它指出，等待时间随工作站的利用率成指数比例增长。这意味着如果利用率为100％，则等待时间将是无限的。

在这种情况下，专业部门正试图通过升级来打破对项目的封锁。它不能帮助开发人员团队对任何任务进行排序或处理，但是通常，这是引发开发的唯一可能方法。尽管由此产生的，与该过程相关的其他扩展却适得其反。

开发人员可以做什么

封锁情景不仅不经济，而且对于开发团队来说非常不利。因此，当他们有机会进行更改时，通常很容易吸引他们合作解决问题。作为第一个也是最重要的措施，与公司各利益相关方的封闭反馈周期有助于实现这一目标。只有在所有参与者的互动中（从BizDevOps的角度来看），IT的封锁才能得到永久解决。

实施使用各种不同的方法和工具，这些方法和工具可能会因规模，行业细分，公司的成立状况和战略而异。但是，一般而言，以下四项措施可被视为迈向具有更高附加值的IT的重要步骤。

1.根据总体业务目标确定优先级

尽管这种措施似乎不言而喻，但在许多公司中，相应的规范都是灰色理论。为了改变这一点，开发团队必须首先将利益相关者召集在一起并提高认识。然后一起回答以下问题：主要目标是什么？哪些标准适用于优先级排序？如何协调利益冲突？

2.通过指标创建和传达交付透明度

如果每个人都清楚在哪个时间段内提供哪些服务，那么每个相关人员将更容易将工作包放在一起，然后可以按计划进行处理。这还包括跟踪变更请求的运行时间并测量错误率：多少变更实际上失败并因此导致返工？

团队和利益相关者的定期报告是任何DevOps组织运作的重要贡献。此外，基本原则独立于官方沟通而适用：每个人都应该公开信息，以便每个人都可以适应当前情况。这样，所有相关方都可以感知到改善或积极地为消除赤字做出贡献。

3.与Scrum董事会和看板董事会组织工作

Scrum和看板等方法提供了有价值的工具，即使在复杂的环境中也可以保持焦点。但是仅靠工具是不够的。团队的所有成员必须始终自觉地专注于共同目标。仅仅因为一项任务可以快速，轻松地完成，并不一定有助于团队当前的目标。必须共同取得进步。建立小批量，避免进行中的工作以及完成任务很重要。

但是，某人一旦完成一项新任务就对团队并不总是有益的。为了实现冲刺目标，在他人的任务中给予支持通常更为重要。此外，联合工作可确保更好地补偿单个团队成员的损失。

4.回顾–展望未来

定期回顾以持续改进的行动项目（措施）为重点，可以显示过去有效的方法和无效的方法。这是改进的基础，也是寻找以下核心问题的答案的基础：我们将如何做才能更好地管理整个流程？

但是，从过去的错误和成功中学习还需要预先计划时间。Gene Kim，Jez Humble和Patrick Debois在《 DevOps手册》 [4]中建议将此类改进节省20％的时间。

措施的实施是DevOps转型的第一步，经验表明：任何人都可以设置启动冲动-无论是Biz，Dev还是Ops！

一个示例场景

这是一个典型的IT封锁案例：一家大型机械工程公司的营销部门计划了两年后重新启动其网站。最初，通过网站可以增加潜在客户。但是，所有业务的最高要求都被汇编成一个全新的网站概念。

结果：内容管理系统（CMS）被一种产品取代，该产品的技术自身的IT人员没有必要的专业知识。更改只能在外部实施。如果从BizDevOps的角度出发，营销和IT首先在具有A / B测试功能的现有解决方案的基础上一起尝试对客户方法进行具体更改，那将会更加有效。“向左移”的原则可确保更改在开发过程中的正确性及其可操作性。营销可以通过参与者使用假设将他们的要求降低到最小可行产品来做出贡献。

中心问题是：能为客户带来利益的最低产品是什么？这不仅显示所需的服务和功能是否正常运行。相反，很清楚它们带来了什么好处。这样，IT和业务部门可以在密切协商中逐步扩展产品。

这种假设驱动的方法减少了开发中非实际需求所需的资源浪费。对于最终用户无用的功能在准备投入市场之前不会进行广泛的修订和测试，而是在原型阶段进行挑选。另一方面，先前项目的经验表明，超过一半的工作量通常花在对用户不重要的功能上