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个人来做，很容易出现人工错误。
他说：“通过使用持续交付，我确定我们能消除一些错误。”
