# 人工智能驅動下的開發者體驗 -實務篇 - Ruddy Lee 李智樺
42年的 programmer

{%hackmd @DevOpsDay/BJXaW1_k6 %}

> 從這裡開始寫

## 前言

- 每個禮拜 Review 一次，你就滿意了嗎？
- 漏掉一行 code，你要等一個禮拜才能改
- 客戶可能會罵七天 (每週 Release 一次，痛苦七天)
- 客戶打電話問，什麼時候會改好？
- 最難的是：開發環境跟測試環境一模一樣
- 影響 Release 的次數是『公司的文化』
- 不能 Release 很痛苦

影響 Release 的速度是什麼？ 是公司的文化！

- 今天會把重點放在開發者體驗
- AI 時代來臨，你突然同時擁有全世界的知識，你要做什麼？如果你還沒有思考這個問題，一定要花時間思考

疫情三年之間改變了什麼：有人工智慧等同擁有全世界那要做什麼？這才是重點
花時間思考可以幫助入夢

- Gartner 發佈新興技術曲線圖
- Gartner 2023 年 7 月發布 DevX

>Gartner 的 Hype Cycle 報告:
Hype Cycle for Emerging Technologies, 2023

## Gartner 提出2023年新興技術趨勢的四個主題：
* 新興人工智慧 Emergent AI
* 開發人員體驗 DevX
* 原生雲端
* 以人為中心的安全和隱私

疫情前花了三年寫一本書《開發者體驗》

- 看起來是我的 Bug，但明明是元件的問題，工程師天天都在痛
- DevOps 一定要合在一起
- 給開發者一個使用平台，讓開發者專注做自己的事

- Internal developer platform, IDP
- 讓開發者專注開發的事情上
- 解決開發者的開發痛苦，並且讓品質又穩定
- 減少認知負荷

- ChatGPT 出來時，大家的反應是什麼
- CEO 打電話給理事會，希望大力投資
- 董事會要求 CEO，CEO 要求 CIO，由上而下的壓力

- ChatGPT 對我的產品有什麼用？

### 新興人工智慧 Emergent AI

### 開發人員體驗 (Devloper Experience, DevX)

> 指開發者與執行軟體產品服務相關的工具、平台、流程和人員之間的所有互動。

- 寫程式給別人用，就是要得到回饋
- 一年寫一百個功能，有些功能從來不用，那就白做了，工程師自己埋點自己看，你寫多少程式，就會揹多少東西在背後
- Release 快，刪掉東西不害怕，頂多就再弄回來
- Devops 詢問開發者你需要什麼？你的痛點是什麼？
- 解決 DevX 最好的方法就是有好的 mentor
- 開發者體驗就是學習，從新手到專家

- AI 擴增軟體工程、以 API 為中心的軟體及服務 SaaS
- 用於操作和管理軟體系統的一套準則(GitOps)
- **內部開發者入口網**(Internal developer portals/platform 建立開發者門戶的平台)
- 開源計畫辦公室 open-source program office
- 價值流管理平台 value stream management platforms

- 開發者體驗即平台
- 一個設計，運行優秀的平台應該以客戶為導向，就是用戶驅動的平台
- 開發者體驗及導師制
- 導師制是一個師生共同付出與獲得的發現過程
- 開發者體驗及學習
- 面對學習，正視學習架構團隊學習機制
- 強化開發者社交平台

- 理念
- 開發者體驗即學習
- 你不知道你不知道些什麼，你從來沒有做過，請你估算時間，怎麼辦？你講不出來
- 第一個你要讓自己有概念，你就可以大概說出來
- 估算只是概念，不要相信他
- 有把握什麼時候可以寫出來的時候，估錯的話，了不起加班熬夜把功能做到
- 要想辦法讓自己從新手，迅速到專家
- 問 ChatGPT 要怎麼做啊？但是不要相信他
- 你記不住所有的東西的，你回去想要講給你的朋友聽，你只能記住百分之三十，做筆記，不要囤積知識，擺在你會經過的路上，寫一個 Email 寄給自己，你會看 Email，所以就是你會經過的路上，當然你可以做分類，歸納知識
- 擺在會經過的地方上

- 實作
- 開發者體驗即平台->團隊共享
- 如使用 ChatGPT，你使用的是私有 ChatGPT 還是團隊共有 ChatGPT ？
- 你知道團隊問了哪些問題嗎？｜團隊學習
- AI 來的時候，就是一種團隊學習，大家今天的知識就是這些，讓大家擁有相同的知識

敏捷開發： 小增量、多迭代與尋求回饋

* 差距彌補法: 新手迅速到專家->學習
* 提升自學效率
* 數位化第二大腦:
* 數位化記筆記，但是不要囤積知識
* 擺在會看到的地方 (例如 email寄給自己)
* Wiki
* Git(喵)
* 知識庫
* 協作服務引導
* 團隊學習，克服係慣性拒絕
* 團隊其他人都在學習什麼
* 共享團隊知識 讓隱形的知識消失
開版方法： 克服限制 TOC

- 共享學習
- 柯氏評估模式，導師制
- 新人要學會的第一件事情是，如何問問題
- 內部開發者入口網
- 整理出所有新人問的問題
- 解決團隊技術性的問題

Thinning Viable Platform：必須很薄，但是可以解決新人的問題
建立滿足需求的平台即可：小增量、多迭代與尋求回饋 - 敏捷


### 看見全貌

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

- 如果你很快地進入重點，就看不到全貌，你要後退，才能夠更清楚一點(有時可能要退很多步)，你還需要自己做下去嗎？要投資嗎？要能夠問很多問題，才能夠摸索全貌
- 要知道自己在哪裡，以終為始
- 犯錯的機率就會下降
- 確認自己在哪裡，還有多遠？
- 看完全貌後：我在哪裡？
- 探索真正的問題

講師會把 PPT Release , 建議用 WPS app 來看
- 可以寫註解

講師例子：
- 收到中國邀請到對面授課，但教育部說你要留一手：完全違反師道

### 原生雲端(普及式雲端)

### 以人為中心的安全和隱私

### 開發者體驗 (Developer eXperience, DevX) 的定義

- 狹義定義
- 開發者使用你 API 的感覺，所以是個人的、感性的。
- API 是定義應用程式，服務和元件如何通信的契約。
- 廣義定義
- 寫程式一定要有人回饋，如果沒有回饋，損失慘重
- 視開發者為End user 將工作過程的技術協作與團隊協作看作產品與服務
- 關注 developer 在開發中的感知與反應;致力於消除這些產品與服務所帶來的摩擦力進而能夠快速交付價值並獲得反饋
- 如果 UX 很順暢，只要自己學會 20 %，80 % 自然達成

### 為什麼要關注 DevX ?

- 你看到問題，學習的機會就來了
- 你覺得你們團隊的開發速度好嗎？
- 你要如何加快團隊開發的速度？
- 為什麼效能這麼慢？找出問題在哪裡
- 專案的日期被壓死了，開發團隊來不及做完，你會怎麼辦？
- 找 PO 重新把需求估一下，哪裡卡關？你可能會這麼想
- Ruddy 老師怎麼做 => 砍需求
- **千萬不要損失品質**，反撲的成本遠高於準時交付的成本
- 需求少做減少工作量？
- 減少額外的認知負荷(因時程而造成的壓力)
- 把工程師全部趕進房間，讓他們不受干擾，原本三點半可能要去喝珍珠奶茶、最好加個雞排， 不可以！
- 上廁所是 Debug 最重要的工作！！！！！每次上廁所都做一次反思，你剛剛做的問題，卡在哪裡，如果你用不同角度去做，能不能夠客觀冷靜觀察自己的行為，所以咖啡、可樂很重要，因為他們是利尿劑，你會自然地去上廁所，但，啤酒不行喔！
- 工作之餘應該有個喘息時段：冷靜、反思、休息
- 檸檬不錯，咖啡可樂很重要 都是利尿劑
- 在面對一堆需求時，畫一條線，團隊溝通要做幾成，以及哪些是特別重要的需求，挪到線的另一端
- 達成共識：這次我們只做八成還是九成，不要讓需求超過那條線，畫一條需求的水平線，如果這需求真的很重要，就把功能頂上去啊，把其他功能移下去

### UX 之於 DevX

如同於 UX, DevX 是專注於優化 開發者的體驗，解決程式開發人員的痛苦

公司角度： 改善團隊開發速度
個人角度： 由認知負荷的角度看開發者效能

如何加快團隊的開發速度
請他人來看來發現問題

你罵我，我就改善。
寫程式就是要回饋啊！

### 降低工程師的負荷

- 固有認知負荷
- 與問題領域的基本任務相關
- 開發者的基本功不夠落實
- 額外認知負荷
- 與處理的環境相關
- 浪費和非增值的活動
- 相關認知負荷
- 老師為了讓你學更多東西，所以給你很多習題，讓你理解

==專注！！==
記得保留空間給認知負荷！

### 解決團隊開發速度的解決之道：

- Speed Model
- Software Development Speed Model
- 關注工程師的負荷
- 調整組織結構 Team Topologies
- Team Topologies 描述了 **團隊結構** 和 **交互模式** 相關的組織模型 (拓樸)
- 依照功能區分四種
- 業務流程對齊式團隊 Stream aligned
- 複雜子系統團隊
- 平台團隊
- 賦能團隊
- 依據一、康威定律 | 依據二、鄧巴數
- 反康威定律
- 鄧巴數
- 讓你的團隊保持強
mathew skelton/manuel pais

### 基本團隊拓樸的團隊交互模式

考量點：**業務**、**技術**、**組織**

#### 三種團隊交互模式

- 協作
- 成本最高
- 與其他團隊合作
- 服務（開API）
- 成本介於中間
- 提供某種服務
- 引導
- 成本最低
- 為團隊尋求幫助以清除障礙

> 拆書會：幾場演講 心得分享
每個人自己報告，把心得跟團隊分享

- 綠色：工程師最需要的『專注』！！！！
- 黃色：技術債

"五年以上離職都該算是公司的損失"

### 參考書籍

[高效能團隊模式：支持軟件快速交付的組織架構 (Team Topologies: Organizing Business and Technology Teams for Fast Flow) | 天瓏網路書店](https://www.tenlong.com.tw/products/9787121410826)

### DevX 即平台

- Internal developer portals/platform
- 以平台設計的方式，減輕開發團隊的「額外認知負荷」
- 內部開發人員平台 IDP 兼具以上兩者
- 團隊累積下來的知識，把它寫出來
- 團隊之間有知識的篩漏，需要建立一個平台去解決它

### 了解工程師的負荷

### 開發速度起不來?

- 基礎沒做好：把基礎穩紮穩打的做好
- 每個團隊都不一樣，大部分的情形都是開發者沒有落實他的基本動作，工程師能不能夠很踏實的做自己的工作，自然所有的問題都會減少

### 開發速度跟開發團隊的認知負荷 (關於組織變革的成功要素)

- 他們覺得很興奮？還是很疲倦？
- 透過成就感、感覺學到東西都不疲倦
- 覺得有學到東西還是沒學到東西

### 團隊開發速度的考慮

- 因為軟體是複雜的，拿手或不拿手，速度就顯現出來
- 一個月三個月一個月
- 目標式學習：
- Intervals : 1快節奏衝刺 3馬拉松式 1快節奏衝刺，平均速度高於 Intervals 區間式
快12hr-中10hr-慢6hr

- 擬定軟體開發側略
痛點先行 pain point first-

- 開發流程是不是更自動化
- 選擇業界最佳實踐

哪種學比較多？
mentor 的好處是雖然在教的時候會花時間，但是當導師回來做自己的事時專注力會大幅提升，勝過他原本的效率

---

## 聊天室：

笑死，先開聊天室
老闆問說，是不是可以不需要客服人員了
> 有 AI 是不是也需要要工程師惹 [name=Kehao]

> 真的好想花看看20美 現在的 （很笨

20美請一位junior他不香嗎

不會壞就不要動 ＸＤ

估算未知的時間，我先丟出這張牌結束這回合

雞排真香
？？？
肥宅快樂水！

是不是有買KO股票來推廣的!
可樂喝太多了吧....
上廁所可以debug???
需要利尿一率推薦薏仁水&西瓜汁

喝太多可樂真的不好啦....
一天喝8罐可樂，很快糖尿病吧....

> 請 iThome 工作人員在會場多擺幾箱可樂

手機要兩階段認證呀！！！

感謝工作人員 52
快點hot fix

飲料店決定不跟91app合作

**以下開放養身話題：**

好想上廁所 ==
不要憋 會血尿

上廁所真的有用，會突然靈光一動

1. 上廁所
2. 洗澡
3. 騎車 (Ruddy 老師都是騎單車)

所以公司也要設置浴室才對

喝咖啡太多 現在想上廁所
咖啡也利尿
喝咖啡也要記得喝水喔，我的mentor只喝咖啡，去年急診去醫院了。
利尿劑真的不能當水喝...
喝咖啡要喝兩倍的水，這是過來人的建議 e.g. 喝300cc 咖啡 水要double 600cc
conding前飲水 600CC 喝水!
推薦下載喝水提醒 app，好用
人體吸收水分是有速率的，大概半小時200cc，超過就浪費（尿）掉

可惜了,後面想繼續聽

有人知道簡報網址嗎？拜託好心人分享，謝謝
+1
+2
+3
有跟主場確認，只要講者同意，之後會上傳到官網
→官網連結 https://devopsdays.tw/2023/session-page/2274