如何確定DevOps變更的優先順序？

自動化一切！有多少人聽過這句話？有多少人被要求從事這項工作？如果您是軟體開發人員或DevOps工程師，那麼您就會確切地知道我在說什麼。也許您甚至想自己自動化一些事情*，*但是卻沒有足夠的時間完成工作？

任何IT專案都在努力獲取正確數量的資源，並在正確的時間進行正確的工作。那麼，您如何才能幫助和交流現在應該解決的最高優先順序的問題呢？以下是一個簡單的過程：

• 定義：找到痛點
• 範圍：進行需求分析
• 實驗：執行改進
• 分析：這將帶來多大的麻煩？值得投資嗎？
找到痛點

這通常是最容易的部分。它們在CI/CD管道中嗎？它們在工具中嗎？他們是流程嗎？您是否經常錯過專案截止日期？清楚地概述和定義您所看到的痛點。

通常，事情越痛苦，投入時間解決問題就越有價值。

執行需求分析

讓我們從行業術語定義開始：

需求分析是一個過程。雖然一個企業的生產量多少會取決於其生產能力，但是必須努力產生對其產品的潛在需求。

對於工程團隊而言，這實際上意味著我們需要了解是否確實有解決這些痛點的需求，或者這僅僅是單一資源所苦苦掙扎的事情。這通常是工程師和管理人員不同意的地方。對於像我這樣具有強大工程背景的人，這需要真正跨出您的舒適區域，並換上另一個鏡頭才能看到工作。

我很高興與之合作的最偉大的商業領袖之一告訴我：“我們不能僅僅因為重視IT而從事IT工作，而是必須從事能夠為企業帶來價值的工作。”

因此，可以說今天在多個環境中的部署是手動完成的，這對於系統工程師來說是一個痛苦的時刻。他們希望使這項工作自動化，並且管理層正在推遲其優先順序。為什麼會這樣呢？也許是因為我們每月僅釋出一次新版本的軟體？也許是因為我們只有4種環境可將程式碼推送到其中？也許是因為只有一個人需要這樣做，並且從來沒有遇到過完成工作後的問題？

儘管我無法描述所有可能的情況並給出示例，但我的最佳建議是從時間，人員和金錢方面考慮您的痛點。參與某事的人越多，花費的時間越多通常意味著更多的經濟影響。經濟影響越大，首先解決的問題就越痛苦且最可行。

改進



解釋這一點的最簡單方法是將其稱為概念的證明階段。花時間建立和定義計劃。事物的實際當前狀態是什麼？您想要達到的目標狀態是什麼？

不要嘗試一次自動化整個過程或所有事情。就像敏捷原則一樣，將其分解為一小部分變更，測試結果並分析資料。使用它可以為繼續進行此工作的價值管理提供更多證據。

優先順序排序

現在，您已經有了一個計劃和一些資料，可以開始計算出所建議的工作領域的價值所在，分析起來應該很簡單。這項改變將要實施多少麻煩？完全需要多長時間？值得投資嗎？

這應該可以幫助您從自己的團隊，管理層以及整個交付團隊中獲得支援！最終成功的變更意味著相關人員已經融入了新流程。

結論

DevOps很難。該術語涵蓋了SDLC的各個方面，並且在改進方面從未缺少任何想法。作為DevOps的工程師，我們需要幫助降低錯誤並找到真正的方向，從而為業務帶來收益。只要您看到應該完成的工作專案，就可以按照此過程進行操作，您將迅速影響更高階別的專案任務。

原文地址：https://www.linuxprobe.com/devops-change-priority.html