O
# 復盤： 將經驗轉化成能力 - 李智樺 (Ruddy 老師)

{%hackmd @DevOpsDay/B1cnefOI0 %}

### 》[議程介紹](https://devopsdays.tw/2024/speaker-page/120)

### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/4W53Dv88R93uMhWN8)

### 》[投影片 (建議使用無痕模式開啟)](https://onedrive.live.com/?authkey=%21ANl4Fcm7LApfZoc&id=68B24674607C69D9%21357987&cid=68B24674607C69D9)

> 共筆從這開始

# <div style="color:yellow;">生日快樂</div>

- 做一件事情最重要的事情是專注，進入心流是非常重要的
- 我很喜歡共筆但我希望你把筆電放下來用記憶寫共筆，就可以思考兩次

> 今天生日的請舉手(X) 可以拿禮物啦！
> 舉手就可以拿禮物啦，六份紀念品啦

經驗是不會自己變成能力。做了筆記之後你有覆盤嗎？專案結束之後不會自動變成能力，你要自己去挖掘
你有覆盤嗎？

覆盤最重要的是學習跟改變習慣。對方下一盤棋你馬上就會應對思考，你會落入陷阱跟習慣，習慣的pattern是很糟糕的。

復盤的目的重擺一次棋盤，然後改變習慣。

改變習慣到底有多難？你若是開會都帶筆電進去你怎麼解決問題？怎樣專注開會？
但你習慣就是要進去開會，就是要把電腦打開要記錄，對programmer而言，code review。但 code 不會像棋盤一樣擺一擺就結束，你需要review來改變你的不良習慣，所以復盤是真正重要。

- 復盤+：把經驗轉化為能力
- 復盤：對過去的事情做思維演練

## 何謂復盤？

如果你的孩子想當 programmer 你要怎樣教育他？
復盤，教會他應對。

- 一炷香反思
曾國藩，若一炷香燒起來你被燻得受不了的時候，你就會下決定的。
- 聯想三大方法論
- 目的性
- 分階段實施
- 復盤
- AAR (After Action Review) 行動後評估被評價為最成功的組織學習之一
- 行動後評估（對組織最有幫助）
- 回顧目標
- 評估結果
- 分析原因
- 總結經驗
- 持續改善，這也就是CI/CD的精隨
- 最精彩的地方
- 寫下案例，不要犯同樣的錯誤
- 復盤是圍棋選手增長棋力最好方法
有能力復盤的人記憶力都好，不是要記得每一個子，要去記得一個區間，因為復盤可能是十個十一個棋子在跳

前面的二十是分鐘，一場對弈有 20 分鐘可以思考，前面20分鐘是計時的，後面20在20秒裡面下，超過就被機器判定失敗。所以是20/20。

在專案開始之初，首重看見全貌
- 認知問題
- 訊息 > 邏輯 > 假設
- 我在哪裡

## 離開會場的時候，要記得一件事情，你要改變什麼？

## 工程師的交流活動

## 軟體開發的復盤時機
你遇到盲點的時候，你遇到疑惑的時候。

- 團隊復盤 code review
- 針對需求開發優先序的復盤
- 先解決最重要的問題
- 把盲點跟疑惑和 PO 討論，提出來，改變需求
- 知道自己在做什麼事情很重要
- 一定要做紀錄
- 沒有做紀錄，一個月之後，才能夠有所依據

## 復盤的結構化思維

提示工程有用嗎(promt engineer)，你每次問你知道你問的有幾分嗎？你問的方法有改善嗎？因為沒有回饋你不知道你問的好不好，不知道差異也不知道有沒有學習。
但你得到很多知識，但你問問題的品質還是沒變。

如果重做一次要從哪裡開始？
大部分人都會說一半時間我就可以做完，但你這樣不就會做一樣的方式，沒有改變啊。
若要改變第二次做要比第一次做要有更多的時間。

- 探究規律就是結構化思維，學習並改變習慣
- 回顧
- 反思
- 探究
- 提升

- 方法
- MECE 原則
- 把大問題切成小問題
- 互相不相關，獨立
- 小問題盡可能完備
- 邏輯樹
- 請 AI 討論完之後，把結論畫成邏輯樹
- 延伸下去，結果自然就會好
- 頭腦風暴
- 流程圖
- 歸因分析 RCA

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

- 認知問題
- 訊息
- 邏輯
- 假設
- 我在哪裡

你都按照PO的需求去做，都按照顧客行為去做，不是讓你照著 coding。

第一事情解決盲點跟疑惑。

跟 PO 討論產品的核心、盲點，雙方討論需求。

你若是照做不誤，你是一個忠厚老實的工程師。

跟團隊做討論，有疑惑就討論，第二天站立會議就可以拿出來就討論。

一定要做紀錄，如果沒有做紀錄一個月以後你就看不出來code是誰寫的，罵完別人就才發現原來是自己寫的，一定要留下紀錄，code review才有效。
code review就應該改變習慣，習慣就要去改變。

探究規律是另外一種習慣，你用哪種 pattern 去做這事情，改變這種 pattern。學習並去改變習慣。好處在這裡，提升問題跟解決能力。之後解決問題的能力就可以增加了。

你留下紀錄老師在說這段的時段引起你思考什麼東西，你就會加強你的思維，你就可以盡可能留下訊號，記憶力變強，但實際是是因為專注力變強。

與其說「批判性」，不如說「假設」思維
Programmer 最重要的是專注力。

我會請chatgpt把我們最後會談的東西化成邏輯樹，你就可以很清晰的看到這點，這樣就可以了解你的提示工程狀況。每次問完問題就會知道你每次問的狀況。ai最喜歡就是結構化。

這樣的思維模式可以讓人變聰明，不夠聰明會讓你看起來很聰明。復盤可以讓你聰明應對。

復盤要做紀錄，復盤

## 復盤跟SBI

SBI一定要做。
- situation
- Behaviour
- Impact

## 開發者一天的工作
早上開會
開完會之後看你缺了什麼
一點之後code review
兩點到三點coding
後來又有會議
最後又有bug要修
最後就是加班趕工

## 你一天做了哪些重要又不緊急的事

緊急的事情馬上去做，有截止日期的就去做。
老闆有deadline你就恨得牙癢癢的。
但日期應該誰定？你自己定！
若不定截止日期就會跟暑假作業一模一樣。
若不定日期你就會開學前一天才做，找兄弟姐妹一起來做。

- 什麼時候做重要不緊急的事情，一天天這樣過你什麼時候會去做呢？
- 團隊的事
- 計畫與補救
- 建立和合作關係
- 新機運
- 個人發展

最勇敢的是開始 coding 的時候，把手機關掉，進入心流狀況。
工作狀況進入心流模式也可以活的很健康。

一天可以做多少事很明顯，要把開始跟最後的事情定好，持續改善。
養成好的習慣早上就做，晚上回去要做什麼，把你勞動的效能盡量提升。
可以復盤一天，要去思考，讓你的效能盡量提升
你有排序過你自己一天的工作嗎？
優先處理：code review，因為 code review 是一整個團隊的事

當你看不到系統的全貌的時候，你有疑惑，系統變動太快。

要保持一種態度，少增量 多迭代 持續回饋

復盤跟 testing 的關係
codereview要怎樣做？可以看google code review pattern
~~微軟相對就不嚴謹~~

- 找出問題
- 提高品質
- 綜合檢查

回顧只是一個開始，要反思，反思之後搞不好可以重做。

越早開發成本會是越低。上線之後要花六百四十倍的力氣才能還原。
越晚復盤，花費的成本越高
先解盲點、再解疑惑

### 需求決定開發的效能

programmer 首先設計自己的開發過程

盲點跟疑惑解決之後再去談核心。programmer 不用太快去coding，按照你的順序去做，但PO是按照使用者的不是你的。要先解掉你的疑惑然後才去進入。

### Code review

不犯同樣的錯誤

## 工程師的交流活動- code review

- 解決兩個問題，提升品質
- coding style
- 程式碼的行為
- SRP（Single Responsibility Principle)
- 解決程式的複雜性
- 單一職責降低複雜性，可讀性增加
- code review 的抉擇
多長的 code review 是好的。
> 不超過三頁。

如果你要教會你孩子coding的話不要超過兩頁，若要通通重寫的話乾脆你自己寫好了。

若是親人每天晚上就看一下，理解一下有什麼問題。不要偷懶，因為明天就兩倍，連假就是三倍四倍五倍，根本看不理解看不清楚。你就會要他重寫，那你乾脆自己寫好了

越短的code review幫助越大。
而且會增長他的自律

番茄工作法
最重要的是做緊急且重要的事情
專注讓你的記憶力加強，復盤的時候專注的去復盤，要去排序工作，排序好比什麼都有效。
寫下來我今天要達成什麼，中午看一下還來得及去做，下班看一下今天做了什麼。

### 重點是提問、燈號

- 狀態
- Good
- 沒把握
- Need help

- 多長的 code 你可以發揮全力做好 review ?
- code review不超過四頁，一頁30行，超過就退回去。你超過根本看不完，coding style跟解決的問題一起列出來一起討論啊。你coding沒有跟你討論，你怎麼會知道你隱藏了多少bug，你一定要找人code reivew跟墊背（ＸＤ）啊。這就是團隊協作的真諦啊。

- 復盤：清楚疑慮並產生創意
- 問題比答案更有價值

- why
- ~~列出一個有多層結構下目錄裡的所有檔案~~（這個說法不好）
- 為了找出裝置記憶卡內的所有檔案（改成這個）

- what if
- 運用遞迴呼叫的方法可能導致效能上的不足

- how
- 同樣是運用堆疊，是否考慮由自己處裡堆疊的方式，會快一些

以前我們寫程式都不敢給別人看，你一定要找人墊背啊，找人code review。我們以前有同事都喜歡三更半夜把code寫完，但要跟人分享，越多人看你才會寫得越清楚。
code review ，120行做一次，請別人來看，一起討論。

### 工程師復盤的時機

回顧會議之前要做code review，不是回顧會議之後。才會對你有幫助。
專案結束之後要做復盤，但你沒有辦法擁有重做的可能，只能事後進中紀錄。

每個scrum都要做，那是最好的時間點，不要寫一千行才給人看，那是最糟糕的事情。

經過討論以後，
留下足跡你才能在夠小的區間討論。
標示 1 2 3 4 很重要

### 復盤的關鍵要素

復盤的關鍵要素是因為你親身經歷過，你看別人復盤的結果不是你自己復盤，那不叫做復盤，叫做

復盤不是總結，是學習，是可以客觀思考。你可以推敲你已經贏了還是輸了，希望從中間學到最多。

### 對復盤的誤解

回顧會議是復盤嗎？

只是復盤的開始，接下來要往後走

一定要走到提出疑問的解方，互相討論。

復盤是一種問題分析跟解決分法。大部分都要超越問題分析也要分段落，可以指定問對方為什麼這樣做？
復盤是一個區間不是一兩顆棋子。

### 復盤是基於假設思維
通常我們假設都是自己的事。
你覺得作法應該要改變，不是事實證明要改，你必須不斷檢討自己。

### 專案重做怎樣有最好的效能？

專案有沒有重做的機會？
你一定要做一件思維。

你必需不斷復盤檢討自己哪裡做錯你才可能變好。你不復盤你怎麼知道你自己做對還是錯，中間的關鍵是什麼？

復盤若回顧的時候可以睡著就太幸福了，有時候太心驚膽跳，都會疑慮自己要不要做。

先找影響最大的原因是什麼，然後去好好改善。通常你以為最大的原因都不是最大的原因，你應該去問你的同事、問老闆。但大家答案都不一樣怎樣知道最大的原因呢？
所以你要看清事情的全貌。去找到最大的限制點跟POC去解決它，一定要改善最大的限制點，你以為你改善很多了你還是覺得為什麼是這樣呢？

因為你沒有找到最大的問題去解答。再來才是去找到MVP去解答。

### 比復盤學到更多

多作復盤，不犯一樣的錯誤，知行合一。

運用檢驗PR時進行復盤。

復盤的時候找到有價值的地方，回顧會議上先做復盤，找到真正的key point。
四頁120行一定要做復盤，超過重寫就不看。
復盤的優先順序要第一啊，不能讓整個團隊等在哪裡，第二天第三天成本太高，必須立刻解決。

## Q&A

---
### 閒聊區👋

<div style="color:yellow">🎂 Happy Birthday！</div>
🎂🎂
🎂🎂🎂
🎂🎂🎂🎂
🎂🎂🎂🎂🎂
🎂🎂🎂🎂🎂🎂
❤️ Ruddy 老師 生日快樂！ ❤️
Ruddy老師生日快樂<3

**66 大順**

Ruddy 老師指定肥宅快樂

> 是不是我太晚來了，不然怎麼都沒快樂水可以喝
> ~~去I棟拿~~
> A2 空了

Ruddy 老師生日快樂🎉

Ruddy 老師生日快樂

Ruddy 老師生日快樂
謝謝筆記天使ANNA

Re:Zero 算不算複盤的最佳代言輕小說
算！
只是越復盤越慘...

###### tags: `DevOpsDays Taipei 2024`