敏捷與DevOps

說到 DevOps 免不了會讓人直接聯想到各式各樣的工具，而這也是 DevOps 之所以能夠加速軟體生產力的方法之一。 工具的使用，如果只限於個人，那麼就只是個人的意願問題而已，但如果把工具引入團隊內，那麼這問題就會稍稍變得複雜！比方說： 團隊內的成員是否熟悉這類工具？ 工具要如何融入團隊目前的工作模式？ 如果是工具舊換新，那麼資料要如何遷移？ 團隊是否有空做出改變？ 工具使用的成本是否可以承擔？ 講到這裡是不是開始覺得一陣頭昏腦脹了呢？不過就用個工具嘛！ 可別在這邊危言聳聽~ 上述的問題，運氣好的話的確有可能經過一陣摩擦後順利落地。運氣好不好這得端看工具影響的範圍和深度而定，結局就又回到上述各個問題。筆者就曾經遇過團隊花了大價錢買了工具全年的訂閱也請了外部講師做了一套培訓，結局是工具從一開始的零星使用到最後無人使用。這樣的故事並不少見，而當工具導入擴及到全組織時，那問題就又顯得更加麻煩。當然講到這邊都還只是提到工具而已，而 DevOps 可不只有工具，還有許多工程上的最佳實務做法… 所以到底該怎辦比較好？ 掌握工具或實務做法的影響範圍是做出任何改變的重要第一步！ 流程說穿就是完成一件事情的一連串活動和做法。如果我們能夠了解導入目標所相關的流程的話，那不就可以順著流程知道哪些活動、人和工具會受到影響，從而掌握影響範圍。因此，筆者在協助企業進行各式 DevOps 導入時，第一件會做的事情就是進行流程對照(Process Mapping)的活動。流程對照名詞聽起來很厲害，但其實就是透過視覺化的方式來把做事過程塑模下來的活動。進行這類活動有以下幾個步驟：

今年剛好有機會受國家資通安全研究院的邀請去參加 DevSecOps 人才培養的討論，與會者有的來自學界而有的來自產業界。整個討論以核心、次核心、外圍的任務、知識和技能的超大表來進行，項目總計應該有近百項，所幸研究員設計了一個討論方式，讓整個討論不至於按表操課到枯燥乏味，但是最後討論還是持續了三個半小時多。過程中，還有一些共同表達意見的部分，則又提供了一些貼心的小舉牌(如下圖)。 特別提出這個小舉牌其實是因為這種做法是相當值得稱許的。直觀來說，想法表達大致上就是「是」或「不」，這種極端答案，但實際上團隊討論時的確會存在實質願意配合而沒有特別想法的成員。這種時候逼迫他們非要選隊站，很容易提升作出選擇的困難或是導致討論變得極端。 回到 DevSecOps 人才職能的議題上，目前職能的項目和類型是以歐盟標準為核心，輔以美國的標準。 標準設計上，DevSecOps 工程師一職是被設計在安全交付此面向上，但安全「交付」的交付二字為這個職能帶來許多挑戰。面對不同類型的組織，其組織內的資安角色並不見得有如這類標準所列出的精美配置，所以這也使得該職能工程師的工作範圍可大可小。不過，可能會有人認為 DevSecOps 它是一種機制、文化或做事的方法，而非一個角色，這說法自然也沒什麼毛病，但就像 DevOps 本質上也是種軟體開發的做法、機制和文化，但最後市場還是多了很多 DevOps 工程師和部門，所以 DevSecOps 也很自然地往這方向發展。往好的方面看，這也代表這樣的機制、做法和文化被期待內建到組織中。或許文化這樣的概念會因為這些內建的演進漸漸地在組織中形成吧!? 所以簡單來說，從當前標準的職能定位來看，DevSecOps 這類角色有點像是昔日的安全工程師加上 DevOps 工程師的味道！ 有這麼簡單!!!?? 這幾年在現場協助企業落地實施 DevSecOps 時，我比較容易感覺到這類角色常常就是我們半驕傲半苦笑說的一條龍工程師 再加上需要了解「安全知識」並且「知道如何將安全左移到每個軟體生命周期階段」，以便確保軟體在「端到端“交付”是安全的」。講到這兒~我不禁為這職能捏把冷汗，心裡直嘆好厲害的一個角色。

溝通是一切的起點，而最有效的溝通在於面對面 BizDevOps 的目標在於讓商業人員、管理人員和工程師能夠有一致的目標，並且在具備共同認知的情況下協同達成目標。為了能夠達成目標且提供客觀的基礎，資料驅動是必要的方法，透過資料我們可以將產出、任務、需求、流程和商業關係聯繫起來，從而能夠透過整體的角度來思考需求並且制定權衡的政策。 有了權衡的政策，下一步便是找出需求和制訂計劃，並且透過團隊的工程能力來實現需求。這一連串的過程涉及了不同人事物的溝通和資訊交換。單純地透過文字是很難在第一時間將彼此對齊在同一個認知上，需求的利害關係人必須面對面地確認和協調需求的樣貌。 基於面對面的溝通也才能有效地勾勒出需求的輪廓並且找出具體的實例來協助團隊中的每一個成員，運用自身的能力來實現需求。 完整的團隊仍然是一個關鍵要點 傳統組織按職能區分人員結構，這讓組織人才的技能得以深化且經驗得以順利傳遞，但這也使得面對面的溝通變得困難，甚至是讓不同職能的人對齊組織的價值目標也變得困難。畢竟每個人都專注於一整件事情的某一部分，對該部分負責也對專責的技能負責。 為了突破這種僵局，思考如何在組織內按照價值目標組建一個 5~15 人以內的完整團隊，就變得關鍵，但只是把一群人集合起來就想要獲得一個高效的團隊，這仍然是把事情想得過於簡單！不同的背景、不同的能力、不同的個性和各種不同會讓新組建的團隊深陷在風暴中，難以逃出，所以想要讓團隊快速脫離磨合期並且持續改善成長。團隊務必找出： 團隊協定:人與人之間合作的方式 任務標準:處理事情的標準 透過找尋協定與標準，會幫助團隊更加了解彼此，並且知道團隊內的障礙。 一個團隊就能夠頂全部的產出? 除非公司自行開發的資訊軟體很少或沒有，而且也不太使用軟體服務，否則單靠一個小團隊就要面對各種問題，恐怕團隊也會隨著組織的增長而慢慢吃不消。 因此，我們必須思考如何組建一個有機的大團隊！ 有機的大團隊以拓樸的角度看待每個自組織的小團隊，讓大團隊中的各種能力可以發揮在必要的目標上，而且也不會因為強迫拆分所造成部門牆導致價值目標的破碎和工作依賴所造成的浪費。 不過，就像團隊內需要有協定與標準！團隊之間也需要有協定和標準，以便讓各團隊之間可以快速地進行協作達成目標。團隊期待他人(團隊)與其合作的方式和標準就是團隊的 API。簡單說就是團隊的使用手冊 不管組織是透過自組織方式來組建各種團隊還是透過組織情境與需求來組建團隊，我們都可以透過團隊拓樸1的概念來思考。按照《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一書中所言，組織裡的團隊按照其交付內容的質性可以分為四種基礎類型：

由 FinOps 的權威機構：FinOps 基金會（FinOps Foundation, F2）所訂定的 FinOps 框架在 2024 年迎來了改版，包含更新 FinOps 一詞的定義[1]、擴展參與和關聯的角色等，而最大的變動在於簡化 FinOps 框架中的實踐領域，並更完善各實踐領域下所需具備的執行能力[2]。下圖是 FinOps 基金會官網最新版的框架總覽圖： 資料來源： FinOps 基金會官網：Framework overview 重點更新：FinOps 定義 早期的時候，雲端的財務管理包含了使用 Cloud Cost Management（雲端成本管理）、Cloud Financial Management（雲端財務管理）一詞。 (2021): “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.