gary gruver就像是從未來穿越來的人，早在十年前，他就供職于世界上最大的列印機制造商(惠普)，使用devops緩解軟體開發流程的擁塞問題。
該實踐被稱為devops出現于2007年，然後作為靈活軟體開發被世人熟知。
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個人來做，很容易出現人工錯誤。
他說：“通過使用持續傳遞，我确定我們能消除一些錯誤。”
作者：何妍
來源：51cto