Gary Gruver就像是從未來穿越來的人，早在十年前，他就供職于世界上***的打印機(jī)制造商(惠普)，使用DevOps緩解軟件開發(fā)流程的擁塞問題。

該實(shí)踐被稱為DevOps出現(xiàn)于2007年，然后作為敏捷軟件開發(fā)被世人熟知。

 [[142382]]

20年來，惠普的打印業(yè)務(wù)由于其固件而增長緩慢，該公司無法在沒有附件更新的情況下添加新產(chǎn)品、新功能與容量。2007年，Gruver接管了惠普的軟件開發(fā)工作。

他的故事從這啟程，之后在Macys.com(美國梅西百貨的官網(wǎng))獲得成功。

“固件在過去20年已成為激光打印業(yè)務(wù)的瓶頸，”他表示惠普一直在努力嘗試解決該問題。

2008年，全球經(jīng)濟(jì)衰退，他所在的軟件開發(fā)部門的預(yù)算從1億美金縮減到5500萬美金。

他說：“那我只能竭盡全力尋找讓工作更具生產(chǎn)力的方式。”

三年后，他“完全重新架構(gòu)”開發(fā)流程，并解決了固件引起的瓶頸問題。他也能釋放更多時(shí)間去創(chuàng)新。

“多數(shù)我服務(wù)的企業(yè)看起來更像是轉(zhuǎn)變之前，而非轉(zhuǎn)變之后的企業(yè)。”他說，“長期以來我都不知道自己很敏捷，我覺得與以前相比沒變化。”

Scrum不等同于敏捷

在大型企業(yè)中使得生產(chǎn)率不同的一個(gè)主要因素——某個(gè)時(shí)候，Gruver管理著800名開發(fā)者——是在執(zhí)行級(jí)別應(yīng)用敏捷原則。

多數(shù)組織關(guān)注如何讓團(tuán)隊(duì)工作。團(tuán)隊(duì)關(guān)注如何讓他們的單個(gè)項(xiàng)目運(yùn)作，以及他們是否進(jìn)行scrum(迭代式增量軟件開發(fā))與其他“敏捷儀式”，如持續(xù)不斷地發(fā)布給用戶新版本。

如果大型企業(yè)只關(guān)注scrums，就可能丟失敏捷原則。

他表示，Scrum并不等同于敏捷。

大型企業(yè)典型的敏捷部署是規(guī)劃好未來18個(gè)月要做的事情，團(tuán)隊(duì)就做例如將軟件立項(xiàng)的事情，但發(fā)布并不持續(xù)。

“DevOps作為一個(gè)專業(yè)術(shù)語出現(xiàn)的原因在于敏捷忘記了持續(xù)發(fā)布的重要原則，”他說。

聚焦業(yè)務(wù)需求

知曉企業(yè)業(yè)務(wù)目標(biāo)有助于創(chuàng)建一個(gè)愿景，并在轉(zhuǎn)向DevOps后對(duì)公司該做的事情列出優(yōu)先順序。例如，在惠普，Gruver想消除固件瓶頸并為創(chuàng)新提供空間。

推動(dòng)DevOps的IT人士也應(yīng)該明白業(yè)務(wù)的成本驅(qū)動(dòng)與周轉(zhuǎn)驅(qū)動(dòng)。

“該旅程會(huì)持續(xù)一段時(shí)間，”Gruver說。

DevOps法則的應(yīng)用需要跨所有層級(jí)協(xié)調(diào)，所有團(tuán)隊(duì)需要接受使用相同的工具。

識(shí)別核心業(yè)務(wù)需求后，轉(zhuǎn)向DevOps的舉動(dòng)應(yīng)該包括將積壓工作分優(yōu)先級(jí)的過程。最重要是，不要忘記持續(xù)向用戶發(fā)布***版本，并獲得一致的反饋。

他說：“如果你首先做的是最重要的事情，就能得到由企業(yè)帶領(lǐng)的持續(xù)學(xué)習(xí)過程，這做起來很輕松。”

一些人表示將參照這些技巧開啟DevOps使用之旅。

“我們公司都沒有用DevOps，我想在我們的開發(fā)生命周期中獲得效率，快速獲取受支持的應(yīng)用，”飛利浦高級(jí)應(yīng)用開發(fā)人員Chris Flynn表示。他想實(shí)現(xiàn)自動(dòng)發(fā)布于測試，因?yàn)槟壳八匆姶罅亢臅r(shí)的手動(dòng)操作既不平滑也不輕松。

他希望部署持續(xù)的構(gòu)建工作，對(duì)于獲得開發(fā)生命周期的效率與快速推出應(yīng)用很感興趣。

這些更改從執(zhí)行買入開始。“如果能讓執(zhí)行層看見DevOps的重要性與收益，他們就會(huì)考慮這項(xiàng)技術(shù)，”Flynn說。

Harvard Pilgrim Health Care的工程師Ramesh Subramaniam表示，他的企業(yè)交付每月發(fā)布是一個(gè)勞動(dòng)密集型過程，需要40個(gè)人來做，很容易出現(xiàn)人工錯(cuò)誤。

他說：“通過使用持續(xù)交付，我確定我們能消除一些錯(cuò)誤。”