衡量 – 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目標的商業意義(好難)。

 

 

 

衡量: 讓紅黃綠燈更明確化

綠燈的顏色是世界共通的,不論走到哪裡都是『紅、黃、綠』三色。(英文用的黃色是 Amber 琥珀色,所以紅、黃、綠簡寫成 RAG.) 採用這三種顏色的理由是,因為對人類而言,最容易辨識的顏色依序是紅、黃、綠的緣故。顏色有隨著光線減弱而不好分辨的傾向。而紅色不管多遠、多小,依然可以清清楚楚的看到,而且從進入眼睛的光、傳入腦中的速度也以紅色最快,所以拿紅色來做警示訊息最洽當不過了。

 .

{ 紅綠燈最初問世是在1868年,是在英國的西敏寺使用紅綠兩種信號裝置。三燈式信號機則首見於1918年於紐約啟用的手動裝置;日本則是隔年的1919年在東京的十字路口利用紅、綠色板的手動式機械燈號,台灣是在1940年中山北路上設立了第一個紅綠燈。 }

.

燈號須先取得團隊對燈號的明確共識,以避免誤判(draw by Gina Abudi)

.

專案開發的紅黃綠燈

用燈號標示狀態,來關注它的風險,具有淺顯易讀的效益。聽起來或是看起來都似乎很容易又好用,在看板上也容易表現出來。一般的解讀是,「紅燈」拿來表示有重大問題發生了,專案時程可能會因此延誤或超出預算,需要我們立即的關注。「黃燈」表示有出現問題的可能性,需要開始關注它了。「綠燈」表示一切按照預期,沒有脫軌的現象。在運行看板的時候,我們常會在無法控制的工作卡片上,用標註燈號的方式來顯示它的狀態。(例如一些委外開發的工作項目,比較困難取得即時的資訊,就採用亮燈的方式來做風險管理。)

.

簡單但不夠明確反而容易造成誤解

顏色容易隨著亮度的不同而造成誤判。虛擬的顏色則容易跟隨著描述者所採用的詞彙而造成聽者的不同詮釋。例如:在看板的站立會議上,最怕出現QA人員描述最近的Bug必較多要亮黃燈了,提醒大家要注意品質。聽起來沒什麼問題,是QA人員在報告時,提醒大家要多注意品質,但這種描述的方式對透明度並沒有幫助,反而容易造成誤解,工程師可能解讀成「QA對我們的品質感到不滿」或是「我們害了QA人員需要加班才能完成測試的工作」。若以明確化為目的;較正確的說法應該要透過數字來的作報告,譬如:「 昨天Bug的解決比例是5/15,新增15個Bugs解決5個Bugs,品質亮黃燈。用這種方式來陳述事實而不帶容易讓人誤解的形容詞」。

.

站立會議作報告時;應該盡量提出可供衡量的數據,讓會議的內容更明確化。

.

範例

燈號在加上數據的陳述

.

適當的加入度量值

估算只是估算,基本上只是對未來即將完成工作的一種預計性時間的猜測。在沒有做完以前實在很難做成比較明確的度量,但如果因此而不去做衡量,就失去修正、改善的機會,犯了不敏捷的錯誤。

.

Measure

衡量Measure;只要能让你知道得比以前多,就是一项成功的衡量

.

追求敏捷化,我們需要知道得更多一點點
只要能夠獲得比以前多一點的訊息,就是一项成功的衡量。大家都知道傳統的開發方式就是做了一個最大的假設,假設我們能在專案一開始就把所有的事都想清楚的前提下,而犯了最大的錯誤假設,為了修正它,敏捷便以小增量、多個迭代的方式來取代它。至於,有什麼方法能使我們更敏捷呢? 那就是運用衡量measurement 來設法去減少假設跟猜測。至於要衡量什麼呢? 如何來衡量呢?(請參考,註1.如何衡量萬事萬物. by 道格拉斯‧哈伯德)

三件我們必須做衡量的事:

  • 不確定的事 – 為了做成決策,必須先做些假設的事
  • 有風險的事 – 我們害怕會出問題的事
  • 對訊息的判讀

 

.
衡量很難嗎?
為什麼要做量? 量的目的是減少風險,面對假設。因為敏捷很務實,不做太多假設,要做到這一點,要減少假設,只有透過度量的方式才能對一些訊息明確化。哈伯德教我們要做衡量:「宣稱萬事萬物沒有不能衡量的」。第一次聽到這句話時,你可能不以為然,但是如果你拿Bill Burnett所著的《Design your life》(註2. 為比爾‧柏內特與戴夫‧埃文斯所合著,是教人如何運用設計思維來設計生活的書,獲5顆星級亞馬遜圖書)裡面對你人生的衡量或是對個人健康、愛情的衡量方式,也就是拿狀態表的方式來作衡量,是不是就不會太排斥了呢(看起來是不是很像紅、黃、綠燈的形式,只是它多分了一份,我個人偏好使用5等份的評估方式)?

Measure_love對愛情做度量的狀態表

.

》請避免黃燈效應;影射人們在遇到需要下決策時,停下來觀望做了拖延的動作,也就是錯失良機的問題。在公共交通管理中,人們常常見到這樣的標語或口號:“紅燈停,綠燈行,黃燈亮了等一等”;“一慢,二看,三通過”;“寧停三分,不搶一秒”等。由此就產生了對決策過程中人們冠冕堂皇進行拖延的一種形象比喻--黃燈效應

.

什麼是好的度量

度量.png會改變行為的度量,才是好的度量

 

.

結論

請把衡量拿來當成減少不確定性、優化問題的有效手段. 這一點應驗了管理學之父. 彼得·德魯克 Peter F. Drucker 所說的: 「如果你不能衡量它,就不能管理它」。我們拿公司的老闆來做比喻,你可以相信所有做老闆的人心中都有一把尺吧! 他拿它來衡量整個公司、所有有關的事物(怪不得做老闆的人都容易失眠)。 我們若把衡量放到敏捷開發裏頭來,前提是針對系統而非個人所進行的一種度量,它減少了許多的猜測,撇開了那些沒必要的假設,它讓我們更容易看到風險,也務實多了。(度量跟衡量被我混為一談了,原文是measurement)

.

後記; 於 2020/07/03,二年後再看這篇文章;對於目標明確的事務,可能會盡量採用 OKR的關鍵指標(Key Result)做衡量,原因是它有激勵的作用。它是四分法: 0 – .3 – .5 – .7 – 1.0, .7是最佳衡量值而不是 1.0,因為它能夠被期待未來會有更好的表現。

.

Measure_all

from Peter F. Drucker 

.

註1. 書: 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法,作者: 道格拉斯‧哈伯德。這是一本麻省理工學院指定教材,長踞亞馬遜網站商業類暢銷書榜,為一生受用的衡量技術!

註2. Bill Burnett所著的《Design your life》,史丹佛大學最夯的生涯規畫課圖書,中文書名: 

做自己的生命設計師:史丹佛最夯的生涯規畫課,用「設計思考」重擬問題,打造全新生命藍圖 (Designing Your Life: How to Build a Well-lived, Joyful Life) 

 

敏捷需求的分析工具

.

敏捷探討需求的分析工具

圖示.png

敏捷探討需求的分析工具說明

.

專案負責人Product Owner的利器

  1. 產品心經: 產品經理應該知道的60件事
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 用戶至上 (Understanding your users: a practical guide to user research methods) 用户至上(用户研究方法与实践原书第2版)
  4. 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法 (How to Measure Anything: Finding the Value of“intangibles” in business
  5. Essential Kanban Condensed  by David J Anderson and Andy Carmichael
  6. 使用者故事對照 (User Story Mapping: Discover the Whole Story, Build the Right Product)
  7. Google 創投認證!SPRINT 衝刺計畫:Google 最實用工作法,5天5步驟迅速解決難題、測試新點子、完成更多工作!(Sprint: How to Solve Big Problems and Test New Ideas in Just 5 Days)