流程目標的定義

當團隊討論流程時，是否也曾聽過有人問：「為什麼要這樣做？」而主管卻只回答：「因為 Scrum 就是這樣規定的。」

想嘗試改善流程，卻被框架侷限，不知道哪些可以改、哪些不能動。不同團隊各自摸索流程，沒有共通語言，也沒有參照依據，只能靠經驗猜。

這種現象背後，其實反映了一個根本問題：

我們把流程當作「標準答案」來執行，而不是當作「思考架構」來設計與優化。

Disciplined Agile （簡稱 DA）的設計邏輯正好相反。它不告訴團隊「該怎麼做」，而是幫助團隊回答：「針對我們的情境，有哪些選項？又該如何選擇？」

這一切的關鍵，就是流程目標（Process Goal）。

所謂的流程目標，並不是一張固定的流程圖或作業清單，而是一組結構化的決策架構。它協助團隊釐清：

• 當我們面對某個流程議題（如：探索需求、釋出產品、驗證品質）時，有哪些關鍵決策需要做出？
• 每個決策點底下，有哪些做法可供選擇？
• 這些選項之間的風險、成熟度與適用情境為何？

流程目標的出現，讓團隊不再只是照著方法論走流程，而是開始建立起一種有選擇、有意識、可持續進化的流程設計能力。

流程目標不是流程，而是協助團隊做決策的「地圖」

簡單來說，一個流程目標就像是「我們想要達成某件事」的任務起點，而不是「怎麼做這件事」的固定步驟。它不會告訴團隊要用 Scrum 還是 Kanban，不會硬塞一套做法，而是幫助團隊根據自己的情境，選擇最合適的方式來完成目標。

以「部署解決方案」為例，DA 會先問：「團隊的部署流程穩定嗎？自動化成熟嗎？是否有合規需求？」然後根據這些情境，提供不同的策略選項，讓團隊做出最適合自己的選擇。

每個流程目標，都是一組「決策點」與「選項組合」

一個流程目標的內容大致包含三個部份：

1. 流程目標
   例如「計劃產品釋出」、「應對風險」、「改善品質」。

2. 決策點（Decision Points）
   這是想要完成該目標時，團隊需要思考的各種問題，例如「要怎麼估算時程？」「交付的頻率應該多快？」「該由誰驗證品質？」

3. 選項列表（Options）
   每個決策點會列出數個可行選項，有的標示為「預設起點」（bold italic），適合新手團隊作為起步；有些則是進階選項，必須評估其代價與回報。

這種設計，就像一份互動式地圖，提醒團隊哪些地方需要注意與考量選擇，並清楚標示出各條路線的特色與風險。

舉個例子：估算工作量的方式

假設我們正在討論「如何計劃產品釋出」，其中一個決策點是「要採用哪種估算方式？」常見的選項有：

• 由團隊合理推測（Educated guess by team）
• 規劃撲克（Planning poker）
• 無估算（No Estimation）
• 功能點（Function points）

每種方式都有其適用情境。例如小團隊熟悉故事點（Story Points）概念，用規劃撲克就會很順手。但對有精準預算壓力的金融組織單位，用功能點的方式可能更易於被接受。若是維運性質的持續交付團隊，甚至可以考慮採用無估算策略，直接依據處理速率來排程。

關鍵不在於哪一種方法最好，而是在於團隊有沒有看清楚自己的情境，選擇合適的方法。

與傳統「流程模板」的差異

過去在導入敏捷時，我們經常會看到一種現象：一開始團隊學習了某一種方法（例如 Scrum 或 SAFe），接著就仿照它的流程圖、節奏與角色設計，建了一套「標準流程模板（Process Template）」。看起來一切有章有法，但實際運作時卻常常卡住，甚至引發更多阻力。

問題就出在於流程模板只說明了「怎麼做」，卻沒有回答「為什麼這樣做？」

模板的問題：用固定答案套不同的問題

流程模板就像是預設好的流程藍圖，通常包含一組活動、角色與節奏，例如：

• 每兩週進行一次迭代
• 每天早上召開 15 分鐘站會
• 由產品負責人管理產品待辦清單
• 迭代結束舉辦展示與回顧會議

這些做法本身沒有錯，但問題在於：前提假設是所有團隊都處於相同情境、面對同樣問題。所以一旦團隊照著這些模板去做，往往便沒辦法因應現實中的變化，例如：

• 團隊分布在不同時區，每日站會難以同步。
• 產品負責人不熟業務，無法有效管理需求。
• 兩週一迭代的節奏對於資料分析團隊過於頻繁。

這時候就會出現「有做，但沒用」的現象：表面上遵循敏捷流程，實際上卻談不上真正的敏捷。

流程目標的價值：讓團隊「依據目的，選擇做法」

DA 提出流程目標的概念，就是為了解決這個困境。它不再告訴團隊「應該怎麼做」，而是提醒團隊先想清楚「要達成什麼」，然後根據情境選出適合的做法。

例如：

• 團隊的目標是「加快價值交付」，那可以選擇減少批量大小、提升部署頻率、縮短回饋迴路等手段。

• 團隊的目標是「探索範疇」，則可以採取人物誌（Persona）、使用者故事地圖（User story map）、影響地圖（Impact map）等工具。

重點是：流程目標提供的是「選擇架構」，而不是「標準答案」。

模板追求一致性，流程目標強調適應性

流程模板最大的優點是「統一性」，適合在大型組織推動標準化流程時使用。但敏捷的本質是「因應變化」，而不是「套用標準」。

DA 之所以強調流程目標，是因為它尊重每個團隊的獨特性。不同的技術組合、利害關係人需求、法規限制與人員組成，會影響團隊在相同目標下做出不同選擇。

流程目標提供的是「決策結構」，需要思考但能更貼近實際。從表面上看，模板執行起來更快速，但從長期來看，流程目標讓團隊學會選擇與調整，才是真正能持續成長、因應變化的能力。

幫助團隊思考與決策

很多團隊學習敏捷的第一步，都是從模仿開始。這是很自然的學習歷程：看別人怎麼做，我們就照樣做。例如：

• 看別人用 Scrum，我們也跟著兩週一迭代。
• 看別人開每日站會，我們也每天早上集合報告進度。
• 看別人寫使用者故事，我們就把需求改成「In order to..., as a … , I want …」的格式。

這些模仿行為本身沒錯，但若缺乏對背後目標的理解，很容易讓流程變成形式，而非價值的實現。

做法只是手段，目的才是本質

拿「每日站會」當例子。很多團隊每天準時集合，但實際上只是輪流背稿、報告昨天做了什麼，今天要做什麼，然後草草收場。

問他們為什麼要開這個會？多半會說：「因為 Scrum 規定要這麼做。」

但事實上，站會的本質目的是為了同步資訊、揭露阻礙、促進協作。如果這些目標沒有被實現，即便流程照表操課，也無助於團隊的改善。

這就是流程目標要解決的問題：讓團隊從「為了做而做」的被動執行者，變成「知道為何而做」的主動決策者。

舉個例子：同樣是「制定測試策略」，做法可以千變萬化

當我們想要「制定測試策略」這個流程目標時，首先要做的不是直接套某種測試技術框架，或是購買某個測試管理工具，而是先思考：

• 要驗證哪些層次的品質？（功能性？效能？安全性？）
• 誰負責執行測試活動？（開發人員？測試人員？自動化流程？）
• 測試活動在什麼時候發生？（開發前？開發中？部署前？）

這些就是流程目標中的「決策點」。每個決策點下面都有不同的實作選項。例如有的團隊選擇使用測試驅動開發（TDD），有的團隊會寫自動化驗收測試，有的團隊只做基本手動點測。

選哪一個不重要，重要的是團隊知道是基於什麼情境和理由選擇它，以及它是否真的幫團隊達成目標。

結語：如果只模仿做法，就永遠無法改善

沒有目標導向的流程，只會讓團隊陷入「流程崇拜」的陷阱。

• 覺得每日站會很煩，卻不知道可以改變會議形式或頻率。
• 覺得寫使用者故事沒幫助，卻不知道可以換成對話式範例或其他需求表示法。
• 覺得迭代速度太慢，卻不知道可以調整批量大小或交付節奏。

但如果從目標出發，團隊就會開始問：

• 我們開這個會的目的是什麼？目前有達成嗎？
• 現在這個流程是幫助我們還是阻礙我們？
• 有沒有更好的方法，能更快或更清楚地達成我們的目標？

這些問題，才是團隊自我改善的起點。DA 的流程目標設計，正是為了改變團隊的思考方式：

不再是「我們要做什麼流程」，而是「我們想達成什麼目標？目前做法有幫上忙嗎？」

當團隊從目標開始思考，流程的選擇就會有所依據，改善也就有方向。模仿固然可以快速上手，但唯有理解背後的目的，才能讓流程真正為團隊所用。

• Disciplined Agile® (DA™) Tool Kit: Process Goals