作者：張裕、雅純
理想中的研發團隊應當具有以下特徵：
-
總是工作在最高優先級的事項上
理想的研發團隊能夠識別並始終集中精力在當前最緊迫和最有價值的任務上。這需要團隊具備出色的項目管理能力和決策能力，以便能夠正確評估優先級，做出合理的工作分配，並快速適應項目需求的變化。
-
各個角色既能專注於自身的專業工作，又能彼此高效協同
每個團隊成員都應當是各自領域的專家，並且全身心投入到他們擅長和負責的工作當中。然而，這並不意味着他們僅限於個體工作。一個理想的研發團隊鼓勵跨學科合作，通過敏捷的溝通機制和共享的工具，確保信息能夠順暢地在團隊成員之間流通。團隊中的設計師、工程師、產品經理和其他角色之間應當存在協同工作的文化，這樣的多元化合作能夠促進創新思維，並最終導致更高質量的產品開發。
-
團隊和個體的技術和工程能力能持續改進
理想研發團隊不僅在現有技術上精通，而且持續追求技術和專業技能的提升。這意味着個人和團隊都應該鼓勵創新和實驗，並且能做到快速試錯、快速反饋。同時，團隊應該有制度鼓勵個人在工作中嘗試新方法和技術，這種文化不僅有助於團隊的長期成長，也有助於吸引和保留那些富有好奇心和熱情於學習新事物的人才。
一個擁有如上特質的研發團隊更有可能成功地完成複雜的項目，創造創新的產品，並在競爭激烈的市場環境中獲得成功。
團隊工程交付的常見問題
要成爲上面所述的優秀研發團隊確實需要付出巨大的努力和持續的改進。在追求理想狀態的過程中，以下三個問題經常成爲阻礙團隊達到理想特質的障礙：
1）信息傳遞失真： 團隊內部成員來自不同的專業背景，使用的術語和概念也各不相同。例如，開發說發佈一個應用，運維說對一個服務做變更，但他倆說的其實是同一件事情。在日常協作中，需要將這些信息從一個領域轉換到另一個領域，並確保信息不丟失、不扭曲。如果處理不當，就會導致團隊成員對項目的理解出現偏差，從而影響決策和執行。爲了解決這個問題，可以通過建立統一的概念模型、使用共享的術語庫、提供跨部門交流培訓和使用相同的工具平臺等方式來減少信息傳遞過程中的失真。
2）流程沒有連接： 儘管每個研發階段內部可能已經實現了自動化和高效的運作，但是當一個項目或需求從一個階段轉移到另一個階段時，往往缺乏流暢的銜接。舉個例子，有的企業開發人員和測試人員屬於不同的職能團隊，開發人員提交代碼後，自動會觸發代碼的構建、靜態檢查、單元測試等環節，但到了功能測試階段，開發人員需要手動填寫提測單，在提測單裏寫上代碼版本、單測結果、靜態檢查結果、部署方式等，由測試人員線下確認後，再流轉到功能測試階段。這種階段間的斷層通常需要依賴於團隊成員之間的線下溝通和非正式協議，這容易造成流程上的混亂和效率低下。要打破這些障礙，團隊可以嘗試引入端到端的研發管理工具和流程，確保流程的透明化和自動化，從而形成一個無縫連接的、整體的研發流程。
3）無法識別重點： 當團隊同時處理多個項目和需求時，工程活動可能會分散在不同的工具和平臺上。這種分散導致團隊成員很難追蹤整體的進展，也難以判斷哪些任務是當前的重點。信息的碎片化使得團隊難以集中注意力在最緊迫的需求上。解決這個問題的關鍵在於建立統一的研發管理系統，按研發任務聚合工程活動，實時展示各個任務的狀態和優先級。此外，定期的回顧會議和優先事項的重新評估也是確保團隊能夠集中精力在最有價值的工作上的重要做法。
總結來說，成爲一個優秀的研發團隊不僅需要專業技能的不斷提升，而且還需要針對信息流通、流程銜接和重點識別等方面的問題進行系統的解決方案設計和實施。通過持續的努力，優秀的團隊可以逐步克服這些攔路虎，走向成熟和效能的最高標準。
因此，改進的第一步是要能看見工程活動和研發模式，進而識別其中存在的問題。
統一工程交付的概念模型
爲了有效解決信息傳遞失真、流程不連貫等問題，確保信息的流暢傳遞和流程的無縫連接是至關重要的。這就要求從根本上統一工程交付的概念模型，使所有參與者——無論是開發人員、測試人員、產品經理還是任何其他相關方——都擁有共同的理解框架。
在解決這些問題的過程中，雲效聯合產學研各界於 2022 年發佈了 BizDevOps白皮書， 該白皮書提出了 BizDevOps 完整的概念模型，通過該模型，可以更清晰地界定和管理研發生命週期中的各個環節。
具體到模型本身，它將業務需求、產品需求、變更請求定義爲時標對象，這些時標對象在時間軸上代表了需求的生成和變更的發生。每一個變更請求都與特定的應用相關聯，而應用就是變更請求所屬的空間或上下文。這樣，工程交付的核心概念就被簡化爲兩個主要元素：應用和變更請求。此外，還包括了應用的一些重要附屬屬性，例如變更內容、環境、部署編排和研發變更流程等。這些屬性共同描述了從需求提出到最終部署的完整過程。
通過應用這個核心概念，工程側能夠高效地聚合研發資產和研發流程，形成一個集中的管理點。這有助於優化資源分配，提高研發效率，同時也有助於跟蹤和度量研發過程中的關鍵指標。
另一方面，變更請求作爲時標對象，承擔了連接不同研發活動和項目協作的關鍵角色。通過對變更請求的跟蹤和管理，團隊可以確保所有的活動都圍繞着實現具體的業務目標進行，同時使得整個工程交付過程更加透明和可控。
綜上所述，這個模型不僅爲團隊成員之間的溝通提供了共同的語言，還爲整個研發週期的管理提供了一套清晰的指南，從而使得各個環節能夠緊密協作，確保研發活動能夠高效、有序地進行。
定義應用交付的模式
擁有了統一的概念模型後，我們得以實現對研發資產和流程的系統化規範和高效管理。具體來看：
1）基於應用將研發資產和研發流程有效地規範和管理起來： 我們爲此構建了一套標準化模板，旨在幫助團隊對應用的研發資產和流程進行全面梳理。這個模板涵蓋的內容包括但不限於：
a. 應用相關角色及其權限： 定義每個涉及應用開發的角色（如開發人員、測試工程師、產品經理等）以及它們相對於應用的權限，確保權限的分配既滿足安全要求又促進工作效率。
b. 應用的代碼和製品： 明確代碼庫管理和製品庫的使用，以及不同角色在代碼提交、審覈、製品生成和存儲過程中的職責和權限。
c. 應用的分支模式： 規定了源代碼管理中各種分支的使用場景和規範，以及不同分支對應角色的職責，確保代碼的版本管理既清晰又高效。
d. 應用端到端的研發流程： 詳細描述了從開發任務的啓動到產品的最終上線，涉及的所有階段和流水線，包括每個階段的具體任務、責任分配、准入和準出標準，以及階段間的銜接方法。
e. 應用的環境及其與角色的對應關係： 梳理各種環境（如開發環境、測試環境、生產環境）的配置和用途，以及各個環境中不同角色的責任和權限。
2）基於變更請求將產品需求和開發任務端到端地連接起來： 與上面的靜態資產和流程管理相比較，這裏更側重於需求到上線這一動態的研發流程。
a. 創建變更請求： 這一流程的第一步通常是將產品需求轉化爲技術任務，即變更請求，這些變更請求直接屬於相應的應用。
b. 指定變更範圍： 變更請求的創建過程中，會指定其變更範圍，通常指定爲某個代碼庫的特性分支。開發人員在此分支上進行代碼提交，觸發應用的研發流程。
c. 執行研發流程： 隨着研發流程的展開，變更請求會逐漸通過各個階段，特性分支也可能會被合併到集成分支或發佈分支。每個階段的執行頻率可能不同，一般情況下，越接近流程的末端，執行的次數就越少。
d. 完成變更： 當變更請求成功通過最後一個階段，它就被視爲完成。同理，一個產品需求所對應的所有變更請求一旦全部完成，那麼這個產品需求也就可以宣佈完成或者發佈上線。
基於雲效平臺的落地方法
我們強烈建議在落地工程交付實踐之前，先把需求協作實踐梳理清楚，關於這一塊內容，推薦參考：如何制定科學有效的需求流程規範。
接下來，我們會藉助雲效平臺，按照前面章節的示例，定義應用的交付模式，並按照該交付模式完成一個產品需求交付的完整流程。
4.1 通過應用模板定義應用交付模式
我們通過應用模板來承載團隊的工程交付模式，這裏我們以前面提到過的基於 feature 的持續交付模式爲例。
該交付模式的特點是開發、測試均基於特性分支，集成發佈均基於主幹分支，屬於快速開始，快速集成，快速交付，推崇單個特性的獨立開發、獨立測試、獨立集成於獨立交付。
首先，在雲效 appstack 上創建一個名爲“特性驅動的持續交付模板”的應用模板。
在該模板上開啓“變更 + 研發流程”服務。
按照 feature/master 兩階段的研發流程，爲這兩個階段分別定義變量組，在變量組中使用不同的 k8s namespace，以及指定不同的副本數。
接下來通過模板來規範應用的部署方式，雲效推崇多套環境一套編排模板的實踐，差異性的部分通過變量組來定義。
然後，我們規定每個應用都有兩套環境，分別爲用於 feature 開發驗證的“特性驗證環境”，和用於集成發佈的“生產部署環境”。這兩套環境與對應的變量組、部署編排和集羣資源（可選）關聯。
我們已經確定了應用的環境和部署策略，接下來我們規範應用的研發交付流程。
我們要求應用從開始開發到完成交付，需要經過特性驗證和生產部署兩個階段的驗證，且只有經過特性驗證階段的 feature，才能進行生產部署。爲了做到這一點，我們創建了一個兩階段的研發流程，分別爲特性驗證階段和生產部署階段。
在特性驗證階段，我們定義了一條包含 4 個步驟的流水線，分別爲代碼檢視、構建、部署和測試，且規定分支爲自由選擇方式（可在流水線配置名稱前綴爲 feature- 的分支有新的代碼提交自動觸發）。
在生產部署階段，我們配置了一條有 5 個步驟的流水線，分別爲代碼檢視、構建、審覈、部署和完成變更。同時限制流水線運行分支爲 master，且執行時相關 feature 在特性驗證階段的執行結果爲成功（雲效會自動計算流水線執行時所涉及到的 feature 分支，並判斷其前序階段的執行成功與否）。
至此，我們完成了應用模板的定義，現在，讓我們基於該模板來創建一個應用，並完成一個特性的交付。
通過應用模板創建好應用後，還需要設置好應用所關聯的代碼倉庫和相關成員。
4.2 分析產品需求，拆解變更請求
假設我們接到一個產品需求，需要將查詢服務接入風控，避免爬蟲攻擊。爲此，我們爲 risk-control-srv 拆解了一個變更請求，並關聯到該產品需求上。
4.3 在變更分支上提交代碼，進行持續驗證
由於設置了代碼提交至 feature 分支自動觸發特性驗證階段的執行，每次在 feature 上 push 代碼後，都會自動進行驗證並給出反饋。
4.4 通過代碼評審合併變更分支，進入生產部署
當代碼評審通過併合併入 master 分支後，會自動觸發生產部署階段的執行。
4.5 完成變更，進而完成產品需求
生產部署階段執行完成後，變更請求會變爲已完成狀態，同時其對應的產品需求也會自動進入已完成狀態。
後記
本文從統一工程交付的概念模型開始，介紹瞭如何將應用交付的模式顯式地定義出來，並通過工具平臺落地。但需注意，團隊的工程交付實踐往往不存在標準解，我們都是在尋求當前場景下的最優解。在具體的場景下，團隊的工程交付受到協作機制和技術水平的雙重製約，因此需要我們把視角從工程交付本身跳出來，結合協作、技術一起來看，並持續優化和改進，才能找到適合我們自身團隊的最佳實踐模式。