軟件開發(fā)運(yùn)營、數(shù)據(jù)科學(xué)如何才能敏捷？

Isaac Sacolick 沈建苗

就算企業(yè)領(lǐng)導(dǎo)人提倡企業(yè)組織需要更敏捷更靈活，他們也無法強(qiáng)行要求敏捷性。你的CIO和IT領(lǐng)導(dǎo)人可以對他們稱為敏捷方法標(biāo)準(zhǔn)的一套實(shí)踐、指標(biāo)和職責(zé)實(shí)行標(biāo)準(zhǔn)化，但是無法強(qiáng)行要求每個人都采用敏捷文化和理念。

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

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

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

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

為敏捷方法正名

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

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

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

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

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

通過數(shù)據(jù)運(yùn)營和數(shù)據(jù)治理加快機(jī)器學(xué)習(xí)

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

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

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

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

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

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

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

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

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

完善開發(fā)運(yùn)營實(shí)踐時運(yùn)用客戶理念

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

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

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

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

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

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

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

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

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

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

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

當(dāng)組織采用這些類型的實(shí)踐時，就不必強(qiáng)行要求敏捷性。敏捷性成為了共同的價值觀和完成工作的標(biāo)準(zhǔn)方法。

本文作者Isaac Sacolick著有亞馬遜暢銷書《駕馭數(shù)字化：通過技術(shù)進(jìn)行業(yè)務(wù)轉(zhuǎn)型的領(lǐng)導(dǎo)人指南》一書，該書介紹了許多實(shí)踐，比如對成功的數(shù)字化轉(zhuǎn)型計劃至關(guān)重要的敏捷規(guī)劃、開發(fā)運(yùn)營和數(shù)據(jù)科學(xué)。Sacolick是公認(rèn)的頂尖社交CIO，在數(shù)字化轉(zhuǎn)型領(lǐng)域頗具影響力，還是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