Retro 說了沒用？問題不是你說錯了，是你說法讓問題變得無法行動

Retro 說了沒用？問題不是你說錯了，是你說法讓問題變得無法行動 目錄 1. Retro 的話消失在空氣裡 2. 為什麼 Retro 的溝通跟平常不一樣 3. 讓問題無法行動的四種說法 4. 把問題說成可以行動的格式 5. 提行動項目的方式決定它會不會被執行 6. QA 在 Retro 的角色定位 Retro 的話消失在空氣裡 你說過「需求總是在 sprint 中途才改」。 大家點頭，PO 說會改善，記錄在白板上。 下一個 sprint，需求在第三天改了。沒有人提上次的白板。 你說過「測試時間不夠」。 大家也點頭，說會更早開始估。Retro 結束。 下一個 sprint，RD 在 sprint 最後一天才說「我的功能好了，可以測」。 這不是你說的東西沒人聽，是你說的方式讓問題變得沒有人有辦法處理。 為什麼 Retro 的溝通跟平常不一樣 Retro 不是 1:1、不是 slack 訊息、不是 bug 單。 它是一個有時間限制的會議，多個人在場，大家的注意力分散，每個人都有自己想說的事。 在這個環境裡，模糊的問題會讓所有人沉默——不是因為大家不關心，是因為沒有人知道該對模糊的問題做什麼。 「測試時間不夠」 是模糊的。誰要做什麼讓測試時間夠？沒有答案，所以沒有人行動。 「上週三個功能在 sprint 最後兩天才進 QA，我只有一天測三個」 是具體的。這個問題有主詞、有數字、有時間點，接下來可以問「為什麼這三個功能這麼晚？」，問題開始可以被處理。 Retro 的溝通要解決一個問題： 在有限時間裡，讓多個人對一個問題的認識達成一致，並且找到一個可以被執行的下一步 。 根據 Agile Alliance 的調查，大多數 Scrum 團隊定期舉行 Retrospective，但行動項目真正被追蹤到完成的比例出乎意料地低。Retro 不是沒有用，是大多數人的說話方式讓問題止步於討論，走不進行動。 這需要不一樣的說話方式。 讓問題無法行動的四種說法 1. 太抽象 「RD 和 QA 溝通不順暢。」 誰都看得出這不是一個可以行動的問題。但很多 retro 的白板上寫的就是這種東西。 抽象問題讓所有人覺得「對，這是問題」，然後下一個議題。 2. 只說感受，沒有事實 「我覺得這個 sprint 壓力很大。」 這是真實的，值得說出來，但它沒辦法被解決——因為沒有人知道壓力來自哪裡。 感受要有對應的事實才能被處理。 3. 指向特定的人 「XXX 的 PR 每次都在最後一天才送，害我來不及測。」 就算這是事實，Retro 不是評判的場合。這樣說會讓 XXX 防衛，讓其他人尷尬，讓討論從「怎麼解決」變成「誰對誰錯」。 4. 問題太大，找不到切入點 「我們的品質文化需要改變。」 改變文化是結果，不是行動。Retro 裡沒有人有辦法對這句話做什麼。 把問題說成可以行動的格式 一個可以在 retro 被處理的問題，通常有這些元素： 範例： | 原來的說法 | 改成可行動的格式 | | | | | 測試時間不夠 | 這個 sprint 有 4 個功能在最後 2 天進測試，其中 2 個我只測了 happy path | | 需求不清楚 | 登入頁面的需求在 sprint 第 4 天改了一次，改的範圍影響到我已經寫好的 3 個測試案例 | | 溝通不順暢 | 付款功能上線前一天我才知道有一個 API 改動，沒有時間更新測試 | | 環境一直不穩定 | 這個 sprint CI 失敗 9 次，我花了大概 3 小時確認是環境問題還是真的 bug | 同樣的問題，說法改了，就有可以接著問的問題，有可以追的根本原因。 提行動項目的方式決定它會不會被執行 Retro 最常死在這裡：有了好的問題分析，但行動項目寫完就死了。 行動項目死亡的三個原因： 沒有 owner ：「要改善 RD 和 QA 的溝通」——誰負責？下次沒人追。 太模糊 ：「RD 要更早告知 QA」——怎樣算早？ 1 天？3 天？沒有衡量方式，就沒有驗收標準。 沒有追蹤時間點 ：行動項目不是 sprint 結束就算了，下一個 retro 要 review 上一個 retro 的項目。 一個好的行動項目寫法： 範例： 具體、有人負責、可以驗收——這樣的行動項目才有機會被執行。 QA 在 Retro 的角色定位 QA 在 retro 的優勢是：你是整個 sprint 裡最跨功能的人。 RD 看到的是自己負責的功能，PM 看到的是需求和進度，QA 看到的是所有功能的整合狀況、測試覆蓋的漏洞、以及哪裡的流程讓測試工作變得更難。 這個視角在 retro 很有價值，但容易被浪費掉——如果 QA 說的東西太技術、太抽象、或者聽起來像是抱怨。 QA 在 retro 最有效的貢獻，是 把測試過程看到的流程問題，翻譯成對整個團隊有意義的資訊 。 不是「我測試很辛苦」，是「有這幾個地方讓我們的 delivery 效率下降了，原因是這樣，我認為可以這樣改」。 從抱怨變成分析，從感受變成資料，從問題變成提案——retro 才開始有用。 Retro 不是失靈了，是大多數人沒有人教過怎麼在這個場合說話。 說法對了，問題才能被看見，被看見才能被解決。 參考資料 1. Agile Alliance — Retrospectives ：https://www.agilealliance.org/glossary/heartbeatretro/ 2. Mountain Goat Software — Making Retrospective Action Items Actually Happen ：https://www.mountaingoatsoftware.com/blog/making retrospective action items actually happen 3. DORA — 2024 State of DevOps Report （心理安全感與持續改善文化）：https://dora.dev/research/2024/dora report/ 4. Martin Fowler — Software Development Antipatterns ：https://martinfowler.com/articles/antipatterns.html 5. Scrum.org — What is a Sprint Retrospective? ：https://www.scrum.org/resources/what is a sprint retrospective