Gartner的研究主管George Spafford說：“由於缺少標準的定義和方法，處於不斷發展中，需要接受和管理風險，DevOps對傳統IT思維提出了挑戰。這個不確切的目標狀態導致許多IT部門猶豫不決、不敢實施DevOps策略。”
雖然沒有一系列具體的所需階段，但Spafford建議基礎設施及運營（I&O）領導人可以遵循這八個基本步驟來搞好DevOps項目。
1. 確定業務理由
DevOps項目要關注業務需求，而不是“純粹爲了DevOps搞DevOps”，避免方法和工具變得比客戶需求還重要。企業要避免這個常見的錯誤：還沒有明確搞DevOps項目的業務理由，就貿然上馬。
Spafford解釋到：“比如說，先從業務價值入手，問問DevOps能帶來什麼，而不是專注於發佈速度、更快地完成工作。理由可能是‘通過提升發佈速度，我們能夠更快地創新，從而支持銷售和營銷部門使用移動應用進行訂購。’最成功的企業希望通過DevOps獲得業務的好處。”
2. 爲所在企業定義DevOps
Gartner對DevOps下的定義是：這是一種使用敏捷方法、協作和自動化交付解決方案的業務驅動方法。能以所在企業易懂的措辭來定義目標狀態顯得很重要。爲項目挑一個標籤，提供員工認同和支持的一個“標語”，這有助於員工參與進來。這個定義應簡短、明確重點，並支持業務理由。
3. 選擇“先行者”應用軟件
別指望一個步驟就部署好DevOps。DevOps要迭代式部署，每次同時滿足這三個要素：
友好的環境：這意味着大家願意使用先行者應用軟件，真心嘗試項目。
可接受的價值：先行者應用軟件要提供足夠的價值以贏得信譽和批准，以便繼續下去。
可接受的風險：由於DevOps方面的不確定性，許多人認爲它風險很高，害怕開始入手。企業應指出風險可接受的機會，因爲IT、運營、開發、信息安全，法規遵從和審計等部門的每個人都要學習。
Spafford說：“DevOps主要用於敏捷開發以及不確定性相當大的場景（比如機器學習和物聯網），但由於DevOps理念可以廣泛應用，所以會有引入這套概念的其他機會。然而，最初運用於創新的系統通常比較好，因爲現有功能可能無法支持像大數據、機器學習和物聯網這些項目。”
4. 確定初始團隊
人員是成功的DevOps項目的主要因素。挑選初始團隊的成員時，要注重行爲而不是注重技能。教技術技能比教正確行爲來得容易――錯誤的行爲會使DevOps工作偏離正常進程。物色優秀的團隊成員，要聰明、有幹勁，瞭解風險，致力於終生學習，還能適應新的工作方式。
5. 確立目標和度量指標
因爲人員是DevOps項目中最重要的因素，瞭解和實施合適的激勵措施至關重要。Spafford說：“在許多傳統企業，目標由各部門確立，IT度量指標落實到位，以解決問題，獎勵解決問題的人員。”
“在DevOps項目中，目標要由團隊確立，並與下達給團隊的業務目標保持一致。DevOps團隊成員要認識到他們都有同一個目標，度量指標和激勵措施要鼓勵團隊合作以實現業務目標，而不是度量指標強化風險規避和解決個別問題。”
6. 專注於限制因素
I&O領導人應找出限制生產能力的最大瓶頸。開發新的和變更的系統，並轉移到生產環境中，這個生命週期會帶來最大的限制因素，因而限制生產能力。如果專注於這個最大的限制因素，DevOps團隊就能系統地識別什麼在阻礙所需的工作節奏，並克服這個瓶頸。
7. 開發工具鏈
實施DevOps的總體目標包括一套集成的工具鏈，支持合理地評估和選擇工具，以便每個工具都與應用程序生命週期中的相鄰工具鬆散耦合。連接所有的自動化接觸點和信息流可藉助工具鏈來加快版本的發佈，同時減少錯誤、缺陷、返工和停運。這將讓在每個階段使用的工具得以保持一致，便於瞭解在階段內和階段之間哪個地方需要實現自動化、集成和工具轉換。
8. 準備好後擴展
太多的公司犯這樣的錯誤：開始DevOps之前就需要擴展，以便獲得批准。這導致了惡性循環。因爲他們不知道如何擴展DevOps，所以無法開始。而由於他們無法開始，就無法摸索並搞清楚如何擴展。
Spafford建議：“切莫還沒有準備好就試圖擴展，結果讓靠譜的DevOps項目偏離正道。”
“相反，把團隊召集起來，開始朝着似乎最有意義的方向前進，克服遇到的限制因素。人員、技術和流程方面一定要循序漸進。帶來技術債務是不可避免的，而管理這種債務是新模式的一部分。”