如何確定DevOps變更的優(yōu)先級(jí)?
自動(dòng)化一切!有多少人聽過這句話?有多少人被要求從事這項(xiàng)工作?如果您是軟件開發(fā)人員或DevOps工程師,那么您就會(huì)確切地知道我在說什么。也許您甚至想自己自動(dòng)化一些事情*,*但是卻沒有足夠的時(shí)間完成工作?
任何IT項(xiàng)目都在努力獲取正確數(shù)量的資源,并在正確的時(shí)間進(jìn)行正確的工作。那么,您如何才能幫助和交流現(xiàn)在應(yīng)該解決的最高優(yōu)先級(jí)的問題呢?以下是一個(gè)簡單的過程:
- 定義:找到痛點(diǎn)
- 范圍:進(jìn)行需求分析
- 實(shí)驗(yàn):運(yùn)行改進(jìn)
- 分析:這將帶來多大的麻煩?值得投資嗎?
找到痛點(diǎn)
這通常是最容易的部分。它們?cè)贑I/CD管道中嗎?它們?cè)诠ぞ咧袉??他們是流程嗎?您是否?jīng)常錯(cuò)過項(xiàng)目截止日期?清楚地概述和定義您所看到的痛點(diǎn)。
通常,事情越痛苦,投入時(shí)間解決問題就越有價(jià)值。
執(zhí)行需求分析
讓我們從行業(yè)術(shù)語定義開始:
需求分析是一個(gè)過程。雖然一個(gè)企業(yè)的生產(chǎn)量多少會(huì)取決于其生產(chǎn)能力,但是必須努力產(chǎn)生對(duì)其產(chǎn)品的潛在需求。
對(duì)于工程團(tuán)隊(duì)而言,這實(shí)際上意味著我們需要了解是否確實(shí)有解決這些痛點(diǎn)的需求,或者這僅僅是單一資源所苦苦掙扎的事情。這通常是工程師和管理人員不同意的地方。對(duì)于像我這樣具有強(qiáng)大工程背景的人,這需要真正跨出您的舒適區(qū)域,并換上另一個(gè)鏡頭才能看到工作。
我很高興與之合作的最偉大的商業(yè)領(lǐng)袖之一告訴我:“我們不能僅僅因?yàn)橹匾旾T而從事IT工作,而是必須從事能夠?yàn)槠髽I(yè)帶來價(jià)值的工作。”
因此,可以說今天在多個(gè)環(huán)境中的部署是手動(dòng)完成的,這對(duì)于系統(tǒng)工程師來說是一個(gè)痛苦的時(shí)刻。他們希望使這項(xiàng)工作自動(dòng)化,并且管理層正在推遲其優(yōu)先級(jí)。為什么會(huì)這樣呢?也許是因?yàn)槲覀兠吭聝H發(fā)布一次新版本的軟件?也許是因?yàn)槲覀冎挥?種環(huán)境可將代碼推送到其中?也許是因?yàn)橹挥幸粋€(gè)人需要這樣做,并且從來沒有遇到過完成工作后的問題?
盡管我無法描述所有可能的情況并給出示例,但我的最佳建議是從時(shí)間,人員和金錢方面考慮您的痛點(diǎn)。參與某事的人越多,花費(fèi)的時(shí)間越多通常意味著更多的經(jīng)濟(jì)影響。經(jīng)濟(jì)影響越大,首先解決的問題就越痛苦且最可行。
改進(jìn)
解釋這一點(diǎn)的最簡單方法是將其稱為概念的證明階段?;〞r(shí)間創(chuàng)建和定義計(jì)劃。事物的實(shí)際當(dāng)前狀態(tài)是什么?您想要達(dá)到的目標(biāo)狀態(tài)是什么?
不要嘗試一次自動(dòng)化整個(gè)過程或所有事情。就像敏捷原則一樣,將其分解為一小部分變更,測(cè)試結(jié)果并分析數(shù)據(jù)。使用它可以為繼續(xù)進(jìn)行此工作的價(jià)值管理提供更多證據(jù)。
優(yōu)先級(jí)排序
現(xiàn)在,您已經(jīng)有了一個(gè)計(jì)劃和一些數(shù)據(jù),可以開始計(jì)算出所建議的工作領(lǐng)域的價(jià)值所在,分析起來應(yīng)該很簡單。這項(xiàng)改變將要實(shí)施多少麻煩?完全需要多長時(shí)間?值得投資嗎?
這應(yīng)該可以幫助您從自己的團(tuán)隊(duì),管理層以及整個(gè)交付團(tuán)隊(duì)中獲得支持!最終成功的變更意味著相關(guān)人員已經(jīng)融入了新流程。
結(jié)論
DevOps很難。該術(shù)語涵蓋了SDLC的各個(gè)方面,并且在改進(jìn)方面從未缺少任何想法。作為DevOps的工程師,我們需要幫助降低錯(cuò)誤并找到真正的方向,從而為業(yè)務(wù)帶來收益。只要您看到應(yīng)該完成的工作項(xiàng)目,就可以按照此過程進(jìn)行操作,您將迅速影響更高級(jí)別的項(xiàng)目任務(wù)。































