深度解讀7個場景，破解研發效能障礙

語言: CN / TW / HK

時間 2022-10-01 20:01:14 LigaAI

伴隨著數字化與資訊化的發展，研發效能和降本增效日漸成為企業管理焦點。尤其對於研發型團隊而言，快速地、保質保量地交付價值是優先順序最高的任務，但在實際的開發過程中，我們總會遇到技術債務、並行衝突等影響研發效能的情況。

在告別野蠻生長，主張精耕細作的今天，企業/組織應該如何解讀種種效能障礙，制定可複製的解決方案？本篇文章將從7 個常見的研發場景出發，分享有關研發效能提升的心得與經驗。

場景一：並行開發導致程式碼衝突

組內/組間並行，或由程式碼回退/合併等造成的各種並行開發導致程式碼衝突是常見的效能問題之一。並行化的分支管理和版本管理是比較重要的議題，而合併策略、Feature分支管理、變更管理都可能影響研發效能。

解決這個問題，可以考慮以下三種優化方式：

以時間為軸，串起整個版本主線，程式碼對版本負責，版本對功能負責。

對同一系統而言，程式碼是並行開發的，但最終的交付物/釋出物是順序釋出的；對不同系統而言，主要考慮相互間的依賴關係，影響面以及釋出順序。

按照敏捷迭代方式將大功能化整為零，更好地應對變化。 如遇到迭代週期內需求必須變更的情況，需要確定好變更的影響範圍和需求優先順序。

技術/優化需求和跟版迭代需求可能需要採用不同的釋出策略和分支管理。 這樣既可以保證業務目標按期、有效地達成，還能保障各種優化和支撐工作靈活地進行和並行。

技術債是一個老生常談的話題。企業在平常的研發管理中，應重視「好習慣」的培養，若等到技術債堆積成山，系統病入膏肓才著手解決，恐怕就為時已晚了。

建議在日常的研發管理中，加強程式碼稽核機制，實行程式碼的P3C規範化檢查；前期對業務的技術方案也應作出合理取捨。

另外，架構設計應結合實際業務和資源進行充分考慮，謹防過度設計。 好的架構是演化而來的，沒有一勞永逸的完美架構。

並行協同時，配置和資原始檔的不同步也是造成衝突和問題的重要因素。為避免額外的排除工作影響研發效能，企業可以考慮提升配置和資源的獨立性以及簡化性。

第一，儘量按時間順序管理需求配置的唯一值；如果不能保證唯一配置，則推薦按分組邏輯管理各組的修改值（不冗餘其他組的原有配置）。

比如，按時間序列管理或分組並列管理，待確定提測節點後再進行合併。這樣可以較清晰地發現衝突項，防止互相覆蓋。

此外，除公共配置外，考慮按功能進行分組配置，不要將全部內容寫在一個配置檔案裡。

第二，配置合併時，簽入簽出流程要儘可能短。 配置的合併過程需要稽核，但配置調整的流程時間視窗不易過長，以免造成額外的等待成本，誘發潛在的衝突。

許多時候，生產環境的資料必須脫敏，但同時，研發團隊又需要驗證生產問題或縮小問題的影響面。這種情況應該如何解讀和解決？

生產環境的客戶資料脫敏後，記錄部分非敏感的ID引數、異常等日誌仍可以作為有效資料，完成特定場景下的分析訴求。

準備一個與生產環境相對一致的「克隆體」——Pre準生產環境，同步並通過非客戶資料完成生產環境的驗證。

非客戶資料包括部分生產測試的資料、經客戶允許的可蒐集的部分資料，以及經過合規完全脫敏後的資料等等。

通過少量客戶滲透，或對部分特定租戶進行生產環境的短時滲透執行， 穩定後再投入大規模部署。

研發過程中，開發環境和部署環境的複雜度也會影響研發效能。因此，建議儘可能地降低自測、聯調、環境部署的複雜度，以及同一個服務的程式碼量和複雜度。

舉個例子，有些系統僅是啟動就要耗時 30 分鐘，那麼每位開發者每天花在應對環境、應對啟動的時間成本也顯著增加了。

不可否認地，沒有一款產品、一項服務能永遠不出問題。因此，搭建有效、可快速反應的業務監控和運維監控體系非常重要。

不管選用哪種監控平臺系統，核心目的都是監控核心目標，並實現關鍵指標的及時預警和通知。有效、直接、快速地反應和處理髮現的問題，比豐富的監控方案更為重要。

其次，重視測試環節。 考慮補充多種測試手段，儘可能地發現問題，比如針對介面的自動化測試、針對場景的整合測試、對大型系統的壓測環境等等。

在研發流程管理過程中，非技術因素也會對研發效能產生重要的影響。

研發流程管理是研發效能提升領域中重要的議題。管理者可以以鳥瞰檢視，分析和判斷研發全生命週期的運轉情況，並藉助智慧化的監控和預警工具，發現問題、解決問題、避免問題，做出更可靠的管理干預和引導。

瞭解更多敏捷開發、專案管理、行業動態等訊息，關注我們 LigaAI@oschina 或點選LigaAI - 新一代智慧研發協作平臺，線上申請體驗我們的產品。

「其他文章」