憑心而論，敏捷性無法強制要求，但可以強調優勢透過共識達成目的。
文／Isaac Sacolick 譯／Nica
就算領導者在大廳宣稱企業組織必須更敏捷更靈活，還是無法強制做到。CIO與IT領導者可以標準化所謂敏捷方法標準的實作、指標與責任，但無法命令所有人接受敏捷文化與心態。
你可以選擇敏捷工具、利用DevOps實作更自動化，也可以啟用「公民資料科學專案」(citizen data science programs)，但無法強迫員工採用、要求員工欣然接受。IT操作可以運用混合多重雲端架構，但不見得代表成本已最佳化，或基礎架構能夠神奇地自動擴充縮減。
所以，若你尋求的是快速標準化敏捷處理程序，或藉由移轉到敏捷基礎架構而神奇地處理技術負債，又或是立即轉型成敏捷工作模式，那麼你可能要失望了。敏捷不是自由來去、廉價或輕鬆容易的。無法在固定時間表下用甘特圖管理它。
[ 大師開講─台大資管曹承礎教授：企業數位化 CIO的關鍵領導力 ]
儘管我深信敏捷是大規模由下到上的轉型，但不意謂著開發人員、工程師、測試員、敏捷專家與其他IT團隊成員能各司其職推動敏捷性。團隊必須協同合作、認同權衡取捨，並在對利益有共識的情況下定義敏捷操作原則。
那麼，若敏捷不能被強制又需要所有人的貢獻，企業組織要如何變得更敏捷？在敏捷方法、資料驅動實作與採取DevOps文化的種種精神下，本文將介紹幾種IT企業所有人都能協同合作推動敏捷的方法。
悍衛敏捷方法論
筆者在著作《Driving Digital》第二章講的是從基礎scrum實作到更全面性的敏捷規劃程序，其中包括指派角色與責任、規劃多種衝刺訂單(Spring Backlog)【譯註：敏捷開發scrum裡的專有名詞】，以及標準化估算實務。我與團隊合作嘗試採取敏捷心態與文化時，會一起建立釋出管理訓練、基礎架構標準、敏捷原則與其他推動敏捷的指導方針。
但這並非實施敏捷的準則。不同企業組織營運策略各有差異，組織架構、組織文化、人才、合規性要求以及傳統與現代化架構混用程度都不同。這些背景因素在考量何時與何處套用不同敏捷實作時，至關重要。
舉例而言，大型企業可能有專門處理領導者們想快速開發與釋出給員工的行動應用API幾組團隊。另一個團隊則可能處理移轉主要用於管控、稽核與全球業務操作錯綜複雜的舊式系統。
[CIO都在讀： IT必須掌握的新核心能力 ]
這兩組團隊有可能遵循一致的、慣例的與規明嚴明的敏捷實作嗎？這無疑會讓偏好採用更民主與自動組織敏捷方式的API團隊感覺受到約束，留下許多決策給團隊處理。另一方面，又給予太多自由，讓處理複雜、營運核心舊式傳統的團隊處於更大風險。
目標與限制的差異，便是投身敏捷方式的企業，在定義敏捷原則時，何以必須培養發問「為什麼」的問與答文化之故。當領導者決定怎麼做而不解釋為什麼，人們就難以採用隱含實際意義的作法。解釋敏捷原則 ─ 尤其解釋為什麼這麼做，可以幫助團隊在決定何時、何處與如何套用敏捷實作時做出更好的決策。
利用DataOps與資料治理加速機器學習
我喜歡蜘蛛人那句名言「能力越大，責任越大。」每個企業都想要資料科學家、資料視覺化自動程式與公民資料分析師持續得出見解協助制定決策。但這種能力也需要資料、分析與機器學習團隊採取積極資料治理與DataOps實作，處理企業組織的資料品質、安全性、隱私權、主檔資料管理(MDM)與資料整合需求。
因此，當分析團隊致力於更敏捷、更頻繁交付報告結果，並增加用於分析的資料集數量時，資料團隊則必須依合規性要求，強化底層資料處理基礎，逐步發展企業營運的期望。
[CIO都在讀： 所有企業都想要的12種CIO技能 ]
敏捷並非想要就要或透過強制就能做到。當多重專業團隊體認到敏捷的重要性而協同合作改善分析報告的交付與資料處理基礎時，資料與分析處理程序會逐步形成。這裡有幾個例子：
- 公民資料科學專案要求參與各方，在釋出新資料視覺化前，界定與維護資料探索與定義。
- 資料科學團隊將機器學習模組、定義飄移參數記錄下來，並以界定的生命周期為基礎，維護已上線模組。
- 資料一致性與品質團隊將分析團隊視為客戶或利益相關人。透過分析團隊定期檢視資料角力(wrangling)效能、評估並調整資料模組後整合，減少下游資料處理。
- 所有獲得處理資料許可的團隊，定期檢視資料安全性、合規性與隱私權需求的變化。他們採取安全性、資料或技術負債缺口，並為彌補的工作指派優先順序。
- DataOps與雲端操作團隊主動提升監控等級、容量規劃與基礎架構自動化，以符合成長中的資料處理與分析團隊的執行效能要求。
敏捷性，帶來協同合作，以及平衡想要與需要的工作。此外，這個新時代的 Big data、機器學習與自主商業智慧(BI)程式，無疑將會自動產生新的一堆資料負債、資料孤島與資料安全性風險。
DevOps實作完善過程採用消費者心態
採DevOps文化與實作的企業組織，正致力於解套長達數十年來的IT悖論──如何賦能敏捷團隊，交付少量、頻繁、低風險變更，讓產出能滿足使用者並提升企業，而又不破壞可靠性、安全性、執行效能與其他營運服務水準？
DevOps實務與工具，可以解決導致重大意外的IT變革管理處理程序的落差、需要根源肇因分析的複雜問題、拖累佈署的棘手基礎架構相依性，以及長久以來的安全性議題。以下是幾個DevOps成功案例：
- 套用私有及公有雲的企業組織使用安全的基礎架構程式碼(Infrastructure-as-code, IaC)自動化環境的佈署與拆除。
- 敏捷開發團隊自動化測試，並使用 shift-left 的持續整合/持續發佈(CI/CD)管道簡化建置與佈署。更先進的團隊則將安全性驗證納入他們的管道並採納devsecops。
- IT營運改善管理繁複的無伺服器佈署、微服務架構，並增加監控與佈署AIOps平台混用多重雲端網路，改善能見度與事件應變能力。
這些都是處理IT敏捷與操作上悖論的策略要素，但一頭栽進這些專案而沒有任何策略，就可能導致毫無任何商業價值的IT成果。更糟的是，有時它會促使IT在自動化上過度投資，損及營運優先處理事項的交付。
假設，你正將舊有三層式架構應用現代化，準備移往公有雲，必須確定實施自動化到什麼程度。你應如何定義怎樣才足夠？應如何定出在DevOps上改善成功的標準？
[ 加入 CIO Taiwan 官方LINE，與全球CIO同步獲取精華見解 ]
問題與規範，有助於解答上述提問。有些稱之為服務等級需求。有些則被描述為非功能性需求。有些情況下，高度參與的利益相關人要求每天釋出報告與99.999%的可靠度。其他情況則是，很難讓定義需求所需要的利益相關人參與。
每種狀況挑戰各異，但就敏捷所需的共同點來看，是從定義客戶、客戶角色及成功準則開始。當你的利益相關人過度遵循規範時，將他們提出的需求，與合理商業敏銳度的需求區隔開來就很重要了。而當他們的需求不明確時，將成功的標準記錄下來就特別重要。
許多企業組織定義產品管理或商業關係管理責任，以便獲得與分享目標客群形象、成功準則與營運需求。將客戶心態帶進DevOps團隊與實作中，是有助於企業組織釐清要投資哪些自動化與投資到何種程度的最佳實作。
簡而言之，敏捷性無法強制。敏捷性只能透過領導者與貢獻者間的協同合作達成。敏捷團隊必須以自動組織原則與標準的方式作業。必須在營運所需的交付提升，與處理資料、營運與技術負債之間取得平衡。設定優先順序、定義成功準則，以及確認定義客群形象與瞭解客戶需求及價值所需的最低標準為何。
企業組織採取這幾種實作方式時，就不必要求敏捷了。敏捷已成為共享價值與把工作作好的標準處理方式。
（本文授權非營利轉載，請註明出處：CIO Taiwan）
