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

該實踐被稱為DevOps出現于2007年，然后作為敏捷軟件開發被世人熟知。

 [[142382]]

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

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

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

2008年，全球經濟衰退，他所在的軟件開發部門的預算從1億美金縮減到5500萬美金。

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

三年后，他“完全重新架構”開發流程，并解決了固件引起的瓶頸問題。他也能釋放更多時間去創新。

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

Scrum不等同于敏捷

在大型企業中使得生產率不同的一個主要因素——某個時候，Gruver管理著800名開發者——是在執行級別應用敏捷原則。

多數組織關注如何讓團隊工作。團隊關注如何讓他們的單個項目運作，以及他們是否進行scrum(迭代式增量軟件開發)與其他“敏捷儀式”，如持續不斷地發布給用戶新版本。

如果大型企業只關注scrums，就可能丟失敏捷原則。

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

大型企業典型的敏捷部署是規劃好未來18個月要做的事情，團隊就做例如將軟件立項的事情，但發布并不持續。

“DevOps作為一個專業術語出現的原因在于敏捷忘記了持續發布的重要原則，”他說。

聚焦業務需求

知曉企業業務目標有助于創建一個愿景，并在轉向DevOps后對公司該做的事情列出優先順序。例如，在惠普，Gruver想消除固件瓶頸并為創新提供空間。

推動DevOps的IT人士也應該明白業務的成本驅動與周轉驅動。

“該旅程會持續一段時間，”Gruver說。

DevOps法則的應用需要跨所有層級協調，所有團隊需要接受使用相同的工具。

識別核心業務需求后，轉向DevOps的舉動應該包括將積壓工作分優先級的過程。最重要是，不要忘記持續向用戶發布***版本，并獲得一致的反饋。

他說：“如果你首先做的是最重要的事情，就能得到由企業帶領的持續學習過程，這做起來很輕松。”

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

“我們公司都沒有用DevOps，我想在我們的開發生命周期中獲得效率，快速獲取受支持的應用，”飛利浦高級應用開發人員Chris Flynn表示。他想實現自動發布于測試，因為目前他看見大量耗時的手動操作既不平滑也不輕松。

他希望部署持續的構建工作，對于獲得開發生命周期的效率與快速推出應用很感興趣。

這些更改從執行買入開始。“如果能讓執行層看見DevOps的重要性與收益，他們就會考慮這項技術，”Flynn說。

Harvard Pilgrim Health Care的工程師Ramesh Subramaniam表示，他的企業交付每月發布是一個勞動密集型過程，需要40個人來做，很容易出現人工錯誤。

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