• 瀏覽: 38
[隱藏]

就算企業領導人提倡企業組織需要更敏捷更靈活,他們也無法強行要求敏捷性。你的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%的可靠性。而在另一些情況下,讓利益相關者積極定義需求會比較困難。

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

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

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

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



原文連結:https://inewsdb.com/數碼/軟體開發運營、資料科學如何才能敏捷?

inewsdb.com 日日新聞 . 掌握每日新鮮事



inewsdb.com 日日新聞 . 掌握每日新鮮事
[按此隱藏 Google 建議的相符內容]