劇透一下！坦誠的回答是，你無法強行要求敏捷性，但是可以專注于效益，通過達成共識來實現敏捷性。

就算企業領導人提倡企業組織需要更敏捷更靈活，他們也無法強行要求敏捷性。你的CIO和IT領導人可以對他們稱為敏捷方法標準的一套實踐、指標和職責實行標準化，但是無法強行要求每個人都采用敏捷文化和理念。

你可以選擇敏捷工具，利用開發運營（DevOps）實踐加大自動化力度，并支持平民數據科學計劃，但是你無法強行采用并強要員工開心。IT運營部門可能在運行混合多云架構，但這并不一定意味著成本得到了優化，或者基礎架構就可以神奇地自動擴大或縮減規模。

因此，如果你希望敏捷流程迅速實行標準化，通過改用敏捷架構神奇地解決技術債務，或者立即轉變成敏捷工作方式，那么你會大失所望。敏捷性不是免費、廉價或輕松就能得到的。你無法在時間表固定的甘特圖上管理敏捷性。

雖然我認為敏捷性主要是一種自下而上的轉變，但這并不意味著開發人員、工程師、測試人員、敏捷專家及IT團隊的其他成員可以獨立地提升敏捷性。整個團隊必須協同工作，承認要兼顧的取舍，并在效益方面達成共識的情況下制定敏捷運營原則。

因此，如果敏捷性不能強行要求，又需要所有人付出努力，那么組織如何變得更敏捷？以下是IT部門的所有人可以協同提升敏捷性的幾個方法，恪守敏捷方法、數據驅動型實踐和采用開發運營文化的宗旨。

為敏捷方法正名

本人所著《駕馭數字化》的第2章主要闡述了基礎的敏捷實踐以及更全面的敏捷規劃流程，這種流程包括分配角色和職責，規劃多迭代開發周期（sprint）待辦事項，以及預估方法實行標準化。我與試圖采用敏捷理念和文化的團隊合作時，我們會確立版本發布管理準則、架構標準、敏捷原則以及提升敏捷性的其他準則。

但這無法刻板僵硬地部署推行。不同的組織自有不同的業務戰略、組織結構、組織文化、人才、合規要求以及新舊架構的組合。考慮何時何地運用不同的敏捷實踐時，這些因素異常重要。

比如說，一家大型組織可能有團隊為領導人希望快速開發并發布給員工的移動應用程序開發API。第二個團隊可能在竭力改造一套復雜的遺留系統，該系統關系到一家受嚴格監管和審查的跨國公司能否正常運營。

這兩個團隊是否應該遵循相同、規范且嚴格控制的敏捷實踐？這肯定會制約API團隊；如果采用的敏捷方式更民主、自我組織，許多決定交由API團隊處理，那么毫無疑問API團隊會更愿意（而且可能表現出色）。另一方面，若為處理復雜的關鍵業務遺留系統的團隊賦予太大的自由度，那會帶來更大的風險。

目標和約束方面的差異是力求敏捷性的組織必須培養這種文化的原因之一：定義敏捷性原則時，要提出“為什么”并給出答案。如果領導人只規定方式，卻不解釋原因，員工就不太可能采用基本實踐。解釋敏捷原則（尤其是解釋原因）可以幫助團隊在何時、何地以及如何運用敏捷實踐方面做出更合理的決定。

通過數據運營和數據治理加快機器學習

我喜歡蜘蛛俠的這句名言：“能力越大，責任越大。”每家組織都希望自己的數據科學家、數據可視化專家和平民數據分析員能不斷獲取洞察力，進而幫助決策。但是這種能力還要求數據團隊、分析團隊和機器學習團隊采用積極主動的數據治理和數據運營（DataOps）實踐，以滿足組織在數據質量、安全、隱私、主數據管理和數據集成等方面的要求。

因此，分析團隊竭力變得更加敏捷，經常拿出成果，并增加分析中使用的數據集的數量，同時數據團隊必須基于合規要求和不斷變化的業務預期目標，夯實底層的數據處理基礎。

這種敏捷性不是免費或通過強行規定就能獲得的。只有跨部門團隊認識到敏捷性的重要性，并協同工作以改善分析交付和數據處理基礎，數據和分析流程才會日趨完善。這里有幾個例子：

平民數據科學計劃要求各參與部門在發布新的數據可視化之前，定義并維護數據目錄和定義。

數據科學團隊記載機器學習模型、定義漂移參數，并基于定義的生命周期維護生產級模型。

數據集成團隊和數據質量團隊將分析團隊視為客戶或利益相關者。他們定期審查分析團隊執行的數據管理工作，評估和調整數據模型和集成機制，以減少下游數據處理。

所有獲準處理數據的團隊定期審查數據安全、合規和隱私要求方面的變化。他們列出安全、數據或技術債務等方面的不足，為補救工作確定輕重緩急。

數據運營團隊和云運營團隊主動提升監測、容量規劃和基礎架構自動化的級別，以滿足數據處理和分析團隊越來越高的性能要求。

敏捷性是通過協作，并兼顧想要完成的工作與需要完成的工作來獲得的。否則，這新一代的大數據、機器學習和自助式商業智能（BI）計劃很容易帶來一大堆新的數據債務、數據孤島和數據安全風險。

完善開發運營實踐時運用客戶理念

采用開發運營文化和實踐的組織在努力解決一個橫亙幾十年的IT悖論：如何授權敏捷團隊對生產環境進行小幅、頻繁、低風險的更改，以滿足用戶并改善業務，又不影響可靠性、安全性、性能以及其他運營服務級別？

開發運營實踐和工具彌補了IT變更管理流程方面的不足，這些不足會導致重大事件、需要根本原因分析的復雜問題、導致部署延遲的糟糕基礎架構依賴項以及長期性安全問題。開發運營成功的幾個例子如下：

使用私有云和公有云的組織借助安全的基礎架構即代碼，使環境的部署和拆除實現自動化。

敏捷開發團隊借助左移的持續集成/持續交付（CI/ CD）管道，使測試實現自動化，并簡化構建和部署工作。更高級的團隊在管道中加入了安全驗證，并積極采用開發安全運營（devsecops）。

IT運營團隊加大監測和部署人工智能運營（AIOps）平臺的力度，以改善可見性和事件響應，從而改進管理復雜的無服務器部署、微服務架構和混合多云網絡這一能力。

這些都是解決IT敏捷和運營悖論的戰略性要素，但是如果沒有一項戰略就盲目開展這些計劃，可能導致沒有業務價值的IT結果。更為糟糕的是，它有時可能導致IT部門在自動化方面過度投入，影響了完成業務優先事項。

比如說，假設你在更新改造一款遺留的三層應用軟件，同時將其轉移至公有云，你就要決定實施哪種級別的自動化。應該如何定義什么足夠好？又該如何為開發運營方面的改進定義成功標準？

有一些問題和參數有助于回答這個問題。一些人可能稱之為服務等級需求，另一些人可能稱之為非功能性需求。在一些情況下，高度參與的利益相關者會需要每天發布和99.999%的可靠性。而在另一些情況下，讓利益相關者積極定義需求會比較困難。

任何一種情況都帶來了挑戰，但是敏捷性所需的共同點是首先定義客戶、客戶角色和成功標準。如果利益相關者的規范性過強，將他們列出的需求與業務層面上很合理的需求區分開來很重要。如果他們的需求沒有明確定義，將成功標準記入文檔特別重要。

許多組織定義產品管理或業務關系管理方面的職責，以記錄和共享目標角色、成功標準和業務需求。將這種客戶理念引入到開發運營團隊和實踐是一條最佳實踐，將幫助組織確定要投入于哪些方面的自動化、進行多大的投入。

總之，無法強行要求敏捷性。只有加強領導人和參與者的協作，才能獲得敏捷性。敏捷團隊必須按照自我組織的原則和標準來運營。他們必須兼顧業務需要的改進與解決數據、運營和技術債務所需的工作。設置優先級、定義成功標準以及確定什么是最小可行產品，需要定義客戶角色，并了解客戶的需求和價值。

當組織采用這些類型的實踐時，就不必強行要求敏捷性。敏捷性成為了共同的價值觀和完成工作的標準方法。