衡量 – DevOps 架構下的人工智慧思維

.

這堂Session (2018 DevOpsDays 台北 Keynote session)目的在談衡量的意義及我們的做法;會採用倒敘的方式開始,由後往前講,首先描述我們公司Data 團隊對資料分析的處理步驟(有一個案例),會談到一點點OKR對應到Sprint目標的度量(註),然後再談到看板對衡量的助益及我們如何將衡量置入工作流程中,千萬不要將衡量單獨拿出來執行,而成為一種浪費(要精實Lean),有帶到「數據崇拜」的觀念這是針對手機低頭族的一個新詞彙(它源自《人類簡史》作者:尤瓦爾•赫拉利),接著在談到衡量/度量的意義。至於餐廳這一段是真實度量的說明,有一段影片要放,目的在闡述數據分析本身不應該是重點,解題方案才是。(閃電秀: 我們需要專職的 ScrumMaster嗎?)

.

數據分析只是一個過程,解題方案才是主角。

.

0001

.

0002

.

0003

.

0004

.

0005

.

0006

.

0007

.

0008

.

0009

.

0010

.

0011

.

0012

.

0013

.

0014

.

0015

.

0016

.

0017

.

0018

.

0019

.

0020

.

0021

.

0022

.

0023

.

0024

.

0025

.

0026

.

0027

.

0028

.

0029

.

0030

.

0031

.

0034

.

0035

.

0036

.

0037

.

0038

.

0039

.

0040

.

0041

.

0042

.

0043

.

0044

.

0045

.

0046

.

0047

.

7

Google 的合格標準為 0.75

.

0048

.

0049

.

0050

.

0051

.

 

註. OKR 的度量

OKR (Object & Key Result) 目標關鍵結果,這裏我拿它來跟Sprint 的Scrum process 相對照。目的是激勵與明確化Sprint目標達成的度量,主旨是在讓負責開發作業的工程師,也能夠時時不忘記Sprint目標的商業意義(好難)。

 

 

 

廣告

敏捷轉型要從PO作起

過去我輔導的轉型案例裡,起手式都是依據看板之父也就是 David J. Anderson 先生所謂的一種成功的方式(註1,第一步、專注於質量)的切入法來開始改變組織的行為模式的,也就是從「要求品質」開始,更具體的說;就是從開發部門開始改起。這種敏捷化的起步方式看起來十分合理,因為敏捷的初期本來就是針對開發單位所應運而生的(2001年的敏捷宣言目標是專注於開發團隊),因此從開發單位開始改起就很合理了,再來對開發及運維單位做要求品質改善的行為,本來就是不可或缺的要求,所以從這裡下手很少會遭人反對的,再說進行品質改善是一種換來紀律的行為,對團隊有利而無弊,很少會有人反對的意見。但是我發現這麼做是錯的…

 

敏捷轉型要從產品部門做起

最近,突然發覺敏捷轉型要從PO作起才是對的,為什麼呢? 因為如果是由客戶端就要求你在開發時,每2到3週就要讓我看到成果,要求進行功能檢核,到底做得對不對、合不合我用,然後尋求我的回饋來作調整的話,這不就是一種小增量、迭代式的開發嗎?這就是敏捷啊! 而客戶給出的需求只要求能領先開發團隊產出的2到 3個開發週期就夠了,需求的優先順序也是客戶說了算數,這個小開發週期結束時的展示會議(review meeting,就等於SCRUM的檢核會議)看起來就好像是在作驗收一般,這位扮演客戶角色的團隊成員不正是我們不陌生的PO (product Owner)嗎,他的要求自然而然地會將團隊導向敏捷化的路徑上,團隊為了符合PO的要求,不得不將步調挑整成一種小增量、小迭代的模式,這個時候的開發流程也就自然而然地符合了敏捷的精神,而團隊的開發方式自然的就敏捷化了,真是事半功倍。所以敏捷轉型要從PO所在的產品部門做起。

.

人們的需求才是真正在改變這個世界的起因。

.

讓需求敏捷化來引導開發團隊

一切都要由讓需求夠敏捷化開始不要讓開發部門再去主導敏捷化的行為了,應該讓需求來引導開發團隊的行為才是,需求一旦敏捷了團隊自然就敏捷了。而需求如何變敏捷呢?自然是產品規劃部門運用符合敏捷開發的方式來規劃需求的產出,由此作推論,便是組織推行敏捷化要由產品的規劃部門開始。過去我的做法則是一直由開發部門的敏捷化作開始,以讓開發人員踏上正確的敏捷原則為依據,運用一個較小的開發團隊成功的達成敏捷化的方式來作範例,作為組織敏捷化的標竿,然後在來希望這個成功的案例能夠吸引其他團隊來群起效法。這種起手式是許多書上的建議,由一個成功的案例讓開發團隊來主導敏捷化的過程,用好的開始逐步的來推行敏捷化。老實說;這麼多年以後,如果在讓我做一次的話,我會選擇由產品部門的敏捷化開始。或許這是由於推行DevOps所產生的改變吧,我們藉由下面這張圖來做說明: 首先;DevOps的概念實質上應該要包含商業的運作在內的,因此全名應該是 Business DevOps, 而 DevOps則是簡稱(註2.)。

.

DevOps系統思維.png

含有商業運作的 DevOps 圖示

.

上圖說明了,如果只有在開發(Development) 單位實行Scrum 的敏捷開發模式,則實質上是在運行Water-Scrum-Fall而非真正的敏捷化。真正的敏捷必須向前與向後去做推廣。因此由產品部門開始實行敏捷化能夠以較省力的方式,也就是從能夠承上起下的地方是最適合的起始點。

敏捷不是單一部門敏捷就說敏捷化成功了的,一定是由運維、開發一直到業務部門都敏捷了,企業才能嘗到哪種成功的滋味。由開發部門開始運作敏捷的方式,是一種由下往上的推行方式,而由產品部門開始敏捷化的方式則比較偏向由上往下的推行方式。相對的成功率會高一些,當然高層長官的支持,依然是成功的先決條件。只是由客戶的立場做起敏捷化來會更符合以顧客為導向的思維方式罷了。

.

需求看板.png

需求看板Up Stream / 開發看板Mid Stream / 運維看板Down Stream

.

需求看板是敏捷化的源頭

如果能從需求端就開始敏捷,則下游的開發與運維端便能夠自然而然地跟隨著需求而逐漸的敏捷起來。這個道理不難理解,但執行起來要從哪裡作起呢? 來自各方的需求,運作起來其實可以大致分成:規劃執行二個部分。上圖綠色部分是運作時的執行看板,也就是執行的部分,另外應該還要有一份企業俱有巨觀型的規劃看板,也是規劃部分(它應該包含許多大顆粒的需求,跟流動路徑與相對單位需要配合的價值流,這裡就不做細談)。它的流動方式決定了下游所有其他看板的依據。包括何時啟動由哪一個單位負責及需要些什麼配合。

.

需求的好壞決定了開發團隊的效能,需求的敏捷性則影響著團隊開發的模式。

.

需求要先視覺化;視覺化可能是最重要的手續之一,他可以確保開發的流程能夠符合精實的原則來進行,能夠適當的消除穀倉效應,因此產品部門要實施敏捷化的起步當然是由需求看板做出發,讓它務實的反應出規劃執行面的進度與流程(對於完成Definition of Done的定義有所不同,這是與傳統看板之間最大的差異處,相對的它將更專注於處理 Definition of Ready資料備妥)。運用透明化的訊息來與各個相關單位做聯繫,這一步是開始也將是敏捷化成敗的重要因素。

 

結語

如果看板之父的企業變革的「一種成功的祕訣」是減少組織轉型阻力的方法,則由PO需求開始敏捷化的啟動方式,便是一種事半功倍的轉型方法。開發與運維的敏捷化將由於PO對產品規劃的敏捷化而牽動,一種基於客戶的要求,為了與需求相配合而自然形成的敏捷化。這種思考方式是認為因為來自客戶端的需求方式,所引發的敏捷才是自然因應需求而生的敏捷,是一種在順暢不過的敏捷衍生過程,前提是以客戶為導向,所以用一種「敏捷的需求」來引發開發、運維配合而自然改變行為模式的敏捷,是一種事半功倍的轉變方式,也是一種符合以客戶為導向的開發模式。

邁克·考恩(Mike Cohn) 有一段話在支持這種想法

“The Scrum product owner is typically a project’s key stakeholder.
Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team.

This is key to successfully starting any agile software development project.
The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed”

– Mike Cohn

 

.

 

註1. 看板方法: 科技企業漸進變革成功之道》by: David J. Anderson

成功六步.png

.

註2.  BizDevOps (Business DevOps) 有許多單位向DevOps 之父反映過這個疑慮,Patrick 的回答是認同的,DevOps 應該包含商業運行,只是 DevOps 這個詞彙已經被大眾所接受了,沒有必要在做修改徒增疑惑,只要正確的詮釋就好了。 

 

看板上的指頭湯

手指湯.png

讓團隊自行做決策的手指湯

.

看板上運作的是團隊的活動,因此不應該由一個人來繪製它,應該由團隊一起來繪製,一起來擔心缺這個少那個,一起討論、然後一起來繪製、再一起改善它。

– 精實開發與看板方法

.

前情是: 老闆說我們需要一個看板。

忙碌的工程師們面面相覷,好像是誰先出聲誰就要負責似的,大家都不吭聲。

 

(沉默了一回兒…, Scrum Master 首先開口了)

 

「看起來大家都很忙碌的樣子,我們就讓團隊一起來做決定好了」

「我們來玩一個手指頭的遊戲,請大家圍成一個圓圈然後把食指借給我,我們用推舉的方式來選出團隊認為適合做這件事的人選,這叫全民推選,用民意來做決策。規則只有一條,就是被指到的人都是最適合的人選。」

「首先把手指指向天花板,然後開始畫圓圈,… 都好了嗎?」

(用手指頭畫圈的動作,狀似像攪湯的動作,因此稱為指頭湯,好吧,牽強了一點.)

.

「仔細聽我倒數由3開始,當我數到1的時候,就停止畫圓圈.」SM 大聲的說道.

 

「接著就把手指指向你認為最適合畫這個看板的人,好了嗎?」

.

「開始,3、…,2…、1」

.

「這是第一輪,凡是被指到的人,都是最適合的人,請後退一步」

 

「接著我們進行第二輪,請內圈的人把手指借給我」

.

「開始畫圓圈,3、…,2…1」

.

當大家都被指到後,結論是,所有的人都是適合畫看板的人,就大家一起來吧!

 

SM為了確認沒有人沒被選到,因此讓自己也加入圈圈裡頭,然後透過一輪在一輪的手指湯的遊戲,所有的人都被指到了。

.

結語

手指湯的概念來自石頭湯的故事(註),是希望團隊在自組織的原則下,共同來做決策,然後在一起來承擔責任所設計的遊戲,目的是在敏捷做前提下進行引導,在過程中,SM應該視狀況適時地做出許多改變遊戲規則的做法,例如: 先選出第一高票的人,在用指定的方式,讓持續引導的行為涵蓋整個團隊。其實團隊運作很多時候都可以採用這種民主決的方式來進行,目標是讓團隊一起做決策,然後透過遊戲來激發團隊成員一同參與的熱情。

.

 

註. 《石頭湯的故事》

作者:瑪西亞.布朗(Marcia Brown)

它是一本繪本,原文是Stone Soup,它不只是一個故事而已,圖片中引出了不少重要的含義,例如: 打破偏見,齊心齊力,終會成功。

「石頭湯」是歐洲家喻戶曉的民間故事。在法國、瑞典、俄國、英國和比利時,都流傳著不同的版本。

繪本

石頭湯的故事

 

故事在描述三個聰明的士兵,如何運用智慧在既滿足他人又滿足自己的需求的情境下成功的完成了與村民之間良好互動的故事。

 

看板驅動開發之度量篇

.

0004.png

.

0002.png

.

0003.png

.

0004_1

.

0005

.

0006.png

KDD 最大的支柱是精實開發的七大原則(盡量延遲決策)

.

0007.png

工程師在團隊看板前領取了自己想做的工作,然後回到座位上開始進行自己一天工作的規劃,他的目的是 : 追求效能。

.

0008.png

工程師在站立會議領完工作單後,回到自己的座位時,才開始真正的規劃工作。

.

0009.png

這樣的規劃就會有效能嗎?因此我規畫了下面的專門用來提升效能的「個人看板」來協助他改善。

.

0010

.

把單核工作法溶入到看板方法中,運用在專注模式與全景模式之間的切換方式,來獲得效能的提升。接下來我們來看一看這個看板的執行原理:

.

0010_4.png

上半部是一個人的 Scrum圖示, 下半部是對照的看板圖示

.

0011.png

提升效能要從時間管理開始

.

0011_1

.

0013.png

.

0014

一個人的敏捷不能少了回饋: 也就是寄信給自己,在信裡頭運用時間差的思維方式給自己一些意見。

.

0015.png

對照看板方法與三步工作法

.

0016.png

這是三步工作法的基本定義說明

.

0017

實踐上是以切蛋糕的方式而非依序的 一、二、三步驟。

.

0018.png

大家都知道流水線是最快的交付方式,但為何就是做不到呢?

.

0019.png

松耦合是快速開發、運維又能維持韌性的基本原則

.

0020.png

什麼叫放大回饋呢? 就是在每一個流程上的關卡去設定完成的準則,讓 DoD 成為每一到關卡的回饋,避免讓缺陷遺留到下流的工作中。

.

0021.png

看板方法是一種 Safe to fail 的機制

.

0022.png

.

0023

如何把度量Mapping 到DevOps 中

.

0024.png

制定指標是最重要的檢核步驟

.

0024_1

Accelerate 書中所強調的 Software Delivery Performance 四大指標

.

0026.png

客戶的滿意度,決定了返工的百分比

.

0027

DevOps 轉型的四大基本指標 – 如果你不能衡量它,就不能管理它。

.

0028

.

0029.png

.

0030.png

.

0031.png

.

0032

.

0033

.

0034

.

結語

公司可能早就已經辦過「持續交付」這本由 Jez Hummble 和 Dave 所合寫的巨著的讀書會了,但為何開發和運維就是沒有太多進展而死終無法實現它呢? 要知道;這本書花了他們二位四年的時間才完成(註1),而要能真正實踐它更絕非一朝一夕的事,但在我作顧問的這些年來,深深體會是人的阻力才是CI/CD最難突破的地方,明明知道應該怎麼做才對,但就是無法克服哪種受到已知的錯綜複雜和將會面臨的種種挫折感,而始終無法下定決心去做,就一再用各種藉口去敷衍自己,也就一再的錯過改善的時機點。何謂好的時機點呢?

例如:新創公司成功發布第一代的產品時,接下來的決心就是第一個時機點,它應該選擇重構整個程式架構呢?還是部分的維修,把人力繼續花再開發新功能上頭,畢竟滿足客戶、賺錢可以讓公司過得好些。沒關係!接下來還有發布第二代產品的時機點來了,你應該毅然決然的好好重構整個程式架構呢?還是做跟上一次一樣的選擇呢?就是任由複雜的邏輯在繼續增長繼續堆疊下去,也就是選擇繼續花在開發新功能上頭,以可以滿足客戶為藉口、賺錢可以讓公司過得好些! 這些抉擇讓你一在的錯過時機點,也就是成就卓越的機會,到後來公司有一點錢了,而你已經雇用了一倍的人力了,但還是無法回復像開發第一個版時那樣快速更新產品功能的能力。為什麼呢?原因是你錯過多次的機會點來重構你的程式及架構,讓複雜度開始拖累著所有的系統開發,即便大量的聘請優秀的程式人員,若不盡快開始重構你的系統,持續降低它的複雜度,只怕你只是想要正常的營運不想再擴充下去了,也會更加困難的。

因此我始終覺得,人的阻力才是快速改善、快速交付的最大障礙,而流程則只是工具,人性害怕複雜又貪圖近利,是最難突破的地方。所以即便已熟讀聖賢書,深知所以然了,還是要有足夠的勇氣跟決心才能做到真正的敏捷,正所謂的知易行難(註2)。

.

註:

這是一場沒有機會在國內講到的演說,紀錄一下2018/08/17上海 DevOpsDays,供大家參考。

註 1. Jez Humble 接受訪問談到撰寫「持續交付」一書的過程

註 2. 重構應該發生在(1) 小的功能程式完成後,(2) 與其他程式整合的時候,(3) 整合入系統的時候,(4) 系統發布前/後。 

 

 

站在看板前面,你該怎麼想?

0006

2018 DevOpsDays 上海,你扮演什麼角色?

.

無論你是剛好走過看板前面,還是刻意停下來打量它,應該做怎麼樣的思維才算精實、敏捷呢?

.

0007_00.png

.

先不要急著去看下面這個看板那些地方有問題,或是找有不符合看板規範的地方。應該先去感受它所輻射出來的重要資訊在哪裡?

.

看板前的思考.png

.

上面這個看板,很明顯的是中間的那個紅色圈圈裡的那張工作單,它是整塊板子第一吸引人的地方,也是團隊最想要被關注的地方,因此應該先關注它一下。

.

觀察看板第一件事,看到輻射資訊。

再來是 …

.

想要協助團隊改善嗎? 先考慮一下這麼做是否會干擾到團隊

無論你的意圖為何? 在看板前;首先要思考一下自己所扮演的角色,多說或多做的事,是否真能幫上什麼忙? 斟酌一下,或許你可以選擇把觀察到的意見寫下來,選擇用留下「建議」的方式,來協助團隊改善在看板上的資訊,也就是寫一張便利貼貼在醒目的地方留給團隊自行斟酌改進!(選擇沉默式的回饋,這樣可以在盡量不去打擾到團隊的運作下進行回饋)。還是選擇打擾一下負責這張看板的傢伙,用面對面溝通的方式來釐清這張看板讓你疑惑的地方(這麼做看似比較敏捷,但你所扮演的角色才是決定該不該這麼做的基本考量)。

.

不會有完美的看板的,它總是有需要改善的地方!

— 限制理論

.

如何持續改善呢?

嚴格說來;上面那張看板並沒有設定WIP(設定半成品數)值,板子上的欄位設計方式,有許多足以隱藏資訊的地方,確實是有改善的空間,但當我的角色是敏捷教練時,我應不應該把他(她)們集合起來,逮住機會即時的給團隊上一堂看板課程呢?

》不要著急! 先考慮一下;要怎麼做效果會比較好:   — 盡量延遲決策(註2)

  • 是由敏捷教練提出來作主動上課的方式,

  • 還是由團隊在意識到某方面的知識有所不足時,主動要求要上課的方式呢?

哪一種方式來的好呢! 同樣是教學,(註1. 團隊主動學習才是王道)選擇引發團隊的求知意識願意主動去追求改善可能是比較好的策略,這正是持續改善所應該要依序的方針。針對同樣的問題,運用引導的方式,往往會勝過直接處理的做法,來得好上許多。所以要設法讓團隊先產生求知的慾望,然後再順勢去推展才是王道。(給自己開一張單子吧,交給ScrumMaster 處理,或貼在自己的待辦事項裡,避免遺忘)

.

當你發現到看板可以改善的地方時,應該採取何種策略來進行改善呢?

.

給團隊一個小的目標

給團隊一個小小的目標讓團隊去達成,然後在達成後依循這個目標再加重一些,再制定下一個目標,再讓團隊達成,讓團隊一再的去克服它。這是一種比較容易引發團隊學習的作法,也能達到持續改善的效果。遇到比較成熟的團隊,可能會要求攻克較大的目標,就讓團隊自己去決定吧! 重要的是它促發了「持續改善」。而持續改善正是團隊最彌足珍惜的一種活動模式。一旦有一次成功的經驗,團隊就很容易會自然地進行複製,而產生成讓人驚訝效果!

.

衡量 vs. 度量

度量;這個詞聽起來就有工程上追求精準的味道,常讓人聯想的是小數點的取捨,該採用四捨五入呢?還是應該多加上幾位小數。英文都是 Measurement,但相對的;

衡量;聽起來就好像要寬鬆了許多,對一些比較不容易用數值描述的事物,必須用較抽象化的方式來陳述它時,「衡量一下」似乎就成了一個好的描述方式。千萬別用形容詞來描述它(註 3)

當你站在看板前面時,應該先問問自己你想知道什麼?

  • 是確切的工作進度呢,(那就去使用數位看板上所記錄的明確數據做依據,進行度量)。

  • 還是你只是想更清楚一下風險的大小?此時選擇衡量一下便是個好選擇。例如:設置紅綠燈的方式。

  • 還是只是順道逛過來隨便看一下而已。

如果是隨便看一下,就不要說什麼,趕緊離開,除非你看了以後產生了較明確的目的。否則盡量採取不干預團隊運行的理念,這是最好的原則。

.

我經常在看了團隊的看板之後,覺得可以提出許多的建議,或是覺得有許多可以改善的空間,但必須忍住不採取任何行動,要選擇相信團隊是正在朝著改進的路上前進,改善是需要時間去形成的,我們有心想幫助,但不該去干預團隊的運作,這種想法似乎有些消極,但一旦考慮到團隊的自主性時!主管就應該要選擇後退一步,盡量選擇潛移默化或事後引導的方式來進行改善,任意的干預是破壞團隊自組織的最大元兇。

.

可以從看板上獲得的訊息

燃盡圖最大的意義是讓團隊知道自己開發的歷程,至於完成的故事點數的多寡,就效能而言是沒有太大意義的。因為你可能只是對需求的點數估得太過寬鬆了而已。千萬不要為了團隊爆量的故事點完成率而獎勵團隊,那樣做的負面效果會遠勝過原來予以鼓勵的好意的。

看板可以讓我們看見一個使用者需求在開發、運維的流程上逐漸被實現的價值流。當然感受上不會像生產線一樣那麼的明確,也不會有像堆積木一般的踏實,可是在軟體開發上,流程中的即時狀態顯示應該是最具價值的,它能夠提供一個需求在開發中的透明性,它描述了即將發生的事件,若是正向的,則團隊會有一次成功的收穫,是負向的;則代表團隊即將面臨一次失敗的經驗,即便是失敗,也要讓他們一起去克服困難去完成任務,這樣才是培養出團隊自主性的方式。

也就是說;看板上最值得看的是工作單的即時訊息,就是工作的狀態,跟它所引發的討論。相對的,看板上最值得我們去修正的則是那些被隱藏了的訊息與它所可能引發的風險。

.

看板上最值得看的是工作單的即時訊息

.

衡量這二個字可以定義成增加或弄清楚對事物未知性的探索。或更具體一點: 就是「以數量表達的方式來降低不確定性」。例如:我們經常對無法控制的事項,改成用紅黃綠的方式來顯示狀態,就是一種衡量。

讓持續改善發生

設定WIP值的目的是為了從限制半成品數來做到持續改善。但往往會因為少了完整的說明敘述,而讓團隊成員忽略了這麼做真正的意義。

.

用文字敘述來描述目標,是使得看板溝通明確化的必要手段。

.

看板也會產生誤解

人們總以為我會這麼寫別人也一定會這麼想的,但實質上是預作了假設(自以為是),唯有經過確認才不至於產生誤解。在透明化的背後共識才是重點。當團隊的看板在有新成員加入時,確認新人對看板的認知是否與大家一致是入門課題。但其實也是考驗看板設計的好壞的時候,所以當有新人加入時正是重新設計看板的好時機。

.

目標: 如何實踐一種符合精實原則的看板運作

0008_1

.

結語

不過是看一眼看板,真的有必要這麼小題大作嗎?

在DevOps的時代裡,你經常需要捫心自問的是,我這樣做敏捷嗎? 是不是符合精實的精神呢? 身為團隊的一員,你可能是主管、PO、SM或是程式員,不論你的角色為何,要回答上面的問題,要讓團隊更敏捷都是你隨時隨地應該要關注的,它不是ScrumMaster 一個人的職務,是企業全員的責任。

.

看板前思考風險? 是應該干擾團隊嗎? 符合精實原則?

.

0007_1.png

情境示意圖: 用來回答我這樣做敏捷嗎? 是不是符合精實的精神呢?

.

 

註1.  主動學習的效果遠勝於被動學習

0009.png

註2. 精實七大原則

消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、崁入完整性、著眼全體。

.

註 3. 撰寫使用者故事的時候,最怕寫成「又快又好」這種形式,因為這種用形容詞來描述需求,會造成對目標的無法度量,較好的方式: 應該採用對比的說法,或直接給它下限值。例如: 最少每秒 10次。

DevOps的開發方法 – 看板驅動開發

.

0002

.

0003

.

0004.png

.

0005

.

0006

.

0007

.

0008

.

0009

.

0010

.

0011.png

.

0012.png

.

0013.png

.

0014

.

0015.png

.

0016

.

0017.png

.

0018

.

0019

.

0020

.

0020_1.png

二個重點是; 極度訊息透明: 共同意識。 去中心化: 賦能。

.

0021.png

.

0022.png

.

0023

.

0024

.

0025

.

0026

.

0027

.

0027_1

颱風報導是監控與持續度量的極端展現

.

0027_2

但結果卻往往出人意外

.

0028

.

0029

.

0030

.

0031

.

0032

.

0033

.

0034

其實需求更需要 Pull Request

.

0035

.

0036

.

0037

.

0038

.

0039

.

0040

.

0041

最好的回饋是能在問題發生之前提出預警

.

0042

.

0043

.

0044

.

0045

.

0046.png

.

0047

整理過的數據,一定要運用不同的視角在整理一遍

.

0048

讓效能成為適應性的後盾

.

0049

.

0050

團隊經常會淪陷在追逐故事點的迷失之下

.

0051

.

0053

.

0054

無論如何一定要嘗試用不同的視角來審視你所整理過的資料

.

0060

.

0058

讓開發作業更透明,因為工程師總是在開完站立會議回到自己的座位繼續規劃工作

.

0059

.

0057.png

.

 

註 : 《加速:精益軟體和DevOps的科學:如何構建和擴展高性能的技術組織》一書,為 Nicole Forsgren,  Jez Humble,  Gene Kim 的共同著作。它對 Puppet & DORA 的年度報告做了充分的詮釋。

 

DevOps 三步工作法: 第一步 流動

.

0020

第一步是追求組織日常作業的高效能

.

DevOps 三步工作法第一步:流動 FLOW.就是追求快速,從提案成立一直到交付到客戶手上的時間,就是要快。但這其中的障礙是你必須先克服:

有一些你自以為不可能作到的事! (其實是心魔在作祟 …)

 

首先是; 實行 測試開發法 TDD

你會說:對不起;專案實在太趕了,跟本沒時間作TDD(我們甚至連單元測試都省略了!) 然而,專案從來就沒有不趕的時候。你會說新人實在太多了,沒時間做教育訓練,這一點就讓人想到伊拉克戰場上的霧卡VUCA理論,部隊裡總是有一堆沒經驗的菜鳥,但戰爭還是得打下去啊,等你訓練完了,可能也就不需要了,要知道敵人的情況也是一樣的。永遠沒有最佳時機點的。

.

再來是;《持續交付》書裡頭的流水線

這就比較複雜了,我們由整合開始談起吧!把資源都集中到Git是第一步,這個不難,難在你作 Trunk base development 了嗎? 你會說:不可能的,我們的團隊分工很細,除了前後台之外還有各種 Devices 的 App要處裡,不可能作到的。但信不信由你,Google 有 13,000 開發人員在一個程式庫裡,同時這麼做著。

.

接著是;自動化測試後自動布署

這就更有意思了,如果「開發環境 ≠ 測試環境 ≠ 上線後環境」的話,誰敢直接布署呢?(你會說:對我們所在的這個行業而言,就是不斷的在跟客戶進行互動作業,要做好 sandbox 開發環境,這是完全不可能的事…)

.

常常被問道:『敏捷化;到頭來也就是處理人的事情吧?』

我的回答總是肯定的:『是的!

.

如何做好DevOps的三步工作法呢? 打開心魔是第一步。

勇氣」是第一道障礙,「決心」則決定你可以走到那裡?

其實;對許多公司而言,都早已作到上述的事情了,而且這只是基本要求,不要懷疑?!別跟我說你沒聽過「搗蛋猴」了!這是化被動為主動的代表,又稱為故障注入Fault injection!你敢嘗試嗎 …

.

Chaos Monkey.png

用來追求線上極致的運維服務作業(2016 就到2.0版了)

.

後語

DevOps 三步工作法的第三步 持續學習與實驗,正是要用來打破這種因為對系統太過熟悉而預設立場的思維方式。因此要想做好 DevOps 必須先能 打開心魔 才是真正的起步。

.

在這個階段,知識是第二位的,改變的意願和能力是第一位的。

 

.