DevOps的邏輯思維與技術

正確實踐DevOps的方法,是先知道自己在哪裡,再設定目標並運用持續改善來達成它。

-符合邏輯的思考

.

0046

DevOps是解決软件开发人员IT运维人员之间的 沟通問題

.

DevOps的定義:

一种重视「软件开发人员」和「IT运维人员」之间 沟通 合作的文化、运动或惯例。也就是解決软件开发人员IT运维人员之间的 沟通問題。

實行DevOs就是在解決組織內溝通的問題,若是溝通順暢了,開發自然變快、運維也就自然的順暢起來,而發布時間也就一直在加速了!

.

0028

演講題目詮釋;我將用一個顧問的角度來看 DevOps.

.

講這個題目的原委

因為推廣DevOps的關係,連續講了幾年的系統思考System Thinking。始終有一種看不見效果的感覺,一種只看見自己的病但別人都無感的現象,學員們到底獲得了什麼,始終讓人存疑?最近;在一場讀書會(研讀的是唐內拉‧梅多斯系統思維)裡突然感覺到這是邏輯思維不夠清楚的問題;才導致大家研究了半天的系統思維卻問題多多。其實是沒能清晰的辨識系統的基本組成元素(元素、連接及目標;組成系統的三要素)所致,自然無法深入去分析系統的運作方式。從基本元素element開始就弄不清楚了,所以;應該從這裡下手也就是奠定邏輯思考的能力。避免由於對邏輯思考上的不足,導致無法順利進入系統思維的領域,所以才想到這個題目: DevOps的邏輯思考與技術

.

0071

從邏輯思考的誤區開始說起,並參考麥肯錫的思維系列文件

 

.

0033

在多變的世界裡要能看見全貌是一種奢望,但它是實踐系統思維的一部份。

.

0035

追求由 Doing DevOps進化到 Being DevOps.

.0035_01

 

團隊成員具有清晰良好的邏輯思維,對團隊內部溝通無礙間接促成組織展現良好系統思維的基礎。

.

0036

對演講內容,做一下概要總結.

.

0035

看見全貌之後首先要衡量自己在哪裡? 如此才能知道自己距離目標有多遠.

.

0038

我們在哪裡決定你在實行哪一種 DevOps的策略.

.

0037

敏捷運用小增量、迭代與反饋來協助客戶解決問題.

.

0039

DevOps 的目的在能夠更快速地提供客戶穩定的產品功能.

.

0042

進行溝通時不可或缺的清晰邏輯.

.

造成溝通不良的主要原因是;模糊的前言與跳躍、不連續的思考方式。

.

0041

以一個專業顧問(麥肯錫公司)的角度來審視如何實施DevOps.

.

0044

其實DevOps在解決 IT 跟開發人員的溝通問題.但大家卻把注意力都放在 Doing DevOps上,反而很少人能做到 Being DevOps.

.

未命名

這裡要談的是「」的問題,也就是成功溝通的邏輯思考的問題.

.

0045

溝通就像在玩傳接球的遊戲一般,只是球被換成了訊息.

.

0045_01

良好的溝通通常都會有三個基本要素: 清晰的問題具體的答案可以期待的行為反應或理解。

.

0046

團隊存在DevOps中的位置決定著即將面臨的障礙.

.

0029

目前你的團隊正在遭遇哪一種障礙?

.

0047_01這張圖在描述實體層面上的問題。由右往左;是在描述溝通瓶頸的二個Gap在哪裡,它們相關的物件(需求/發布計畫),我們可以由能夠運用的工具語言看出,發布計畫在這裡缺少了專屬的語言,造成溝通上只有文件化的不利情境。由左往右看;則是先確定你在哪裡呢? 團隊是否已經在運用最下層所提供的工具呢? 還是商未採用,抑或是運用得不順暢,可以加以度量並尋求改善。

.

0048範例: 溝通的誤區 PO to 工程師.

.

0049

範例: 溝通的誤區 開發 to 運維工程師.

.

0049_01

溝通訊息的三要素: 問題答案期待對方的反應

.

0048

探討如何由 Doing DevOps 走到 Being DevOps.

.

0051

你是在Doing DevOps 還是 Being DevOps.

追求更快速的開發只是 Doing DevOps,為客戶適時的發掘與更新問題才是 Being DevOps.

.

0052

由 Doing Agile 談起.

.

0052_01

Lean 是數位化的基石.

.

0051從 Doing Agile 到 Being DevOps 是我們實施 DevOps 的終極目標.

.

0052

運用麥肯錫著名的金字塔理論來審視實行DevOps的邏輯思維.

.

0053快速交付是我們追求的實質目標.

.

0054錐形才是合理的金字塔外觀(需求-開發-維運).

.

0056_01

金字塔背後隱含的是業務的作業項目.

.

0055

進一步;運用持續漸進的螺旋式曲線,更能符合由 Doing(實行) 到 Being(成為)逐步過程,而不是段落式的,先做完一個才再去做另一個. 這正符合敏捷的精神;小增量、多迭代、尋求回饋的模式。

.

0056

一個快速發布的思維模式.

.

0059

.

0058

.

0059

.

0060

.

0061

.

0062

Being DevOps 所該關注的不是發佈有多快速,而是在客戶回饋或是回饋之前就自覺的發布更新.

.

0063

.

0064

.

0065

.

0066

.

0067

.

0068

.

圖片 001

.

0071

.

0003

.

0004

.

0005

.

0006

.

0009

.

0010

.

0008_01

影響地圖是敏捷開發裡最適合業務人員介入的一環

.

0012

.

0013業務帶回客戶需求的同時,衍生出第一個版本的影響地圖,它是影響地圖的發起線,它可能只是一行式的影響地圖,就戲稱它為一行式的影響地圖」.

.

0014

一行式的影響地圖就足以取的展開式的較完整的影響地圖.

.

0014_01

一個有里程碑、有替代方案及事後評估衡量產出數據的影響的圖範例

.

圖片 003

將加強邏輯思考是為欲達成的目標,排列出影響地圖,並對交付做出預估度量

一個理想的影響地圖;應該有設定里程碑,並做到事前預估與事後衡量,並在回顧檢討時考量是否採用替代路徑

.

註: 以上是即將余4/30發表於中國大陸 DevOps線上峰會主會場的一場演講內容.

節錄一下重點:

一、正確的DevOps思維;應該是審視你現在組織的狀態,再去尋求此刻應該克服的既有障礙。

二、由 Doing Agile 走到 Being DevOps,是一種系統思維的方式,它是在客戶回饋或更早之前就自覺的發佈更新的方式。

三、在技術上;藉由麥肯錫顧問公司金字塔原理,以清晰的邏輯思考來克服組織溝通上的障礙。

四、推廣業務敏捷化「一行式的影響地圖」