owned this note changed 7 years ago
Linked with GitHub

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

tags: DevOpsDays Taipei 2018 9/11 09:40~10:20

歡迎來到 DevOps Days 2018 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口:https://hackmd.io/c/DevOpsDays2018
手機版請點選上方 按鈕展開議程列表。

在大會遇到任何問題都可以在下方的問題回報區中留言
大會問題與建議回報區

qrcode 簡報檔案

網頁版投影片

執行DevOps開發速度是否會變慢? 這很可能,但是要先從指標觀察。

開發速度變慢,但是Depolyment 速度變快,最後對公司就可能會是好的。

品質會變好,客戶會滿意,但開發速度會變慢,因此我們需不需要DevOps,需要!
如果每個禮拜都做一次Open Space,你的問題都會得到解答
不一定會得到答案 但是你會成長

衡量/度量的意義
將度量嵌入工作流
度量驅動開發 : KPI開發,當你去做度量的時候一定要有指標,知道該怎麼去衡量他
數據是不會講話的,如果你沒有足夠的數據素養,你的數據就是有問題的

問題:什麼樣的餐廳你會一去再去

怎麼讓客戶回流

* 衡量的重點不在於數據,而是看見問題後的解決方案

通常我們不是世界上第一個遇到這個問題的人

辨識第一次消費的人
引導第二、三次消費

給予回饋 刺激下次消費
牛肋,烤雞折價卷,cheess cake

衡量

減少不確定性,就是一種成功

專案開始之初,首重看見全貌

看到border 時,才是看到全貌的時候

定位 知道我們在哪裡

有數據才能定位

看板驅動開發看看版的資訊就好了

儘量把你的度量留在開發裡面,而不是看板之中

開發部門的疑惑: 拼命開發讓客戶滿意的功能,能夠增加多少利潤?

< 度量 ->
問題 > 系統分析指標 > 取得數據 > 說明

度量的第一個方法,先簡化(看少一點)

企業的利潤跟開發團隊的效能,有什麼關係?

利潤增加 >

CLD圖(解釋了流動的路線)

用數據來講話

30%抽象的邏輯分析
70%的科學數據

如何量化Sprint的目標達成率?

工程師一天到晚都在完成Task, 而忘記去看企業的目標(要想辦法讓工程師, 甚至全公司了解為何而戰)

訂三個Key Result,問工程師完成多少
OKR(Objectives and Key Results)
OKR 參考連結

0.75就算達成目標
如果目標是1
你永遠不知道1.1是啥狀況

場外感想 對於整數魔人應該差很多XD

(題外話參考) 以前有一種講法, 瞄準月亮就可以射到樹梢

衡量的目的是「減少」而不是「消除」不確定性
找最大的限制,把他極大化,然後解決它

可比較,簡單易懂,是比例,而最重要的,是要達成「改變行為」的目標

愛情如何衡量

所有看板應該要擺在一起
決策時才能看到全面的資訊

程式寫越多,你的load越大

設定產品週期,適時reset

數據崇拜的時代

定義指標 詮釋他

如果不能詮釋你的指標,丟掉它

要注意原本的目標


場外聊天室

麥克風聲音悶悶的

可能因為mic收音開太大,所以AMP 出來聲音也跟著不OK. 大會下次可以先檢查一下麥克風實際收音的情況, (就像演講者通常會先試試看投影片播放是否OK)

是否可以貼上影片連結?

Track B的直播畫面跟聲音非同步有點久

是很久特別是剛剛那段影片

簡報的圖片怎麼有辦法馬上弄上來? 好強阿
對啊, 想知道+1 (畫面好精美)
我就電腦截圖上傳而已啊
簡報連結講者放在第一頁了
↑好像是這邊:https://ruddyblog.wordpress.com/2018/09/07/

Select a repo