CODING Compass —— 打造行云流水般的軟件工廠,coding 免費-ESG跨境

CODING Compass —— 打造行云流水般的軟件工廠,coding 免費

編碼指南針——構(gòu)建流動的軟件工廠

根據(jù)編碼指南針產(chǎn)品總監(jiān)程勝聰在騰訊云CIF工程效率峰會上所做的分享，本文進(jìn)行了整理和更新。

DevOps已從工具階段進(jìn)入流程階段

從20世紀(jì)60年代到現(xiàn)在，軟件工程無疑處于DevOps時代，這幾年DevOps在業(yè)界的轉(zhuǎn)型也證明了這一點。到了這個階段，企業(yè)這么多年都在投入轉(zhuǎn)型，都渴望看到成果。大家普遍在思考一個問題，那就是DevOps是否真的有助于業(yè)務(wù)發(fā)展和數(shù)字化轉(zhuǎn)型，還是僅僅是R&D團(tuán)隊的自我滿足？

在最近一年協(xié)助客戶推出DevOps產(chǎn)品的過程中，我們越來越意識到，研發(fā)管理不能僅僅依靠構(gòu)建工具鏈，還需要將這些工具應(yīng)用到企業(yè)的實際業(yè)務(wù)流程中。我們應(yīng)該切實減輕發(fā)展的負(fù)擔(dān)，而不是增加業(yè)務(wù)發(fā)展的負(fù)擔(dān)。只有這樣，才能有效提高R&D效率，更好地滿足業(yè)務(wù)發(fā)展的需要。

如果說之前DevOps處于工具化階段，各種工具層出不窮，那么在數(shù)字化業(yè)務(wù)快速發(fā)展的大背景下，DevOps正在進(jìn)入一個新的階段:流程化階段。

企業(yè)使用DevOps工具仍然面臨挑戰(zhàn)

從一個典型的用戶反饋出發(fā)，我們來看看用戶目前的困境:

上面這位客戶已經(jīng)深度使用編碼一年多了，對于產(chǎn)品是否好用，他們有足夠的發(fā)言權(quán)。通過對反饋結(jié)果的梳理，可以看出樂器階段的產(chǎn)品還存在一些不足。一方面，客戶充分肯定了當(dāng)初選擇編碼DevOps的決定，團(tuán)隊中的每個角色都能夠在一站式平臺上工作，從而實現(xiàn)了R&D集成的目標(biāo)。另一方面，雖然我們的一站式平臺提供了團(tuán)隊需要的能力模塊，但是不同模塊之間的協(xié)作并不能得到很好的體現(xiàn)。

1.對于一個產(chǎn)品來說，它所關(guān)注的需求活動并不能很好的關(guān)聯(lián)到開發(fā)實際在做什么，所以它不能完全控制進(jìn)度和風(fēng)險。

2.對于開發(fā)來說，更新任務(wù)狀態(tài)是很重要的，但是既然這個東西不會擋住你，是否及時更新就完全看意識水平了。所以很多時候，忙于協(xié)作編程的開發(fā)人員經(jīng)常會忘記這樣做。

3.同時，作為一項相對落后的測試，一旦進(jìn)行測試，各種項目都要檢查，各種信息的核對和更新都要花費大量的時間。再加上考試剩下的時間不多，所以情況特別尷尬。

4.更別說后面的運維同事，只能被告知反復(fù)發(fā)布版本前要做好充分準(zhǔn)備，各種驗證檢查不能打折扣。然后他們只能祈禱各種莫名其妙的問題不要總是出現(xiàn)在敏感的發(fā)布窗口。

總的來說，雖然一個平臺上不同的工具大家都用的很流暢，但是整個過程總會有所缺失。工具之間來回切換還是要耗費大量的精力，信息的正確性也無法保證。這些都是工具類產(chǎn)品的短板。

企業(yè)越來越重視研發(fā)管理的整體效率

這個案例并不是個例，而是DevOps轉(zhuǎn)型到了一個新的流程階段的標(biāo)志:企業(yè)越來越重視研發(fā)管理的整體效率，從強(qiáng)調(diào)某個工具的局部優(yōu)化，到強(qiáng)調(diào)協(xié)同流程的全局優(yōu)化。

工具不能等同于整體效率。組織效率管理的經(jīng)典理論P(yáng)PT指出，組織的三要素中，人和人是基礎(chǔ)。工具和工具賦能人們更高效地工作，而過程和流程是人們行為與目標(biāo)保持一致的載體。完美地做一件不該做的事毫無意義，甚至可能對整體造成損害。從全局考慮，好的流程是不可或缺的。

DevOps產(chǎn)品應(yīng)內(nèi)置于

進(jìn)一步解放生產(chǎn)力的新生產(chǎn)關(guān)系

數(shù)字化背景下，業(yè)務(wù)的快速發(fā)展帶來了軟件系統(tǒng)的高復(fù)雜度，個人需要處理的事情變多，導(dǎo)致單人效率下降。為了提高團(tuán)隊中各個角色的工作效率，企業(yè)追求DevOps轉(zhuǎn)型，希望利用新興技術(shù)和工具快速提升團(tuán)隊生產(chǎn)力。然而，隨著技術(shù)和工具投入的不斷增加，團(tuán)隊規(guī)模的不斷擴(kuò)大，也帶來了整體協(xié)作的復(fù)雜性。但是這些復(fù)雜的依賴關(guān)系像金字塔一樣傳導(dǎo)到團(tuán)隊成員身上，對原有的工作習(xí)慣甚至理解和認(rèn)知形成了巨大的沖擊。即使是一個簡單的交付，也需要很多操作和不同角色的配合，所以整個交付過程是脆弱而低效的:比如上下游工作的合同和規(guī)范缺失，R&D過程的透明度不夠，需要在不同的工具平臺之間來回切換等等。

不同的工具如何在一個完整的流程中有機(jī)共存？如何為團(tuán)隊打造一個高效的流程，讓人們順利完成高質(zhì)量的軟件開發(fā)并發(fā)布到生產(chǎn)環(huán)境中？在這個過程中，團(tuán)隊成員不需要處理不必要的復(fù)雜問題，不需要糾結(jié)于小細(xì)節(jié)，也不需要等待很長時間。我們應(yīng)該解放團(tuán)隊成員的生產(chǎn)力，讓開發(fā)人員可以專注于真正能產(chǎn)生商業(yè)價值的工作。這是目前值得思考的事情:正如生產(chǎn)力決定生產(chǎn)關(guān)系一樣，我們需要更先進(jìn)的研發(fā)管理產(chǎn)品來賦能R&D團(tuán)隊，以滿足當(dāng)今數(shù)字化業(yè)務(wù)發(fā)展的需求。

編碼指南針

處于DevOps流程階段的R&D流程管理產(chǎn)品

通過梳理DevOps實踐中的突出問題，我們得到了以下兩點認(rèn)識:

1。組織級別的開發(fā)運維轉(zhuǎn)型需要領(lǐng)域?qū)＜?/strong>

7月，信通院發(fā)布的《中國DevOps現(xiàn)狀調(diào)查報告(2021)》指出，由于缺乏DevOps專家，近三成企業(yè)推進(jìn)緩慢。而我們在服務(wù)客戶的時候，往往需要提供咨詢，通過專家診斷，制定出流程，然后根據(jù)實際情況設(shè)定要推進(jìn)的目標(biāo)和具體的實現(xiàn)路徑。DevOps產(chǎn)品需要做的是:提取行業(yè)內(nèi)有效的研發(fā)管理經(jīng)驗，嵌入到產(chǎn)品中，引導(dǎo)客戶團(tuán)隊固化并持續(xù)優(yōu)化優(yōu)秀習(xí)慣，從而實現(xiàn)高效的研發(fā)管理。

2。團(tuán)隊成員在協(xié)作中最大的痛點就是“無所不知”[S2/]

在現(xiàn)有提供的工具的基礎(chǔ)下，團(tuán)隊可以在對DevOps有簡單了解的情況下開始協(xié)同工作。然而，用戶面臨的協(xié)作問題確實存在:例如，缺乏跨職能活動的能力，缺乏活動之間的協(xié)作規(guī)范，難以識別R&D過程中的風(fēng)險，個人在工作中需要了解的上下文太多，以及許多只能手動處理的跨職能操作等。這些看似瑣碎，但如果這些問題日積月累，得不到解決，就會造成團(tuán)隊成員極大的“精神疲憊”，甚至導(dǎo)致優(yōu)秀員工對構(gòu)建高效組織產(chǎn)生懷疑。

DevOps深化發(fā)展到現(xiàn)在，代表了業(yè)界對研發(fā)管理產(chǎn)品的新期待:從敏捷到DevOps，結(jié)合LEAN的精益思想，正在向增強(qiáng)可視化和可追溯性，追求標(biāo)準(zhǔn)化和高效化的方向發(fā)展。基于這些感知到的痛點，CODING結(jié)合自身的實踐和行業(yè)成就的經(jīng)驗，努力提升產(chǎn)品，幫助客戶更好地提升研發(fā)管理能力。

Compass=工作流+規(guī)范+自動化

編碼創(chuàng)造了一個全新的R&D過程管理產(chǎn)品Compass，它包括三個主要能力:工作流(串聯(lián)各種活動形成的協(xié)同)、規(guī)范(提高R&D活動一致性的標(biāo)準(zhǔn))、自動化(活動后的觸發(fā))。意味著編碼DevOps是在原有DevOps工具鏈的基礎(chǔ)的基礎(chǔ)上，融入了Knowhow的部分，讓客戶充分借鑒行業(yè)內(nèi)有效的實踐經(jīng)驗，實現(xiàn)高效的研發(fā)管理。

Compass如何提升研發(fā)管理能力

簡單來說，Compass的產(chǎn)品邏輯就是定義流程，規(guī)范流程，高效循環(huán)，識別瓶頸，引導(dǎo)改進(jìn)。

1。首先，R&D進(jìn)程中有各種各樣的活動。

例如，產(chǎn)品經(jīng)理將在Backlog中創(chuàng)建需求，團(tuán)隊規(guī)劃將包含在迭代中，任務(wù)將被分解、聲明或分配。開發(fā)將創(chuàng)建分支，編寫代碼，提交和合并等。，而測試是設(shè)計用例，執(zhí)行測試，然后團(tuán)隊會測試，通過質(zhì)量控制，然后創(chuàng)建發(fā)布表單等。

我們知道，這里列出的一些發(fā)生在同一個角色內(nèi)部，而另一些則需要不同的角色來合作。事實上，它們是按順序進(jìn)行的。

2。其次，確定關(guān)鍵的協(xié)作活動，并將其串聯(lián)起來，形成一個完整的工作流程。

將這些活動按照不同的角色進(jìn)行分類后，我們會發(fā)現(xiàn)，同一角色的某些活動客觀上是其他活動的前提。比如需求創(chuàng)建后，可以包含在迭代中，分支存在后，可以有相應(yīng)的代碼提交和MR，用例設(shè)計后，可以在其基礎(chǔ)上關(guān)聯(lián)相應(yīng)的需求，等等。這些內(nèi)在的聯(lián)系導(dǎo)致了他們活動的自發(fā)完成。

對于剩下的關(guān)鍵節(jié)點，我們從整體R&D的角度出發(fā)，人為定義它們的依賴順序，并根據(jù)實際工作情況串聯(lián)起來。比如任務(wù)分解后，可以創(chuàng)建相應(yīng)的特征分支；在MR可用，并且需求與測試用例相關(guān)聯(lián)之后，就可以進(jìn)行測試，給出測試報告，最后提交發(fā)布單。這就形成了一個完整的工作流程。

3。第三，活動的健壯流程通過規(guī)范來保證，自動化驅(qū)動活動的高效流程。

為了保證活動流通的穩(wěn)健性，我們可以對一些活動設(shè)置準(zhǔn)入和退出規(guī)范，對不符合規(guī)范的給予警告，阻止其繼續(xù)流通。例如，包含在迭代中的需求應(yīng)該給出驗收標(biāo)準(zhǔn)，這應(yīng)該作為用例設(shè)計的基礎(chǔ)，測試報告中的通過率應(yīng)該滿足某個值，然后才能創(chuàng)建發(fā)布單。此外，對于一些可以以標(biāo)準(zhǔn)化方式創(chuàng)建或觸發(fā)的活動，可以設(shè)置自動化規(guī)則。當(dāng)前提條件滿足時，它將自動流動，不需要團(tuán)隊成員切換到另一個工具來更新狀態(tài)或手動創(chuàng)建下一個任務(wù)。這樣就形成了有序的團(tuán)隊協(xié)作工作流程。

4。最后，將R&D的具體步驟與定義的業(yè)務(wù)價值流階段對應(yīng)起來，以提供洞察分析。

而標(biāo)準(zhǔn)化和自動化可以產(chǎn)生準(zhǔn)確的活動記錄，從而為效率衡量提供真實可靠的數(shù)據(jù)，進(jìn)行有效的洞察診斷，指導(dǎo)改進(jìn)。比如提前期和加工時間的差異，任務(wù)完成率/準(zhǔn)確率等。這就是價值流管理的基礎(chǔ)。

以上是指南針的產(chǎn)品設(shè)計理念。我們希望流程中的每個人都能夠通過在整個流程中協(xié)作驅(qū)動開發(fā)行為來關(guān)注自己的價值。同時，沉淀的過程數(shù)據(jù)可以準(zhǔn)確看到R&D過程，并基于對數(shù)據(jù)的洞察分析，指導(dǎo)R&D過程的持續(xù)改進(jìn)。

摘要[/s2/]

編碼羅盤是R&D流程管理基于編碼羅盤原有DevOps工具鏈的產(chǎn)品，包括流程安排、流程驅(qū)動、規(guī)則約束、價值流轉(zhuǎn)。希望能幫助企業(yè)以最低的協(xié)同成本實現(xiàn)最高的響應(yīng)能力，從而最大化R&D效率。