今天打開收件閘，發現魯迪老師有貼了新文章，立馬轉貼上來給大家：
軟體開發的復盤 - RUDDYLLEE

在這篇文章裡，魯迪老師先提了復盤的意義：「重來一次可以學得最多」

接著馬上就進入第一個復盤的情境：Code Review

程式碼審核 (Code review) 是程式復盤的基石

程式碼在開發作業中的 code review 行為是團隊復盤的第一個情境，程式撰寫人應該負起說明程式碼情境的責任 (對程碼做標題說明 WHY? 解決了甚麼需求的問題)

審核人員則應該針對解決問題的方法給予回饋，以提出”如果 …會怎樣”就是what if 的提問方式來做回答，目的在造成當事人的反思，這樣做或許可以促成當事人想到更好的解題方案，或是避免掉將來可能產生的缺陷中。

在必要時進行面對面的溝通，對學習更有幫助，形成教學相長。

Code Review 讓團隊可以協作，並且分享彼此的知識，讓團隊學到更多。

第二個情境則是復盤需求：

復盤的第二個情境是針對需求的復盤。

由於需求的來源是針對使用者的操作情境而來，它的排序方式是以協助使用者順利完成任務為出發點。而程式設計人員則是以整個專案開發的技術範疇為主，它思考的是盲點與疑惑…（中略）

無論是疑惑或是盲點，都是程式設計人員依據需求的陳述和自己所擁有的經驗、技能進行評估後所產生的概念，中間難免會做了許多的假設，這一點；就好比對弈時猜測對方為什麼會下這步棋時的動機一般，需要事後印證來學得正確的經驗。

復盤可以讓我們學到最多。當然針對核心部分的 MVP 開發作業的驗證，也是很值得復盤以充分學習了解的地方。

這段看起來有點像是需求完成後，回頭找出認知落差再校準，藉此累積經驗的感覺

例如我們可能誤以為這個功能應該就是長得像Ａ，結果來來回回老半天才發現客戶是要Ｂ，下次我們就知道還有Ｂ這個可能性

這篇有個我覺得蠻重要的概念：檢討的目的是不再犯相同的錯，而復盤的目的是找出更適合的解決方法、從錯誤中學習。兩者並不相同

檢討跟復盤之間很常會發生誤解，有時候我們會在寶貴的學習機會前忙著找戰犯，這樣就浪費了（特別把這個概念寫出來，也算是提醒我自己吧）

那麼，今天的轉貼就到這邊。明天見～