CODING Compass —— 打造行云流水般的軟件工廠,coding 免費編碼指南針——構(gòu)建流動的軟件工廠根據(jù)編碼指南針產(chǎn)品總監(jiān)程勝聰在騰訊云CIF工程效率峰會上所做的分享,本文進行了整理和更新。DevOps已從工具階段進入流程階段從20世紀60年代到現(xiàn)在,軟件工程無疑處于DevOps時代,這幾年DevOps在業(yè)......
根據(jù)編碼指南針產(chǎn)品總監(jiān)程勝聰在騰訊云CIF工程效率峰會上所做的分享,本文進行了整理和更新。
DevOps已從工具階段進入流程階段
從20世紀60年代到現(xiàn)在,軟件工程無疑處于DevOps時代,這幾年DevOps在業(yè)界的轉(zhuǎn)型也證明了這一點。到了這個階段,企業(yè)這么多年都在投入轉(zhuǎn)型,都渴望看到成果。大家普遍在思考一個問題,那就是DevOps是否真的有助于業(yè)務發(fā)展和數(shù)字化轉(zhuǎn)型,還是僅僅是R&D團隊的自我滿足?
在最近一年協(xié)助客戶推出DevOps產(chǎn)品的過程中,我們越來越意識到,研發(fā)管理不能僅僅依靠構(gòu)建工具鏈,還需要將這些工具應用到企業(yè)的實際業(yè)務流程中。我們應該切實減輕發(fā)展的負擔,而不是增加業(yè)務發(fā)展的負擔。只有這樣,才能有效提高R&D效率,更好地滿足業(yè)務發(fā)展的需要。
如果說之前DevOps處于工具化階段,各種工具層出不窮,那么在數(shù)字化業(yè)務快速發(fā)展的大背景下,DevOps正在進入一個新的階段:流程化階段。
企業(yè)使用DevOps工具仍然面臨挑戰(zhàn)
從一個典型的用戶反饋出發(fā),我們來看看用戶目前的困境:
上面這位客戶已經(jīng)深度使用編碼一年多了,對于產(chǎn)品是否好用,他們有足夠的發(fā)言權(quán)。通過對反饋結(jié)果的梳理,可以看出樂器階段的產(chǎn)品還存在一些不足。一方面,客戶充分肯定了當初選擇編碼DevOps的決定,團隊中的每個角色都能夠在一站式平臺上工作,從而實現(xiàn)了R&D集成的目標。另一方面,雖然我們的一站式平臺提供了團隊需要的能力模塊,但是不同模塊之間的協(xié)作并不能得到很好的體現(xiàn)。
1.對于一個產(chǎn)品來說,它所關(guān)注的需求活動并不能很好的關(guān)聯(lián)到開發(fā)實際在做什么,所以它不能完全控制進度和風險。
2.對于開發(fā)來說,更新任務狀態(tài)是很重要的,但是既然這個東西不會擋住你,是否及時更新就完全看意識水平了。所以很多時候,忙于協(xié)作編程的開發(fā)人員經(jīng)常會忘記這樣做。
3.同時,作為一項相對落后的測試,一旦進行測試,各種項目都要檢查,各種信息的核對和更新都要花費大量的時間。再加上考試剩下的時間不多,所以情況特別尷尬。
4.更別說后面的運維同事,只能被告知反復發(fā)布版本前要做好充分準備,各種驗證檢查不能打折扣。然后他們只能祈禱各種莫名其妙的問題不要總是出現(xiàn)在敏感的發(fā)布窗口。
總的來說,雖然一個平臺上不同的工具大家都用的很流暢,但是整個過程總會有所缺失。工具之間來回切換還是要耗費大量的精力,信息的正確性也無法保證。這些都是工具類產(chǎn)品的短板。
企業(yè)越來越重視研發(fā)管理的整體效率
這個案例并不是個例,而是DevOps轉(zhuǎn)型到了一個新的流程階段的標志:企業(yè)越來越重視研發(fā)管理的整體效率,從強調(diào)某個工具的局部優(yōu)化,到強調(diào)協(xié)同流程的全局優(yōu)化。
工具不能等同于整體效率。組織效率管理的經(jīng)典理論PPT指出,組織的三要素中,人和人是基礎(chǔ)。工具和工具賦能人們更高效地工作,而過程和流程是人們行為與目標保持一致的載體。完美地做一件不該做的事毫無意義,甚至可能對整體造成損害。從全局考慮,好的流程是不可或缺的。
DevOps產(chǎn)品應內(nèi)置于
進一步解放生產(chǎn)力的新生產(chǎn)關(guān)系
數(shù)字化背景下,業(yè)務的快速發(fā)展帶來了軟件系統(tǒng)的高復雜度,個人需要處理的事情變多,導致單人效率下降。為了提高團隊中各個角色的工作效率,企業(yè)追求DevOps轉(zhuǎn)型,希望利用新興技術(shù)和工具快速提升團隊生產(chǎn)力。然而,隨著技術(shù)和工具投入的不斷增加,團隊規(guī)模的不斷擴大,也帶來了整體協(xié)作的復雜性。但是這些復雜的依賴關(guān)系像金字塔一樣傳導到團隊成員身上,對原有的工作習慣甚至理解和認知形成了巨大的沖擊。即使是一個簡單的交付,也需要很多操作和不同角色的配合,所以整個交付過程是脆弱而低效的:比如上下游工作的合同和規(guī)范缺失,R&D過程的透明度不夠,需要在不同的工具平臺之間來回切換等等。
不同的工具如何在一個完整的流程中有機共存?如何為團隊打造一個高效的流程,讓人們順利完成高質(zhì)量的軟件開發(fā)并發(fā)布到生產(chǎn)環(huán)境中?在這個過程中,團隊成員不需要處理不必要的復雜問題,不需要糾結(jié)于小細節(jié),也不需要等待很長時間。我們應該解放團隊成員的生產(chǎn)力,讓開發(fā)人員可以專注于真正能產(chǎn)生商業(yè)價值的工作。這是目前值得思考的事情:正如生產(chǎn)力決定生產(chǎn)關(guān)系一樣,我們需要更先進的研發(fā)管理產(chǎn)品來賦能R&D團隊,以滿足當今數(shù)字化業(yè)務發(fā)展的需求。
編碼指南針
處于DevOps流程階段的R&D流程管理產(chǎn)品
通過梳理DevOps實踐中的突出問題,我們得到了以下兩點認識:
1。組織級別的開發(fā)運維轉(zhuǎn)型需要領(lǐng)域?qū)<?/strong>
7月,信通院發(fā)布的《中國DevOps現(xiàn)狀調(diào)查報告(2021)》指出,由于缺乏DevOps專家,近三成企業(yè)推進緩慢。而我們在服務客戶的時候,往往需要提供咨詢,通過專家診斷,制定出流程,然后根據(jù)實際情況設定要推進的目標和具體的實現(xiàn)路徑。DevOps產(chǎn)品需要做的是:提取行業(yè)內(nèi)有效的研發(fā)管理經(jīng)驗,嵌入到產(chǎn)品中,引導客戶團隊固化并持續(xù)優(yōu)化優(yōu)秀習慣,從而實現(xiàn)高效的研發(fā)管理。
2。團隊成員在協(xié)作中最大的痛點就是“無所不知”[S2/]
在現(xiàn)有提供的工具的基礎(chǔ)下,團隊可以在對DevOps有簡單了解的情況下開始協(xié)同工作。然而,用戶面臨的協(xié)作問題確實存在:例如,缺乏跨職能活動的能力,缺乏活動之間的協(xié)作規(guī)范,難以識別R&D過程中的風險,個人在工作中需要了解的上下文太多,以及許多只能手動處理的跨職能操作等。這些看似瑣碎,但如果這些問題日積月累,得不到解決,就會造成團隊成員極大的“精神疲憊”,甚至導致優(yōu)秀員工對構(gòu)建高效組織產(chǎn)生懷疑。
DevOps深化發(fā)展到現(xiàn)在,代表了業(yè)界對研發(fā)管理產(chǎn)品的新期待:從敏捷到DevOps,結(jié)合LEAN的精益思想,正在向增強可視化和可追溯性,追求標準化和高效化的方向發(fā)展?;谶@些感知到的痛點,CODING結(jié)合自身的實踐和行業(yè)成就的經(jīng)驗,努力提升產(chǎn)品,幫助客戶更好地提升研發(fā)管理能力。
Compass=工作流+規(guī)范+自動化
編碼創(chuàng)造了一個全新的R&D過程管理產(chǎn)品Compass,它包括三個主要能力:工作流(串聯(lián)各種活動形成的協(xié)同)、規(guī)范(提高R&D活動一致性的標準)、自動化(活動后的觸發(fā))。意味著編碼DevOps是在原有DevOps工具鏈的基礎(chǔ)的基礎(chǔ)上,融入了Knowhow的部分,讓客戶充分借鑒行業(yè)內(nèi)有效的實踐經(jīng)驗,實現(xiàn)高效的研發(fā)管理。
Compass如何提升研發(fā)管理能力
簡單來說,Compass的產(chǎn)品邏輯就是定義流程,規(guī)范流程,高效循環(huán),識別瓶頸,引導改進。
1。首先,R&D進程中有各種各樣的活動。
例如,產(chǎn)品經(jīng)理將在Backlog中創(chuàng)建需求,團隊規(guī)劃將包含在迭代中,任務將被分解、聲明或分配。開發(fā)將創(chuàng)建分支,編寫代碼,提交和合并等。,而測試是設計用例,執(zhí)行測試,然后團隊會測試,通過質(zhì)量控制,然后創(chuàng)建發(fā)布表單等。
我們知道,這里列出的一些發(fā)生在同一個角色內(nèi)部,而另一些則需要不同的角色來合作。事實上,它們是按順序進行的。
2。其次,確定關(guān)鍵的協(xié)作活動,并將其串聯(lián)起來,形成一個完整的工作流程。
將這些活動按照不同的角色進行分類后,我們會發(fā)現(xiàn),同一角色的某些活動客觀上是其他活動的前提。比如需求創(chuàng)建后,可以包含在迭代中,分支存在后,可以有相應的代碼提交和MR,用例設計后,可以在其基礎(chǔ)上關(guān)聯(lián)相應的需求,等等。這些內(nèi)在的聯(lián)系導致了他們活動的自發(fā)完成。
對于剩下的關(guān)鍵節(jié)點,我們從整體R&D的角度出發(fā),人為定義它們的依賴順序,并根據(jù)實際工作情況串聯(lián)起來。比如任務分解后,可以創(chuàng)建相應的特征分支;在MR可用,并且需求與測試用例相關(guān)聯(lián)之后,就可以進行測試,給出測試報告,最后提交發(fā)布單。這就形成了一個完整的工作流程。
3。第三,活動的健壯流程通過規(guī)范來保證,自動化驅(qū)動活動的高效流程。
為了保證活動流通的穩(wěn)健性,我們可以對一些活動設置準入和退出規(guī)范,對不符合規(guī)范的給予警告,阻止其繼續(xù)流通。例如,包含在迭代中的需求應該給出驗收標準,這應該作為用例設計的基礎(chǔ),測試報告中的通過率應該滿足某個值,然后才能創(chuàng)建發(fā)布單。此外,對于一些可以以標準化方式創(chuàng)建或觸發(fā)的活動,可以設置自動化規(guī)則。當前提條件滿足時,它將自動流動,不需要團隊成員切換到另一個工具來更新狀態(tài)或手動創(chuàng)建下一個任務。這樣就形成了有序的團隊協(xié)作工作流程。
4。最后,將R&D的具體步驟與定義的業(yè)務價值流階段對應起來,以提供洞察分析。
而標準化和自動化可以產(chǎn)生準確的活動記錄,從而為效率衡量提供真實可靠的數(shù)據(jù),進行有效的洞察診斷,指導改進。比如提前期和加工時間的差異,任務完成率/準確率等。這就是價值流管理的基礎(chǔ)。
以上是指南針的產(chǎn)品設計理念。我們希望流程中的每個人都能夠通過在整個流程中協(xié)作驅(qū)動開發(fā)行為來關(guān)注自己的價值。同時,沉淀的過程數(shù)據(jù)可以準確看到R&D過程,并基于對數(shù)據(jù)的洞察分析,指導R&D過程的持續(xù)改進。
摘要[/s2/]
編碼羅盤是R&D流程管理基于編碼羅盤原有DevOps工具鏈的產(chǎn)品,包括流程安排、流程驅(qū)動、規(guī)則約束、價值流轉(zhuǎn)。希望能幫助企業(yè)以最低的協(xié)同成本實現(xiàn)最高的響應能力,從而最大化R&D效率。
特別聲明:以上文章內(nèi)容僅代表作者本人觀點,不代表ESG跨境電商觀點或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。
二維碼加載中...
使用微信掃一掃登錄
使用賬號密碼登錄
平臺顧問
微信掃一掃
馬上聯(lián)系在線顧問
小程序
ESG跨境小程序
手機入駐更便捷
返回頂部