Isaac Sacolick 沈建苗

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

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

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

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

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

為敏捷方法正名

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

但這無法刻板僵硬地部署推行。不同的組織自有不同的業(yè)務戰(zhàn)略、組織結構、組織文化、人才、合規(guī)要求以及新舊架構的組合?？紤]何時何地運用不同的敏捷實踐時，這些因素異常重要。

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

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

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

通過數(shù)據(jù)運營和數(shù)據(jù)治理加快機器學習

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

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

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

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

· 數(shù)據(jù)科學團隊記載機器學習模型、定義漂移參數(shù)，并基于定義的生命周期維護生產(chǎn)級模型。

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

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

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

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

完善開發(fā)運營實踐時運用客戶理念

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

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

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

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

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

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

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

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

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

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

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

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

本文作者Isaac Sacolick著有亞馬遜暢銷書《駕馭數(shù)字化：通過技術進行業(yè)務轉型的領導人指南》一書，該書介紹了許多實踐，比如對成功的數(shù)字化轉型計劃至關重要的敏捷規(guī)劃、開發(fā)運營和數(shù)據(jù)科學。Sacolick是公認的頂尖社交CIO，在數(shù)字化轉型領域頗具影響力，還是CIO.com和博客 Social， Agile， and Transformation的特約編輯。

原文網(wǎng)址

https：//www.infoworld.com/article/3570436/how-to-mandate-agility-in-software-development-operations-and-data-science.html