正確實踐DevOps的方法，是先知道自己在哪裡，再設定目標並運用持續改善來達成它。
-符合邏輯的思考
.
DevOps是解決软件开发人员和IT运维人员之间的 沟通問題
.
DevOps的定義:
一种重视「软件开发人员」和「IT运维人员」之间 沟通 合作的文化、运动或惯例。也就是解決软件开发人员和IT运维人员之间的 沟通問題。
實行DevOs就是在解決組織內溝通的問題，若是溝通順暢了，開發自然變快、運維也就自然的順暢起來，而發布時間也就一直在加速了!
.
演講題目詮釋；我將用一個顧問的角度來看 DevOps.
.
講這個題目的原委
因為推廣DevOps的關係，連續講了幾年的系統思考System Thinking。始終有一種看不見效果的感覺，一種只看見自己的病但別人都無感的現象，學員們到底獲得了什麼，始終讓人存疑?最近；在一場讀書會(研讀的是唐內拉‧梅多斯的《系統思維》)裡突然感覺到這是邏輯思維不夠清楚的問題；才導致大家研究了半天的系統思維卻問題多多。其實是沒能清晰的辨識系統的基本組成元素(元素、連接及目標；組成系統的三要素)所致，自然無法深入去分析系統的運作方式。從基本元素element開始就弄不清楚了，所以；應該從這裡下手也就是奠定邏輯思考的能力。避免由於對邏輯思考上的不足，導致無法順利進入系統思維的領域，所以才想到這個題目: DevOps的邏輯思考與技術。
.
從邏輯思考的誤區開始說起，並參考麥肯錫的思維系列文件
.
在多變的世界裡要能看見全貌是一種奢望，但它是實踐系統思維的一部份。
.
追求由 Doing DevOps進化到 Being DevOps.
.
團隊成員具有清晰良好的邏輯思維，對團隊內部溝通無礙間接促成組織展現良好系統思維的基礎。
.
對演講內容，做一下概要總結.
.
看見全貌之後首先要衡量自己在哪裡? 如此才能知道自己距離目標有多遠.
.
我們在哪裡決定你在實行哪一種 DevOps的策略.
.
敏捷運用小增量、迭代與反饋來協助客戶解決問題.
.
DevOps 的目的在能夠更快速地提供客戶穩定的產品功能.
.
進行溝通時不可或缺的清晰邏輯.
.
造成溝通不良的主要原因是；模糊的前言與跳躍、不連續的思考方式。
.
以一個專業顧問(麥肯錫公司)的角度來審視如何實施DevOps.
.
其實DevOps在解決 IT 跟開發人員的溝通問題.但大家卻把注意力都放在 Doing DevOps上，反而很少人能做到 Being DevOps.
.
這裡要談的是「人」的問題，也就是成功溝通的邏輯思考的問題.
.
溝通就像在玩傳接球的遊戲一般，只是球被換成了訊息.
.
良好的溝通通常都會有三個基本要素: 清晰的問題、具體的答案與可以期待的行為反應或理解。
.
團隊存在DevOps中的位置決定著即將面臨的障礙.
.
目前你的團隊正在遭遇哪一種障礙?
.
這張圖在描述實體層面上的問題。由右往左；是在描述溝通瓶頸的二個Gap在哪裡，它們相關的物件(需求/發布計畫)，我們可以由能夠運用的工具語言看出，發布計畫在這裡缺少了專屬的語言，造成溝通上只有文件化的不利情境。由左往右看；則是先確定你在哪裡呢? 團隊是否已經在運用最下層所提供的工具呢? 還是商未採用，抑或是運用得不順暢，可以加以度量並尋求改善。
.
範例: 溝通的誤區 PO to 工程師.
.
範例: 溝通的誤區 開發 to 運維工程師.
.
溝通訊息的三要素: 問題、答案 和 期待對方的反應
.
探討如何由 Doing DevOps 走到 Being DevOps.
.
你是在Doing DevOps 還是 Being DevOps.
追求更快速的開發只是 Doing DevOps，為客戶適時的發掘與更新問題才是 Being DevOps.
.
由 Doing Agile 談起.
.
Lean 是數位化的基石.
.
從 Doing Agile 到 Being DevOps 是我們實施 DevOps 的終極目標.
.
運用麥肯錫著名的金字塔理論來審視實行DevOps的邏輯思維.
.
快速交付是我們追求的實質目標.
.
錐形才是合理的金字塔外觀(需求-開發-維運).
.
金字塔背後隱含的是業務的作業項目.
.
進一步；運用持續漸進的螺旋式曲線，更能符合由 Doing(實行) 到 Being(成為)逐步過程，而不是段落式的，先做完一個才再去做另一個. 這正符合敏捷的精神；小增量、多迭代、尋求回饋的模式。
.
一個快速發布的思維模式.
.
.
.
.
.
.
Being DevOps 所該關注的不是發佈有多快速，而是在客戶回饋或是回饋之前就自覺的發布更新.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
影響地圖是敏捷開發裡最適合業務人員介入的一環
.
.
業務帶回客戶需求的同時，衍生出第一個版本的影響地圖，它是影響地圖的發起線，它可能只是一行式的影響地圖，就戲稱它為「一行式的影響地圖」.
.
一行式的影響地圖就足以取的展開式的較完整的影響地圖.
.
一個有里程碑、有替代方案及事後評估衡量產出數據的影響的圖範例
.
將加強邏輯思考是為欲達成的目標，排列出影響地圖，並對交付做出預估度量
一個理想的影響地圖；應該有設定里程碑，並做到事前預估與事後衡量，並在回顧檢討時考量是否採用替代路徑。
.
註: 以上是即將余4/30發表於中國大陸 DevOps線上峰會主會場的一場演講內容.
節錄一下重點:
一、正確的DevOps思維；應該是審視你現在組織的狀態，再去尋求此刻應該克服的既有障礙。
二、由 Doing Agile 走到 Being DevOps，是一種系統思維的方式，它是在客戶回饋或更早之前就自覺的發佈更新的方式。
三、在技術上；藉由麥肯錫顧問公司的金字塔原理，以清晰的邏輯思考來克服組織溝通上的障礙。
四、推廣業務敏捷化的「一行式的影響地圖」。
