只有在開發(fā)和運(yùn)營(yíng)與專業(yè)部門和管理人員共同開發(fā)增值產(chǎn)品的情況下才能發(fā)揮DevOps的全部潛力。代替DevOps，應(yīng)將其稱為BizDevOps。本文介紹了業(yè)務(wù)和DevOps的集成如何改變公司的合作，組織和流程。

將開發(fā)和運(yùn)營(yíng)緊密結(jié)合在一起，以提高業(yè)務(wù)產(chǎn)出。很多企業(yè)依靠DevOps來實(shí)現(xiàn)這一目標(biāo)。IT職能部門之間的組織邊界正在逐漸消失。

現(xiàn)在，有跨學(xué)科團(tuán)隊(duì)追求共同的目標(biāo)，并借助新的可用技術(shù)來創(chuàng)造更具吸引力的服務(wù)產(chǎn)品。除DevOps之外，敏捷方法和自動(dòng)化流程還有助于加快為創(chuàng)新業(yè)務(wù)模型提供集成服務(wù)的速度。

但這不是一件簡(jiǎn)單的事情-此過程需要進(jìn)行很多更改，這對(duì)于某些IT組織而言確實(shí)是一項(xiàng)實(shí)力考驗(yàn)。如“ 2017年DevOps狀況報(bào)告” [1]所示，這仍然值得努力。根據(jù)該報(bào)告，在3,200多名受訪者中，高績(jī)效人員提供新代碼的頻率提高了46倍。他們還可以更快地實(shí)現(xiàn)440倍的更改，同時(shí)將平均恢復(fù)時(shí)間減少96倍，并將更改的錯(cuò)誤率減少5倍。

根據(jù)這些數(shù)字，問題不再是DevOps是否有意義，而是如何實(shí)際實(shí)施該概念。

沒有業(yè)務(wù)的DevOps不會(huì)取得太大成就

有一個(gè)共同的經(jīng)驗(yàn)，由多個(gè)客戶項(xiàng)目共享：如果專家部門在沒有實(shí)際IT部門參與的情況下快速安排提案，則IT中的DevOps方法將無濟(jì)于事。作為對(duì)這些動(dòng)作的反應(yīng)，IT采取了立即反應(yīng)的態(tài)度，這通常是瓶頸情況。

相反，企業(yè)需要的是改變公司所有部門之間的態(tài)度和工作方法。這些更改涵蓋了各個(gè)業(yè)務(wù)部門以及IT開發(fā)和運(yùn)營(yíng)。因此，我們談到BizDevOps。它是IT和業(yè)務(wù)部門用來驅(qū)動(dòng)企業(yè)數(shù)字化轉(zhuǎn)型的一系列相互關(guān)聯(lián)的文化變化。

可以通過日常業(yè)務(wù)生活中經(jīng)常遇到的情況來描述可能發(fā)生的困難以及如何最好地解決這些困難：對(duì)IT的誤解是誤解。

上下文更改是一項(xiàng)昂貴的事務(wù)

許多企業(yè)將IT開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)視為阻礙者，這是很常見的。這是有原因的：IT部門已經(jīng)完全占用了所有正在進(jìn)行的項(xiàng)目和業(yè)務(wù)變更請(qǐng)求，因此他們不得不例行拒絕新請(qǐng)求。這當(dāng)然會(huì)有后果。單一的專家部門將嘗試盡可能長(zhǎng)時(shí)間地束縛并保留資源IT，以便他們可以實(shí)現(xiàn)各自的議程?，F(xiàn)在他們也正在阻止IT。這樣的情況經(jīng)常以這樣的方式發(fā)展：開發(fā)團(tuán)隊(duì)通常不會(huì)同時(shí)處理多個(gè)項(xiàng)目。

這種持續(xù)的上下文變化是非常耗時(shí)的事情。通過上下文更改[2]測(cè)量時(shí)間損失的經(jīng)驗(yàn)法則如下：10％乘以所有同時(shí)進(jìn)行的項(xiàng)目的數(shù)量。這是什么意思？這意味著，如果一個(gè)開發(fā)人員同時(shí)從事三個(gè)項(xiàng)目，那么他會(huì)浪費(fèi)30％的時(shí)間。

效率低下的原因是，開發(fā)團(tuán)隊(duì)必須在不了解更高目標(biāo)或計(jì)劃的情況下優(yōu)先考慮項(xiàng)目和變更（已開發(fā)應(yīng)用程序的服務(wù)操作）的優(yōu)先級(jí)。還有Eliyahu Goldratt的約束理論[3]要考慮在內(nèi)。它指出，等待時(shí)間隨工作站的利用率成指數(shù)比例增長(zhǎng)。這意味著如果利用率為100％，則等待時(shí)間將是無限的。

在這種情況下，專業(yè)部門正試圖通過升級(jí)來打破對(duì)項(xiàng)目的封鎖。它不能幫助開發(fā)人員團(tuán)隊(duì)對(duì)任何任務(wù)進(jìn)行排序或處理，但是通常，這是引發(fā)開發(fā)的唯一可能方法。盡管由此產(chǎn)生的，與該過程相關(guān)的其他擴(kuò)展卻適得其反。

開發(fā)人員可以做什么

封鎖情景不僅不經(jīng)濟(jì)，而且對(duì)于開發(fā)團(tuán)隊(duì)來說非常不利。因此，當(dāng)他們有機(jī)會(huì)進(jìn)行更改時(shí)，通常很容易吸引他們合作解決問題。作為第一個(gè)也是最重要的措施，與公司各利益相關(guān)方的封閉反饋周期有助于實(shí)現(xiàn)這一目標(biāo)。只有在所有參與者的互動(dòng)中（從BizDevOps的角度來看），IT的封鎖才能得到永久解決。

實(shí)施使用各種不同的方法和工具，這些方法和工具可能會(huì)因規(guī)模，行業(yè)細(xì)分，公司的成立狀況和戰(zhàn)略而異。但是，一般而言，以下四項(xiàng)措施可被視為邁向具有更高附加值的IT的重要步驟。

1.根據(jù)總體業(yè)務(wù)目標(biāo)確定優(yōu)先級(jí)

盡管這種措施似乎不言而喻，但在許多公司中，相應(yīng)的規(guī)范都是灰色理論。為了改變這一點(diǎn)，開發(fā)團(tuán)隊(duì)必須首先將利益相關(guān)者召集在一起并提高認(rèn)識(shí)。然后一起回答以下問題：主要目標(biāo)是什么？哪些標(biāo)準(zhǔn)適用于優(yōu)先級(jí)排序？如何協(xié)調(diào)利益沖突？

2.通過指標(biāo)創(chuàng)建和傳達(dá)交付透明度

如果每個(gè)人都清楚在哪個(gè)時(shí)間段內(nèi)提供哪些服務(wù)，那么每個(gè)相關(guān)人員將更容易將工作包放在一起，然后可以按計(jì)劃進(jìn)行處理。這還包括跟蹤變更請(qǐng)求的運(yùn)行時(shí)間并測(cè)量錯(cuò)誤率：多少變更實(shí)際上失敗并因此導(dǎo)致返工？

團(tuán)隊(duì)和利益相關(guān)者的定期報(bào)告是任何DevOps組織運(yùn)作的重要貢獻(xiàn)。此外，基本原則獨(dú)立于官方溝通而適用：每個(gè)人都應(yīng)該公開信息，以便每個(gè)人都可以適應(yīng)當(dāng)前情況。這樣，所有相關(guān)方都可以感知到改善或積極地為消除赤字做出貢獻(xiàn)。

3.與Scrum董事會(huì)和看板董事會(huì)組織工作

Scrum和看板等方法提供了有價(jià)值的工具，即使在復(fù)雜的環(huán)境中也可以保持焦點(diǎn)。但是僅靠工具是不夠的。團(tuán)隊(duì)的所有成員必須始終自覺地專注于共同目標(biāo)。僅僅因?yàn)橐豁?xiàng)任務(wù)可以快速，輕松地完成，并不一定有助于團(tuán)隊(duì)當(dāng)前的目標(biāo)。必須共同取得進(jìn)步。建立小批量，避免進(jìn)行中的工作以及完成任務(wù)很重要。

但是，某人一旦完成一項(xiàng)新任務(wù)就對(duì)團(tuán)隊(duì)并不總是有益的。為了實(shí)現(xiàn)沖刺目標(biāo)，在他人的任務(wù)中給予支持通常更為重要。此外，聯(lián)合工作可確保更好地補(bǔ)償單個(gè)團(tuán)隊(duì)成員的損失。

4.回顧–展望未來

定期回顧以持續(xù)改進(jìn)的行動(dòng)項(xiàng)目（措施）為重點(diǎn)，可以顯示過去有效的方法和無效的方法。這是改進(jìn)的基礎(chǔ)，也是尋找以下核心問題的答案的基礎(chǔ)：我們將如何做才能更好地管理整個(gè)流程？

但是，從過去的錯(cuò)誤和成功中學(xué)習(xí)還需要預(yù)先計(jì)劃時(shí)間。Gene Kim，Jez Humble和Patrick Debois在《 DevOps手冊(cè)》 [4]中建議將此類改進(jìn)節(jié)省20％的時(shí)間。

措施的實(shí)施是DevOps轉(zhuǎn)型的第一步，經(jīng)驗(yàn)表明：任何人都可以設(shè)置啟動(dòng)沖動(dòng)-無論是Biz，Dev還是Ops！

一個(gè)示例場(chǎng)景

這是一個(gè)典型的IT封鎖案例：一家大型機(jī)械工程公司的營(yíng)銷部門計(jì)劃了兩年后重新啟動(dòng)其網(wǎng)站。最初，通過網(wǎng)站可以增加潛在客戶。但是，所有業(yè)務(wù)的最高要求都被匯編成一個(gè)全新的網(wǎng)站概念。

結(jié)果：內(nèi)容管理系統(tǒng)（CMS）被一種產(chǎn)品取代，該產(chǎn)品的技術(shù)自身的IT人員沒有必要的專業(yè)知識(shí)。更改只能在外部實(shí)施。如果從BizDevOps的角度出發(fā)，營(yíng)銷和IT首先在具有A / B測(cè)試功能的現(xiàn)有解決方案的基礎(chǔ)上一起嘗試對(duì)客戶方法進(jìn)行具體更改，那將會(huì)更加有效。“向左移”的原則可確保更改在開發(fā)過程中的正確性及其可操作性。營(yíng)銷可以通過參與者使用假設(shè)將他們的要求降低到最小可行產(chǎn)品來做出貢獻(xiàn)。

中心問題是：能為客戶帶來利益的最低產(chǎn)品是什么？這不僅顯示所需的服務(wù)和功能是否正常運(yùn)行。相反，很清楚它們帶來了什么好處。這樣，IT和業(yè)務(wù)部門可以在密切協(xié)商中逐步擴(kuò)展產(chǎn)品。

這種假設(shè)驅(qū)動(dòng)的方法減少了開發(fā)中非實(shí)際需求所需的資源浪費(fèi)。對(duì)于最終用戶無用的功能在準(zhǔn)備投入市場(chǎng)之前不會(huì)進(jìn)行廣泛的修訂和測(cè)試，而是在原型階段進(jìn)行挑選。另一方面，先前項(xiàng)目的經(jīng)驗(yàn)表明，超過一半的工作量通?；ㄔ趯?duì)用戶不重要的功能上