系統思維下的 DevOps 和 Agile

.

0002

主題: 系統思維之下的 DevOps 與 敏捷

.

0003_01

大家所面對的 DevOps在範圍上都有一些差異,但重點是先知道自己現在在哪裡?

.

0004_01

.

0005

簡單的說明一下系統思維常見的誤區

.

0007

避開誤區的思維方法 – DIE 法則

.

0011_01

總結一下系統思維

.

0012

DevOps vs. Agile

.

0013

參考自 Guru99 網站,我只是做了一下翻譯

.

0013_01

業務、產品部門與開發部門有許多協作的工具

.

0003_02

但運維人士 Ops Guys 缺少一種與大眾溝通的共同語言

.

0016

運維俱有前移與後移的雙向能力,敏捷只有前移功能

.

0021

知道自己現在在哪裡,才能思考該從哪裡開始,因此實踐 DevOps從定位開始

.

0023

不斷的讓自己處於透明、檢核與調適的情境才是應付多變環境的方法

.

0042

讓團隊從看板開始,是一種絕佳的透明方式

.

0043

強調多任務但單工作業的精實七大原則

.

0044

提一下喬梁老弟的持續交付2.0的雙環觀念

.

感觸

從2010年起,我年年參加多種 DevOpsDays 的聚會,卻始終等不到運維人士專屬的共同語言被發明出來,拿它來讓 DevOps 工作運行的更加順暢。雖然這個語言到現在還不見蹤影,但是相信不久的將來一定會有的。

對於需求而言;我們有「使用者故事」User Story可以拿來描繪客戶的種種需求,甚至有影響地圖Impact mapping、用戶故事地圖 User Story map或使用者情境圖來協助分析、製作、探討需求。更有「測試案例」test case、測試計畫來協助開發人員守住程式功能或產品的品質。但至為重要的運維端到目前為止,仍然只有發布計畫Release Plan 來做為溝通的文件,少了一種大家容易溝通的共同語言,讓 Ops運作起來,少了一種融入整個開發到運維的通識協作語言。

.

0013_01

一個好的需求遠遠勝過開發團隊做一大堆無關痛癢的工作

大家都知道;一個好的需求遠遠勝過讓開發團隊做一大堆無關痛癢的工作,因此協助製作、發掘需求的工具、技術一直再出陳更新,再多也不為過。

.

0015

但是PO所端出來的需求Listing,仍大多落於"校驗活動“的象限。

但大家都知道;需求能夠落在"差異化活動“象限中,才最有意義。

.

感觸抒發於至 中華電信 演講主題為「系統思維下的 DevOps 和 Agile」前夕。

.