協作。自動化。問責製。集成。監控。能見度/透明度。DevOps有很多組件，但最終都是關於速度的。如何更快地發布有價值的應用程序……同時保證對你的業務有意義的安全和質量?
毫不奇怪，“加速”的壓力對開發者的打擊最大。但頂尖的開發人員很難招到，挽留成本很高，而且很容易流失。持續不斷的壓力，讓你奇跡般地做得更多、更快——尤其是當團隊的其他成員沒有同樣快和高效的時候——最終會讓開發人員感到沮喪，讓你最有價值的資產處於危險之中。
這裏有一些經過驗證的策略，可以在不增加開發人員負擔的情況下加速應用程序交付。
民主化與low-code /沒有代碼
低代碼/無代碼開發是組織滿足更快交付更多軟件的無情需求的一種方式。通過允許非程序員通過用戶友好的界麵構建和定製標準的業務工作流，低代碼/無代碼本質上“民主化”了通用(通常是無區別的)應用程序的開發。它還可以幫助開發人員快速完成許多常規任務，而不用擔心低層次的實現細節……這樣他們就可以將時間和精力集中在更具戰略性和挑戰性的任務上，從而使您的業務與眾不同。
同樣地，您也可以將測試自動化大眾化，這通常會消耗開發人員的時間，因為傳統的測試自動化方法需要腳本專業知識。就像低代碼/無代碼開發允許非程序員構建他們自己的應用程序一樣，無腳本測試方法(如基於模型的測試和基於視覺的測試自動化)允許任何業務用戶檢查他們“擁有的”功能是否如預期的那樣工作。
致力於全麵提高技能
大多數企業組織都有很多高效的DevOps團隊，但是他們很難在更廣泛的組織中擴展他們的實踐，更有意義的是，他們的成功。事實上，DevOps的規模化是很困難的。DevOps研究所最近發現，超過50%的組織仍然報告說DevOps之旅仍然是一個挑戰。同一項研究還發現，DevOps成功的最關鍵因素實際上是提高整個團隊的技能，包括流程技能和知識、自動化技能和“人類技能”(如協作、人際交往技能、解決問題等)。DevOps Institute聯合創始人兼首席執行官傑恩·格羅爾總結得很好“我們必須像我們的技術一樣，以同樣的重點，經常通過新技能更新我們的人類。”
需要明確的是，這裏的行動項目並不是教每個人DevOps的每個方麵。它是為了確保每個團隊成員(從開發人員、測試人員、scrum管理員到SRE)都能有效地為快速交付優秀軟件的共同使命做出貢獻。正如Merck公司的退休CIO Clark Golestani所分享的那樣:對於開發者來說，沒有什麼比匆忙地快速構建一些東西，然後因為測試、運營或其他一些角色沒有按照預期的速度執行而導致發布延遲更讓人沮喪的了。
僅靠持續交付無法迅速向業務交付價值。參與“持續一切”的每個人——持續集成、持續測試、持續監控，等等——都必須表現最佳，並且能夠隨時訪問各種工具和資源，從而使他們的成功最大化。
連接所有這些點，是實時的
在今天的DevOps過程中發布的應用程序是許多不同組件(移動+大型機+微服務+ api +打包應用……)的產品，這些組件由不同的團隊、不同的時間表、使用不同的工具開發。如果你缺乏對整個應用程序發布準備的實時洞察，你可能會陷入以下兩種陷阱之一(兩者都會影響你的發布速度和吞吐量):
- 你將問題釋放到生產中。這意味著開發人員隨後必須停止他們正在做的事情，花時間重新熟悉功能，找出解決問題的方法，並與QA合作以確保問題得到真正解決(並且不會在過程中無意中破壞其他東西)。
- 你在不必要地拖延發布。當完成了低效的測試後，組織推遲交付的情況並不少見，結果發現他們本可以提前幾周發布的……如果質量反饋能夠更快地提供的話。
對於每個團隊和每個組件，在計劃、開發、構建、測試、發布和操作工具的不同實例中可能隱藏著大量豎井數據點。如果您可以解鎖這些數據來構建一個清晰、準確的發布評估，那麼您就可以在準備好時發布……而不必擔心生產問題會影響您的後續發布。自動化收集這些關鍵數據點的能力越強，就越能有效地解決關鍵問題——這樣就能更快地到達終點線。
最重要的是，確保持續識別並積極地消除當前組織的最大限製。通常，這是你不會懷疑的事情;例如，最新的GitLab調查發現，排在第一位的延遲是測試(47%)，其次是計劃(39%)。編寫代碼排在第三位，占30%。這些發現強調，為了加速交付，不僅有可能，而且有必要超越開發。
當然，您的瓶頸會有所不同。像價值流管理和軟件交付管理這樣的實踐將幫助您確定最危險的延遲的原因。有了這些知識，您就可以著手打破瓶頸並加速交付……而不會讓您的開發人員感到精疲力竭。
*最初發表於福布斯