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

編碼指南針——構建流動的軟件工廠

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

DevOps已從工具階段進入流程階段

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

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

如果說之前DevOps處于工具化階段，各種工具層出不窮，那么在數字化業務快速發展的大背景下，DevOps正在進入一個新的階段:流程化階段。

企業使用DevOps工具仍然面臨挑戰

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

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

1.對于一個產品來說，它所關注的需求活動并不能很好的關聯到開發實際在做什么，所以它不能完全控制進度和風險。

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

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

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

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

企業越來越重視研發管理的整體效率

這個案例并不是個例，而是DevOps轉型到了一個新的流程階段的標志:企業越來越重視研發管理的整體效率，從強調某個工具的局部優化，到強調協同流程的全局優化。

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

DevOps產品應內置于

進一步解放生產力的新生產關系

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

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

編碼指南針

處于DevOps流程階段的R&D流程管理產品

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

1。組織級別的開發運維轉型需要領域專家

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

2。團隊成員在協作中最大的痛點就是“無所不知”[S2/]

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

DevOps深化發展到現在，代表了業界對研發管理產品的新期待:從敏捷到DevOps，結合LEAN的精益思想，正在向增強可視化和可追溯性，追求標準化和高效化的方向發展。基于這些感知到的痛點，CODING結合自身的實踐和行業成就的經驗，努力提升產品，幫助客戶更好地提升研發管理能力。

Compass=工作流+規范+自動化

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

Compass如何提升研發管理能力

簡單來說，Compass的產品邏輯就是定義流程，規范流程，高效循環，識別瓶頸，引導改進。

1。首先，R&D進程中有各種各樣的活動。

例如，產品經理將在Backlog中創建需求，團隊規劃將包含在迭代中，任務將被分解、聲明或分配。開發將創建分支，編寫代碼，提交和合并等。，而測試是設計用例，執行測試，然后團隊會測試，通過質量控制，然后創建發布表單等。

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

2。其次，確定關鍵的協作活動，并將其串聯起來，形成一個完整的工作流程。

將這些活動按照不同的角色進行分類后，我們會發現，同一角色的某些活動客觀上是其他活動的前提。比如需求創建后，可以包含在迭代中，分支存在后，可以有相應的代碼提交和MR，用例設計后，可以在其基礎上關聯相應的需求，等等。這些內在的聯系導致了他們活動的自發完成。

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

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

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

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

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

以上是指南針的產品設計理念。我們希望流程中的每個人都能夠通過在整個流程中協作驅動開發行為來關注自己的價值。同時，沉淀的過程數據可以準確看到R&D過程，并基于對數據的洞察分析，指導R&D過程的持續改進。

摘要[/s2/]

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

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。