第十章:流程改善 (Process Improvement)#

Since it is people who manufacture things, manufacturing is impossible unless people are developed. — Toyota Technology Museum, Nagoya

本章探討看板的核心目的——持續改善 (continuous improvement),以及支撐改善的根基——尊重人 (respect for people)。這兩者被稱為 Toyota Way 管理系統的兩大支柱。

在精實組織中,改善的心態深植於組織的每一個層級,從 CEO 到基層員工,每個人都有追求更好、更有效的渴望。正是對人的尊重——尊重、培養、鼓勵組織中的每一個人——使這一切成為可能。

看板植根於精實思維,其本質就是持續改善與尊重人。視覺化工作是一種簡單但有效的方式,能促進自組織的改善工作。限制 WIP 和幫助工作流動,能讓瓶頸和改善機會對團隊可見,讓成員自行想出改善方法。

然而,看板不會自動幫你解決問題,也不會自動改善任何事情。看板只是揭露改善的機會,如何改善仍取決於你自己。本章介紹三種實用的改善實踐:

  • 回顧會議 (Retrospectives) — 團隊定期反思流程
  • 根因分析 (Root-cause Analysis) — 找出問題的真正原因
  • Kanban Kata — 透過預定義的問題與形式持續改善

10.1 回顧會議 (Retrospectives)#

回顧會議是大多數敏捷方法中的重要實踐。敏捷原則之一明確指出:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

在回顧會議中,團隊分析上一個期間的流程與進展,並嘗試找出可以改善的領域。

如果想深入了解回顧會議的各種執行方式,作者推薦兩本書:

  • Esther Derby 與 Diana Larsen 的 Agile Retrospectives
  • Patrick Kua 的 The Retrospective Handbook

10.1.1 什麼是回顧會議?#

團隊回顧會議應在固定間隔舉行,傾向於更頻繁而非過少。典型的團隊會每一到四週安排幾小時進行回顧。這可以視為團隊投入時間來改善合作方式。

回顧會議的目標是產出少量的改善行動(最好不超過三項),這些行動要能在下一次回顧之前完成。這確保團隊只承擔可以處理的改善工作量——頻繁地做小改善(還記得「限制你的 WIP」嗎?)。

回顧會議通常由五個部分組成:

  1. 設定場景 (Set the stage) — 啟動回顧會議並設定氛圍。一個好方法是向所有人介紹「回顧會議首要指令」(Retrospective Prime Directive):

    Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

  2. 蒐集資料 (Gather data) — 團隊回顧上一個期間,蒐集關於發生了什麼事的資料。不同的練習可能聚焦於不同的事件、情緒或進展。

  3. 產生洞察 (Generate insights) — 分析蒐集到的資料,看看能得出什麼結論。為什麼事情會這樣發展?例如可以使用根因分析。

  4. 決定行動 (Decide what to do) — 找出一組合適的行動,確保能在下次回顧之前完成。通常選擇較少的行動比較多的好;太多行動有可能最後都無法完成。有時候回顧會議可能不會產出具體行動——也許團隊在會議中就解決了問題,或者他們只是需要好好談一談。

  5. 結束回顧 (Close the retrospective) — 好的做法是對回顧會議本身進行一次迷你回顧,可以簡單地問大家對這次回顧的想法及如何改善。

flowchart LR
A[設定場景] --> B[蒐集資料]
B --> C[產生洞察]
C --> D[決定行動]
D --> E[結束回顧]

建議為會議設定時間限制(例如一小時),並為回顧的各個部分也設定時間限制,以保持專注。至少為「決定行動」部分留出 25% 的時間(一小時中至少 15 分鐘),因為這通常是最重要且最具成效的討論。

10.1.2 如何執行?#

上述的大綱相當通用。實際上有許多不同的方式可以執行回顧,作者建議混合不同的方法以保持團隊的警覺性,避免回顧變得無聊。

邀請其他團隊的人來協助引導你的回顧會議,這能帶來新鮮的運作方式。不涉入團隊的人可以保持中立,專注於引導而不感到需要參與。

一個基本回顧的執行步驟:

設定場景:

  1. 展示或朗讀回顧首要指令,詢問與會者是否同意遵守。若非所有人同意,應強調回顧的目標是找到改善點,而非責怪遊戲。
  2. 蒐集資料:請團隊寫下上次回顧以來所有的好事
    • 每件事寫在一張獨立的便利貼上
    • 給予三到四分鐘(使用計時器)進行腦力激盪,完成後將便利貼貼到白板上
  3. 重複同樣的動作,但這次寫下想要改善的事情。提醒團隊:我們不是要找出「壞人」,而是要發現尚未意識到的改善機會。
  4. 請團隊對相似的想法進行分組以識別共同主題。可以讓他們在沉默中進行——這能帶出不同的群組動態,且通常相當迅速。
  5. 再做一次,但這次聚焦於理想的未來:「如果你有一根魔杖,可以做任何事——下次回顧時你的狀況會是什麼樣子?」

產生洞察與決定行動:

  1. 此時應該有很多好事的想法以及團隊可以改善或想嘗試的領域,這是討論的良好基礎。
  2. 請團隊投票選出一到三件在下一個期間想要改變的事項。
  3. 幫助團隊聚焦於有機會在下一個期間實施且有具體成果的事項。可以問:「你怎麼知道這件事完成了?」使用 SMART 目標(Specific, Measurable, Attainable, Relevant, Time-bound)是另一個好做法。

結束回顧:

  • 請團隊用「五指拳」(Fist of Five) 投票——數到三,每人舉起對應評分的手指數(1 最差,5 最好)
  • 請他們寫下一件在下次回顧前可以改善的事,離開時貼在門上
  • 感謝大家的參與

讓每個人在會議開始時說些什麼,即使只是一個字如「是」或「否」。研究顯示,如果某人在會議開始時發言了,他們在會議後續再次發言的機率會高得多。例如,繞一圈問:「你同意回顧首要指令嗎?」

何時應該執行回顧?#

對於迭代式方法(如 Scrum),回顧自然在 Sprint 或迭代結束時進行。許多使用看板的團隊採用基於流程的方式,流程中沒有「迭代結束」的概念。

建議的做法是為團隊決定一個合適的節奏 (cadence)。例如每兩週進行一次回顧,並將其限定在一小時內。隨著團隊對回顧越來越熟悉,可以實驗什麼樣的節奏最適合。

回顧會議的核心要點:

  • 從流程中學習以改善流程
  • 遵循五個步驟:設定場景、蒐集資料、產生洞察、決定行動、結束回顧
  • 偏好頻繁的小改善,而非罕見的大改善

10.2 根因分析 (Root-Cause Analysis)#

想像你的團隊最近出現了大量的 Bug。你有指標顯示趨勢明確:缺陷數量上升,整體前置時間 (lead time) 大幅增加。團隊決定要對這個趨勢採取行動——他們希望減少缺陷並縮短前置時間。

但要怎麼做?從哪裡開始?問題到底是什麼?該告訴開發人員好好表現?規格品質變差了?測試人員不夠警覺?需要更多測試人員?

根因分析是一種結構化的方法,用以深入推理問題,找到問題的真正底層原因。重點在於:如果只修復症狀而不尋找根本原因,同樣的或類似的症狀遲早會在其他地方重新出現。你要修復的是真正的問題,確保它不再發生。

根因分析與「五個為什麼」(Five Whys) 基於相同的思維——不斷地問「為什麼?」直到觸及問題的根本原因。有趣的是,團隊通常在五個「為什麼?」之後就能找到真正的問題,因此得名。

10.2.1 如何運作#

根因分析可用於解決各種層級的問題。你可以透過簡單的問答找到根因(五個為什麼),或者對於更複雜的問題,舉辦一場工作坊。

舉辦工作坊的建議:

  • 邀請所有你認為可能幫助找到根因的人
  • 設定時間限制以聚焦重要問題
  • 決定工作坊的開始與結束時間
  • 告訴所有與會者工作坊的目標是找到問題的根因

為什麼我們需要修復這個問題?#

根因分析的第一部分是找出不修復問題的後果,以深入理解為何修復此問題很重要。

步驟:

  1. 將問題寫在便利貼上,貼在白板中間
  2. 從「問題便利貼」開始,問「So what?」(那又怎樣?)來產生想法
  3. 將每個新想法貼在白板上,繼續向上推演直到「So what?」的問題不再有意義
  4. 你可能會產生幾個不同的路徑或分支,追蹤每個分支繼續問「So what?」
  5. 畫線和箭頭來指示便利貼之間的關聯

Figure 10.1: Building a root cause analysis with Five Whys

範例對話——向上推演後果:

團隊從「我們有很多 Bug」這個問題出發:

  • 「那又怎樣?」 → 佔用了開發新功能的時間;產品形象變差
  • 「產品形象差,那又怎樣?」 → 可能失去使用者;NPS(淨推薦值)下降
  • 「NPS 下降,那又怎樣?」 → 這是投資者關注的指標;投資者也關心用戶數
  • 「讓投資者不滿,那又怎樣?」 → 他們可能削減投資,最終停止產品開發
  • 「佔用新功能開發時間,那又怎樣?」 → 無法建構新功能 → 失去使用者;競爭對手有機會追上

Figure 10.2: Root cause analysis with consequences and feedback loops

如此一來,團隊很快就了解了為什麼這個問題值得關注,以及不行動的影響。

找出問題的根因#

第二部分是向下挖掘,從問題陳述出發,問「Why?」(為什麼?)的問題。就像「So what?」問題一樣,為每個答案建立便利貼。

你會產生很多分支,但要持續深入挖掘。記得畫箭頭和線條顯示便利貼之間的關聯。

在根因分析中,你可能會發現自我強化迴圈 (self-enforcing loops)——便利貼形成一個循環引用。這些是需要特別注意的地方,它們有可能造成惡性循環,問題不斷互相餵養。務必將這些迴圈標記出來(例如用紅色箭頭圈出),以確保記得處理這些問題。

Figure 10.3: Cause tree showing bug causes with reinforcing loops

範例對話——向下挖掘根因:

  • 「為什麼有這麼多 Bug?」 → 時間壓力很大,一直要求交付;不再做技術工作項目;停止了配對程式設計 (pair programming)
  • 「為什麼不做技術工作項目?」 → 因為時間壓力。「配對程式設計也是嗎?」 → 是的,大家覺得配對會花更久。→ 自我強化迴圈:時間壓力導致跳過品質實踐,進而產生更多 Bug,造成更大的時間壓力
  • 「為什麼有時間壓力?」 → 五月的版本發布要到了
  • 「為什麼有交付的時間壓力?」 → 團隊沒有參與決定五月版本的 Backlog,造成 Backlog 遠超過可以處理的範圍
  • 「為什麼沒有發言權?」 → 當時團隊被要求不能從二月版本的開發中抽出時間 → 又一個自我強化迴圈:交付壓力阻礙團隊參與規劃

Figure 10.4: Complete root cause tree with cascading consequences

根因分析是一把銳利的工具,能快速切入問題的根源和業務影響。這可能會引發一些重大的問題,因此務必確保房間中的氛圍是解決問題而非責怪他人。在開始之前提醒大家工作坊的目標,以及你要找的是「尚未實現的流程改善機會」,而不是失敗的人。

根因分析的核心要點:

  • 使用五個為什麼 (Five Whys) 持續追問
  • 找到真正的原因才能解決真正的問題
  • 向上推演找出問題的影響(問「So what?」)
  • 向下挖掘找出根本原因(問「Why?」)
  • 視覺化與合作式的練習

10.3 Kanban Kata#

回顧會議很好,因為它允許團隊跳出正常的工作流來改善流程。但在日常工作中,你也可以進行改善——例如修復經常失敗的建置步驟,或朝著更大的目標(如降低工作項目的平均前置時間)邁進。

Kanban Kata 是另一種實施流程改善的方法。它是一系列問題和表格,幫助你以小步驟、在持續的流程中進行改善,讓改善工作與日常工作交織在一起。這是由 Hakan Forss 所開創的方法。

什麼是 Kata?

Kata(型)一詞常見於武術。它指的是反覆練習一組預定義的動作,以建立肌肉記憶。追求的是盡可能精確地執行動作,一遍又一遍地練習,直到在實戰中這些基本動作已經內化,不需要刻意思考。

從武術到流程改善的跳躍源自 Mike Rother 的著作 Toyota Kata(2009)。書中描述了 Toyota 如何在實踐中實施持續改善。Hakan Forss 將 Toyota Kata 的理念應用於軟體開發中的看板,稱之為 Kanban Kata

Kata——一系列你精確遵循的問題——起初可能感覺刻板,但記住 kata 的重點就是透過反覆練習讓它成為肌肉記憶。最終它訓練你自然而然地做出正確的事。在這裡,kata 訓練的是流程改善的能力。

10.3.1 什麼是 Kanban Kata?#

Kanban Kata 由三個 kata(或稱改善對話)組成:

  • Daily Kata(日常型) — 將改善工作納入每日會議
  • Improvement Kata(改善型) — 正式化的流程改善方式
  • Coaching Kata(教練型) — 聚焦於改善學習者(團隊中的人):一種教練技巧

Daily Kata — 日常型#

Daily Kata 改變了每日站立會議的焦點,透過五個問題 (Five Questions) 來引導討論:

  1. What are we trying to achieve?(我們試圖達成什麼?)
  2. Where are we now?(我們現在在哪裡?)
  3. What obstacles are in our way now?(現在有什麼障礙擋在我們前面?)
  4. What’s our next step, and what do we expect?(我們的下一步是什麼,我們預期什麼?)
  5. When can we see what we’ve learned from taking that step?(什麼時候可以看到我們從這一步學到了什麼?)

Figure 10.6: Coaching Kata card with the Five Questions

範例場景:

團隊圍在看板前進行晨會,團隊領導 Frank 使用五個問題引導:

  • 目標: 每週三要有準備好發布的程式碼——也就是明天
  • 現況: 有風險無法在明天發布
  • 障礙: Master branch 無法建置,有嚴重的合併問題;工作項目 46 有業務規則方面的問題,阻礙了規格和測試規格的完成
  • 下一步與預期:
    • Daphne 和 Eric 正在調查建置錯誤,預計一兩小時內找到問題
    • Adam 下午兩點與 Cesar 和 Beth 開會釐清業務規則
  • 學習驗證時間:
    • 午餐前重新集合確認建置問題
    • 明天晨會分享業務規則會議的結果

Frank 結束會議時愉快地說:「Stop starting, and start finishing!」

Improvement Kata 與 Coaching Kata — 改善型與教練型#

在日常站會結束後,Hakan(教練角色)與 Frank 進行教練對話,使用另一組五個教練問題

  1. What is the target condition?(目標狀態是什麼?)
  2. What is the condition now?(目前的狀態是什麼?)
  3. What was your last step?(你上一步是什麼?)/ What happened?(發生了什麼?)/ What did you learn?(你學到了什麼?)
  4. What obstacles are now preventing you from reaching the target condition?(現在有什麼障礙阻止你達到目標狀態?)/ Which one are you addressing now?(你現在在處理哪一個?)
  5. What is your next step? What do you expect?(你的下一步是什麼?你預期什麼?)/ When can we go and see what we have learned?(什麼時候可以看到我們學到了什麼?)

Figure 10.5: Lead time scatter plot over weeks 14-19

範例對話:

  • 目標狀態: 將中型工作項目的前置時間降至五天(長期目標是在現有人力下降低所有工作項目的前置時間)
  • 目前狀態: Frank 展示了前置時間的散佈圖,最近的數據已接近五天的目標
  • 上一步: 記錄了測試環境的設置流程
  • 學到了什麼: 許多測試設置步驟是手動執行的,其實可以自動化
  • 目前的障礙: 測試設置時間
  • 下一步: 開始自動化測試資料的載入(而非一次自動化整個設置流程——小步驟!)
  • 預期結果: 至少減少 80% 的資料庫設置時間,約節省四到五分鐘
  • 驗證時間: 週五完成,屆時再次會面

團隊使用 PDCA Cycles Record(Plan-Do-Check-Act 循環記錄表)來追蹤每次實驗的決策與進展,記錄每一步的預期結果、實際結果和學到的經驗。

Hakan 強調要盡可能精確地描述預期結果。精確的預期使我們能清楚判斷是否達到了目標。重要的不是必須達到預期,而是透過比較實際結果與預期來學習。Kata 的核心是學習,讓我們能一步步持續改善。

10.3.2 發生了什麼#

在上面的範例中,你看到了三個 kata 的運用:

  • Daily Kata — Frank 在晨會中使用預定義的五個問題引導團隊
  • Coaching Kata — Hakan 使用教練問題引導 Frank 思考改善工作
  • Improvement Kata — 整個改善流程的框架

如果你覺得這些 kata 的問題格式不適合你的團隊,可以自行制定。但制定後就必須嚴格遵循,就像遵循原始問題一樣。重複是完美的關鍵。

「Repetition is the mother of all knowledge. Now do the assignment again.」 — Lennart Wistedt

注意改善過程中對學習小步驟的聚焦。對於每一個小步驟,團隊都先被問到預期結果,然後被問到從結果中學到了什麼。這就是科學方法的應用:

  1. 發展假說 (hypothesis)
  2. 預測將會發生什麼 (prediction)
  3. 執行實驗 (experiment)
  4. 觀察數據 (observation)
  5. 反思預測與實際結果之間的差異 (reflection)

10.3.3 為什麼這樣有效?#

Kanban Kata 之所以有效,有幾個關鍵原因:

基於科學方法的結構化學習: 三個 kata 都建立在科學方法之上。使用科學方法的好處是:沒有「失敗的」結果,只有結果。你會利用結果來學習,並改善下一次的假說。

There is no such thing as a failed experiment, only experiments with unexpected outcomes. — R. Buckminster Fuller

採取小步驟: 你嘗試從目前的狀態 (current condition) 改善到目標狀態 (target condition)。通往目標的道路是未知的,而最佳的導航方式就是小步驟。這些步驟就是基於假說所進行的實驗。

  • 即使犯錯或走錯路也沒關係,只要你從中學習並改善
  • 從目前狀態到目標狀態意味著穿越未知的領域
  • 你必然會走一些彎路——但只要是小步驟,你就能在途中修正方向

建立習慣與心態: 在 Kanban Kata 中,你使用固定的例行程式(問題和表格)來引導不同的 kata。它們幫助你建立新的習慣和持續學習與改善的心態。這才是使用 Kanban Kata 的真正收穫:在整個組織中建立一種每天做出微小改善的習慣與心態。

Kanban Kata 的核心要點:

  • 透過一組預定義的問題進行持續改善
  • 基於科學方法——假說、實驗、觀察、學習
  • 對準你的願景,採取小步驟逐步靠近
  • 三個 Kata:
    • Daily Kata — 聚焦日常活動
    • Improvement Kata — 聚焦流程改善
    • Coaching Kata — 改善學習者本身

10.4 本章總結#

本章探討了流程改善及常見的改善實踐:

  • 持續改善尊重人是看板的核心
  • 看板幫助你發現改善機會,但改善仍需你主動執行

三種改善實踐:

  • 回顧會議 (Retrospective)

    • 團隊回顧流程以找出改善方式
    • 五個步驟:設定場景 → 蒐集資料 → 產生洞察 → 決定行動 → 結束回顧
    • 偏好頻繁的小改善而非罕見的大改善
    • 使用 SMART 目標確保改善行動明確可衡量
  • 根因分析 (Root-Cause Analysis)

    • 幫助找到問題的根本原因,而非只修復症狀
    • 向上推演了解問題的影響(問「So what?」)
    • 向下挖掘找出真正原因(問「Why?」)
    • 注意自我強化迴圈——它們可能造成惡性循環
    • 視覺化與合作式的練習
  • Kanban Kata

    • 基於 Toyota 持續改善方式的工具
    • 三個 kata:Daily Kata(日常型)、Improvement Kata(改善型)、Coaching Kata(教練型)
    • 「Kata」意味著你遵循固定的工作方式朝目標邁進,直到這個例行程式成為第二天性
    • 讓改善成為你正常工作的方式

下一章將探討如何使用指標 (Metrics) 來確認你是否真的在改善。