[[396990]]

企業軟件開發是一項復雜的工作，只有能夠通過快速交付高質量軟件來應對市場變化的公司才能在數字時代占據主導地位。

沒有達到所需的業務敏捷性水平的靈丹妙藥。它需要從傳統的瀑布式思維方式和舊的思維方式到具有相關原則和實踐的精益敏捷思維方式的轉變。

擴展框架和DevOps方法可以為您轉變IT組織以及其余業務提供所需的指導。規模化敏捷框架(SAFe)是最受歡迎的規?；椒?，闡明了在數字時代成功所需的七個核心能力：組織敏捷性，精益投資組合管理，企業解決方案交付，敏捷產品交付，團隊和技術敏捷性，持續性學習文化，并精益敏捷的領導能力。不過，仍然不能保證成功，因為需要認真執行，最好在SAFe計劃顧問的幫助下才能實現。

領導參與度，一致性和系統思考是我最喜歡的成功轉型要素。除了上述常見的成功因素外，框架還在不斷發展。從業人員不斷地將實地的學習和經驗反饋回框架中。這里有兩個有用的模型，以及有關如何將它們與Software Factory方法結合使用的建議，以改進您的DevOps實施并增強業務敏捷性。

DevOps演化模型正如彼得·森格(Peter Senge)在他的*《第五紀律》中*所描述的那樣，團隊和組織需要一種共享的思維模型來產生對問題的共識，并合作找到一個好的解決方案。為此，我創建了所謂的DevOps演化模型。該模型是在我的培訓課程中開發的，目的是解釋人們如何在DevOps旅程中取得最佳進展。

該模型可以幫助您了解如何通過將未完成的工作向左移動來縮短交貨時間并縮短反饋周期的長度。(未完成工作是在團隊“完成”功能和故事之后發布解決方案所需的額外工作。未完成工作的典型示例是任何類型的測試，安全檢查和審計，文檔，開源法律評估和合規性檢查。)

左移未完成的工作可使您的團隊提供更快的反饋，從而提供更多可用的產品和更快的缺陷修復程序。反過來，這會加快流程并提高質量。減少或消除未完成的工作會導致發布更加頻繁，并提高了對需求變更的響應速度。

圖1：DevOps演化模型涵蓋了DevOps旅程的四個主要階段，并直觀地展示了您的組織如何從不成熟的模型發展為更成熟的模型

CI/CD管道模型持續集成/持續交付模型是從我進行的SAFe DevOps培訓和后續研討會中發展而來的。在流程級別對端到端管道進行建模。CI/CD管道建模深入研究了詳細的CI/CD管道以及相關的構建和集成過程。以我的經驗，復雜的企業設置中的許多流程問題是未成熟的CI/CD管道的直接結果。

要創建模型，您需要將所有利益相關者聚集在一起，以將整個管道流程(構建，集成，部署等)繪制為節點和邊緣。節點表示組件，邊緣表示組件之間的關系。雖然您可能認為您的團隊已經知道他們的端到端管道，并且會發現這整個工作都沒有用，但根據我的經驗，從來沒有這樣。

CI/CD管道模型使您可以看到全局。在大型解決方案中，沒有人能理解端到端CI/CD流程。通過召集合適的人員，您可以看到局部優化的次優結果，并專注于高效的端到端改進。

例如，團隊經常聲稱他們每天要構建和部署幾次，而實際上他們是在一遍又一遍地構建和部署相同的代碼或組件。

CI/CD改進的關鍵問題不是管道運行的數量，而是團隊從編寫代碼到到達階段或生產所需的時間。這是您應為每個貢獻要素提出的最重要問題。

由于縮短了交貨時間，因此CI/CD建?？梢蕴岣哔|量。有缺陷的組件可能會對集成最終產品產生多米諾骨牌效應，因為依賴有缺陷組件的組件的開發會延遲。更糟糕的是，如果您的團隊在開發過程的后期發現缺陷，則無法滿足已落實的計劃，或者您可能需要創建快捷方式或變通方法以保持計劃。這降低了質量并增加了技術債務。

圖2：這是具有超過1億行代碼的大型企業產品的CI/CD管道建模示例(單擊放大)。每個橙色粘性標簽代表一個大組件(節點)，而藍色箭頭是描述構建，集成和部署步驟的邊緣。粉色便簽顯示了周期時間，提前期和完整且準確的百分比(%C&A)。綠色粘滯便是分階段部署的最終產品。注意，“ LST”代表“大型解決方案系列”，“ ART”代表“敏捷發布系列”。

軟件工廠方法的企業優勢大型企業通常被視為沒有DevOps的恐龍。從一開始，它們就失去了市場份額，而新興市場的小型公司卻在其DNA中擁有敏捷性和DevOps。但是，雖然確實可以使大型企業向前發展充滿挑戰，但是在SAFe的幫助下，您可以成功進行轉型。您將能夠以最小的努力來創建或更改開發價值流，因為人們已經具有相同的語言和思維定勢，并且他們將能夠快速調整策略以應對機遇或威脅。

軟件工廠通過使團隊能夠更快地調整開發設置以適應不斷變化的業務需求并縮短升級和啟動時間，從而補充了此功能。此外，它有助于減輕團隊的認知負擔，并提高效率，促進左移并縮短交貨時間。

構建企業軟件通常需要的復雜工具鏈通常會導致使用它們的團隊出現認知負擔。考慮所需的管道改進和維護活動，例如跟上最新工具和技術的發展，以及升級構建服務器，操作系統，插件，測試自動化工具等。這就增加了認知負載釋放截止日期的壓力，以及與產品和領域專業知識以及新功能和錯誤修復保持一致的需求，這也就不足為奇了，許多CI/CD管道不穩定且不可靠。

“管道即服務”可以解決這些問題并提高生產率。專門的專家維護并不斷改善多個產品團隊可以使用的服務，從而減輕了開發團隊的負擔，使他們可以專注于在短時間內開發高質量產品的核心職責。

為了更快地響應開發組織中的變更，您需要對開發工具進行標準化。這樣可以更好地集成工具，并使開發團隊更輕松地開發其他產品，因為他們將熟悉其他產品組正在使用的所有工具和核心流程。一組標準化的工具為現代軟件開發方法(例如共享代碼所有權和內部開源)奠定了基礎。

使用Software Factory方法對工具進行標準化可以極大地減少許可和維護成本，同時還可以減少工具之間所需的集成和同步的次數。

如果您擁有大量的工具，則可能有很多不可靠的，半功能的集成以及昂貴的維護工作。這意味著不必要的高昂總擁有成本，繁忙的工作人員以及不可靠的開發數據流。

但是標準化需要謹慎的平衡。我的建議是盡可能地標準化，同時提供盡可能多的自由。并非所有工具和過程都是標準化的候選對象。軟件工廠通常從小規模開始，然后根據采用和用戶反饋逐步發展。圖3顯示了一個經過驗證的帶有核心元素的Software Factory架構。

圖3：這是Micro Focus的Software Factory架構/藍圖，它顯示了功能完善的軟件工廠的主要組件和類別(單擊放大)。

如何開始掌握企業軟件和網絡物理系統是一項復雜的工作，沒有簡單的解決方案或靈丹妙藥。Scaled Agile Framework和其他一些框架可以為您的數字化轉型之旅提供指導和堅實的基礎。

先進的DevOps模型與Software Factory方法相結合，可以增強和補充這些產品，從而使您的組織可以在數字時代蓬勃發展。