計畫來源（Source of Plan）：避免發布計畫變成紙上時程

計畫來源（Source of Plan）是 Disciplined Agile（DA）發布規劃（Plan the Release）中的關鍵決策點。它處理發布計畫由誰形成、哪些資訊需要納入，以及團隊能否根據這些資訊執行與調整計畫。

自組織團隊（Self-organizing Team）、團隊領導（Team Leadership）、經理引導（Manager Facilitated）與經理驅動（Manager-driven）都有適用情境。需求仍在變動、技術風險較高時，實際開發成員需要更早參與規劃。受到法規、預算或高階承諾限制時，組織可能先由經理提出時間框架，再由團隊檢查容量、相依性與技術風險。

發布計畫需要看得到參與角色、責任、估算依據、風險與主要假設。當團隊能穩定整理這些資訊，規劃責任就可以分階段交由團隊承擔。後續檢查進度時，團隊也能同時確認工作完成狀態，以及原先支撐日期、範圍與節奏的條件是否仍然成立。

計畫來源（Source of Plan）在發布規劃中的位置

發布規劃處理的管理問題

發布規劃（Plan the Release）是 Disciplined Agile（DA）用來建立初始計畫的流程目標。它處理的管理問題很直接：這次發布大約需要多久、成本落在哪個範圍、有哪些相依工作、團隊會用什麼節奏交付，以及哪些風險需要先被攤開。

利害關係人需要這些資訊，因為行銷活動、客服準備、預算安排與其他團隊的時程，都可能依照這份發布計畫做決定。若團隊只提供一個日期，沒有交代假設、範圍、相依性與風險，後續需求變動或技術限制浮現時，這份計畫就很難繼續作為判斷依據。

DA 在發布規劃中強調先釐清判斷依據，再決定如何記錄計畫。計畫可以採用路線圖（Roadmap）、里程碑（Milestone）、版本節奏、產品待辦清單（Product Backlog）中的高層次安排，也可以搭配估算（Estimation）與風險清單。團隊需要能清楚說明目前的時程與成本判斷，是建立在哪些需求、技術條件、容量與相依關係上。

計畫來源（Source of Plan）在這裡也很重要。發布計畫由誰制定，會直接影響哪些資訊能進入計畫。若制定計畫的人離實際開發工作太遠，技術限制、人員可投入容量（Capacity）、跨團隊相依性與驗證工作都可能被低估。

制定計畫的人越能接近真實工作現場，就越能把這些限制納入判斷，讓發布計畫成為後續可以持續檢查與調整的工作假設。

計畫來源決定誰的現實被放進計畫

計畫來源回答的是「誰負責形成發布計畫」。這個決定會影響責任分配、資訊來源與風險判斷，也會決定哪些限制與條件能進入計畫。

以會員系統改版為例，管理層會先看市場活動日期、預算窗口與對外承諾。產品負責人（Product Owner）會判斷哪些功能需要優先上線，哪些需求可以留到下一個版本。工程師會注意舊會員資料格式、登入流程相依性、測試資料不足與部署風險。架構負責人（Architecture Owner）則會檢查新舊服務如何並行、資料庫變更能否回復，以及跨系統介面是否需要先做概念驗證（Proof of Concept, PoC）。

同一個發布日期，在不同角色眼中代表不同的工作條件。管理層關心承諾日期，產品角色關心價值範圍，工程角色則需要處理工作量、技術風險與驗證工作。若形成計畫的人只掌握其中一種視角，其他角色面對的限制就可能沒有被納入計畫。

DA 將計畫來源放在發布規劃底下，就是要先釐清哪些角色參與計畫形成、誰負責引導討論，以及誰提供估算與風險判斷，再進一步討論日期與範圍。這樣能讓發布計畫從一開始就納入實際工作條件，也能減少後續因資訊缺漏而反覆調整時程與範圍。

計畫來源（Source of Plan）影響的三個面向

計畫真實性與開發現場的距離

計畫是否可信，取決於具體資訊是否被納入。工程師知道哪些舊系統限制會拖慢開發，架構負責人（Architecture Owner）知道哪些技術方案還沒驗證，產品負責人（Product Owner）知道哪些需求牽涉利害關係人的承諾。這些資訊進入發布規劃（Plan the Release）後，日期才比較能反映團隊實際可交付的範圍。

以會員系統改版為例，資料遷移可能要先清理舊資料，第三方簡訊服務可能需要重新申請測試帳號，客服後台也可能要配合新欄位調整。若制定計畫的人沒有掌握這些細節，發布計畫很容易只剩下需求確認、開發、測試與上線幾個階段。忽略了實際工作還包含等待、驗證、資料修補，以及跨團隊協調所需的時間。

計畫來源離開發現場越遠，越可能直接用職位或人數推估產能。例如「三位工程師做四週」看起來代表一段可投入容量（Capacity），實際上每個人熟悉的模組、可投入時間、請假安排與支援任務都不相同。計畫來源首先會影響的，就是這些差異能否被納入時程與工作量判斷。

團隊接受度與執行承諾

團隊是否參與制定計畫，會影響成員是否理解並認同這份計畫。

由主管或少數角色直接交付的計畫，即使日期寫得很清楚，實際執行的人也可能不知道估算依據從哪裡來。工作開始後，只要遇到資料問題、測試環境延遲或需求澄清卡住，團隊就會發現原先時程沒有把這些條件算進去。

短衝規劃（Sprint Planning）處理該次短衝的工作安排，發布規劃則處理較長時間尺度的方向與交付節奏。兩者涵蓋的時間不同，實際執行工作的人都需要參與相關判斷，說明限制、提出估算、指出風險，並理解最後形成的取捨。

若團隊沒有參與初始發布規劃，前期的估算、範圍或相依假設就可能和實際工作不一致。到了後續短衝規劃，團隊便需要反覆調整工作內容，修正前面留下的錯誤假設。

團隊參與制定計畫，也能讓成員知道目前的日期與範圍建立在哪些假設上，以及哪些條件還需要驗證。後續檢查進度時，就可以直接確認這些假設是否成立，例如相依團隊是否如期交付、資料遷移是否通過驗證，以及產品範圍是否維持原先設定。

管理期待與利害關係人溝通

管理層與利害關係人需要發布計畫來安排預算、行銷、客服教育訓練與跨部門時程。這些需求不會因為團隊採用敏捷而消失。

計畫來源需要處理的，是如何讓管理需求、商業時程與團隊實際能做到的範圍一起進入規劃討論。

若主管只得到「做不到」這種回應，討論很快就會停在日期拉扯。團隊若能說明可投入容量、技術風險、相依工作與替代方案，利害關係人就能進一步調整範圍與順序。

例如會員系統改版需要配合雙十一活動時，團隊可以說明哪些功能必須先上線、哪些管理報表可以延後，以及哪些資料遷移需要提前演練。

計畫來源也會影響規劃時能取得的資訊。經理驅動（Manager-driven）的計畫可以直接納入預算、商業期限與管理要求，同時需要確認團隊容量、技術限制與驗證工作是否已經被考慮。

由自組織團隊（Self-organizing Team）制定的計畫，可以直接納入開發限制、估算與技術風險，卻需要額外補足商業期限、跨部門安排與對外承諾等資訊。

選擇計畫來源時，需要確認規劃過程是否能即時取得這些資訊，讓日期、範圍與風險建立在完整的判斷基礎上。

自組織團隊作為計畫來源的使用情境

自組織團隊共同制定發布計畫

自組織團隊（Self-organizing Team）作為計畫來源時，發布計畫由團隊成員共同形成，並由一位引導者協助討論。

產品負責人（Product Owner）說明商業優先順序，工程師提出技術限制，測試角色補充驗證成本，架構負責人（Architecture Owner）說明跨系統風險。這些資訊會直接進入發布計畫。

以會員系統改版為例，團隊可以先列出預期發布範圍，再逐一確認哪些功能需要一起上線。登入流程、會員資料欄位、客服後台與行銷活動頁面看起來屬於不同工作，實際交付時可能共用同一批資料結構。團隊共同制定計畫時，就能提早確認這些相依關係，並把對應的開發、驗證與協調工作納入時程。

自組織團隊形成計畫後，成員會知道估算依據、主要風險與範圍取捨。後續遇到需求調整或相依工作延遲時，團隊可以回到原先假設重新檢查，例如工作量是否增加、外部依賴是否改變，以及原訂發布日期是否仍然成立。

需要引導與規劃技巧的支援

自組織團隊需要清楚的引導與規劃方法。引導者要協助團隊依序整理範圍、估算、風險、相依性與交付節奏，並把這些資訊放進同一份發布計畫。若每個人只說明自己手上的工作，最後很容易得到一份零散的任務清單。

剛開始採用敏捷的團隊尤其需要這種支援。團隊可能熟悉短衝規劃（Sprint Planning），卻還不熟悉較長時間尺度的發布規劃（Plan the Release）。短衝規劃主要處理接下來一兩週的工作，發布規劃還要納入版本節奏、相依團隊、環境準備、資料遷移與利害關係人期待。

滾動式規劃（Rolling Wave Planning）可以協助團隊控制不同時間範圍的細節程度。近期工作可以拆得更清楚，遠期工作先保留高層次安排，等資訊增加後再進一步細化。

若會員系統改版預計分三個月推進，第一個月可以明確安排資料清理、登入流程調整與測試環境準備，第三個月則先保留報表補強與營運工具調整等較高層次工作。

初始發布規劃仍需要涵蓋足夠的資訊。團隊若把過多細節留到開發期間才處理，前期就可能漏掉相依團隊、測試資料、法務審查或客服訓練。這些工作太晚被發現時，就可能直接影響原先安排的發布節奏。

團隊領導引導時的偏向風險

自組織團隊仍需要注意引導者對規劃內容的影響。引導者主持發布規劃討論時，焦點可能集中在他較熟悉的議題。引導者若長期關注架構問題，計畫可能安排較多技術整理。若他主要承擔交付時程壓力，討論也可能過度集中在日期與範圍，讓技術風險缺少足夠時間檢查。

這些偏向多半來自角色視角不同。熟悉架構的人會先注意系統風險，熟悉產品的人會先注意市場時程，熟悉維運的人會先注意部署與監控。引導者需要主動把這些觀點帶進討論，讓團隊共同確認哪些因素會影響發布計畫。

規劃時可以先列出主要假設，再逐一檢查風險，最後確認發布節奏。團隊可以先寫下「第三方服務測試帳號兩週內可取得」、「舊會員資料清理可在第一個月完成」、「客服訓練可配合第二次內部展示」等假設，再檢查哪些條件的不確定性較高，以及哪些工作需要提前驗證。

自組織團隊作為計畫來源時，需要讓會影響發布結果的資訊進入討論，也要讓成員清楚知道目前的日期、範圍與節奏建立在哪些條件上。

團隊領導與經理參與計畫的取捨

團隊領導制定計畫的效率與限制

團隊領導（Team Leadership）作為計畫來源時，發布計畫多由團隊引導者（Team Lead）、產品負責人（Product Owner）與架構負責人（Architecture Owner）先形成。參與人數較少，討論範圍集中，規劃速度也比較快。

這個選項適合需求範圍已經相對清楚、團隊已有合作默契，且主要技術風險已經完成初步確認的情境。

以會員系統改版為例，如果團隊已經完成資料盤點，登入流程也做過概念驗證（Proof of Concept, PoC），團隊領導可以先整理發布範圍與節奏，再交由團隊檢查。

由於一般成員參與較少，計畫可能漏掉實作現場才掌握的細節。例如工程師可能知道舊會員資料存在大量例外格式，測試角色知道測試環境資料不完整，維運角色也可能知道部署窗口受到其他系統限制。這些資訊若沒有進入計畫，後續就可能影響估算、驗證與發布時程。

因此，團隊領導形成初步計畫後，還需要安排團隊檢查。實際執行者可以重新確認估算、相依性、風險與可投入容量（Capacity），並指出需要修正的假設。經過這一輪檢查後，初步發布計畫才會納入實際執行條件。

經理引導計畫的壓力與價值

經理引導（Manager Facilitated）是由經理帶領團隊完成發布規劃。經理可能來自團隊外部，也可能負責跨團隊協調、預算安排或利害關係人溝通。這種做法可以讓管理需求、外部承諾與團隊限制直接進入同一場規劃討論。

當發布牽涉多個部門時，經理可以協助整理跨部門資訊。會員系統改版若同時影響行銷活動、客服訓練、資料團隊報表與法務條款，經理可以協助確認哪些時程來自外部承諾、哪些範圍可以調整，以及哪些風險需要提前向利害關係人說明。團隊也能在討論過程中補充技術限制、驗證工作與相依條件。

經理引導時也要注意匯報關係帶來的影響。若團隊成員直接向經理匯報，有些人可能不願主動說明測試覆蓋不足、關鍵成員即將請假，或相依團隊尚未確認交付時間。這些資訊若沒有進入規劃，日期與範圍就可能建立在不完整的假設上。

經理可以先請團隊列出主要假設、相依性與風險，再進一步討論日期與範圍。例如先確認「測試環境是否可用」、「關鍵成員是否有足夠可投入容量」、「外部團隊是否已確認交付時間」。討論聚焦在這些條件後，團隊會有更明確的依據說明限制，經理也能據此調整發布安排。

經理驅動計畫的表面穩定與執行落差

經理驅動（Manager-driven）是由經理先形成發布計畫，再交由團隊執行。這種方式可以快速產生日期、里程碑與對外說法，也方便高階主管與利害關係人先安排後續工作。

有些情境會促使組織採用經理驅動。例如合約日期已經確定、法規期限固定、預算審查需要先提出里程碑，或公司已經對外公布活動日期。經理可以先根據這些限制提出時間框架，讓相關部門有一個共同的規劃基準。

需要注意的是，這份計畫可能還沒有納入團隊實際面對的限制。若只用職位與人數估算，例如「兩位後端、兩位前端、一位測試，六週完成」，就可能漏掉每個人熟悉的系統區域、支援任務、請假安排、相依團隊交付時間與技術不確定性。

這類計畫也可能增加後續的調整與說明工作。當實際進度與原訂時程出現差異，團隊需要反覆解釋落差原因，進度會議也可能集中在日期偏離。若成員不了解原先估算依據，也沒有參與範圍與風險討論，就不容易共同調整後續工作。

組織若採用經理驅動方式，可以在初步計畫形成後加入團隊可行性評估（Feasibility Assessment）。經理先提出管理上需要的時間框架，再由團隊逐項確認假設、風險、相依性與可投入容量。經過這一輪檢查後，發布計畫才能納入開發現場的實際條件。

計畫來源（Source of Plan）的選擇判斷

依不確定性與技術風險安排參與深度

選擇計畫來源時，可以先檢查目前有哪些不確定性。需求是否清楚、技術方案是否完成驗證、相依團隊是否確認交付時間，都會影響哪些角色需要參與發布規劃（Plan the Release）。

需求仍在探索時，產品負責人（Product Owner）與實際開發成員需要一起檢查範圍。架構還有待驗證時，架構負責人（Architecture Owner）與工程師要提早參與。跨團隊介面尚未確定時，負責協調的人也需要進入討論，將可能的等待時間與相依條件納入計畫。

會員系統改版可以用來判斷需要多少角色參與。若只調整會員暱稱欄位，團隊領導可以先整理計畫草案，再由工程師與測試角色確認工作量與驗證方式。若修改範圍包含登入機制、資料表結構與客服流程，就需要產品、工程、架構、測試與相關營運角色共同確認，因為發布結果同時受到需求、技術、資料與營運流程影響。

技術不確定性增加時，實際開發成員需要更早參與計畫形成。團隊可以先確認哪些工作需要概念驗證（Proof of Concept, PoC）、哪些相依性要提前確認，以及哪些功能可以拆成較小的發布批次，再依據這些資訊安排日期與順序。

依團隊成熟度調整引導方式

團隊目前的協作能力會影響引導方式。新成立的團隊可能還不熟悉彼此的工作習慣，也不清楚哪些人掌握特定系統知識。這時，Scrum Master、專案經理或有經驗的團隊引導者（Team Lead）需要協助拆分工作、整理相依性、引導估算（Estimation），並提醒團隊把主要風險納入計畫。

若團隊已經有穩定的產品待辦清單（Product Backlog）、路線圖（Roadmap）、估算方式與風險追蹤習慣，發布規劃就可以採用較精簡的方式。團隊領導可以先整理初稿，再透過短時間討論確認假設、相依性與可投入容量，減少不必要的規劃時間。

引導方式應隨著團隊能力調整。新團隊一開始可能需要較多協助，等成員熟悉估算、相依性整理與發布節奏後，就可以把更多規劃工作交由團隊處理。轉換時要明確交代責任，例如誰維護發布節奏、誰更新風險，以及誰負責與利害關係人溝通。

轉型過渡期常會採用混合做法。組織一開始可能受到法規期限、年度預算或高階主管承諾限制，因此先由經理驅動或經理引導建立初版發布計畫。

當團隊能穩定整理風險清單、估算差異、相依性與容量限制後，管理層就能清楚區分哪些條件來自商業約束，哪些限制來自開發現場。這些資訊持續累積後，規劃責任可以分階段調整。

一開始可以由經理提出時程與管理限制，再由團隊檢查可行性。等團隊能自行提出估算、風險與發布節奏後，就可以改由團隊形成計畫，經理則協助處理跨部門協調、預算與外部承諾。

DA 強調選擇工作方式（Way of Working）要回到團隊當下的情境。自組織團隊、團隊領導、經理引導與經理驅動，都需要依據技能分布、相依關係、管理限制與風險程度來安排參與方式，再決定哪些角色要加入規劃，以及需要參與到什麼程度。

檢查計畫假設是否可被驗證

不管計畫由誰制定，都需要說清楚判斷依據。發布日期、範圍與成本估算背後，都建立在一組具體條件上。若這些條件沒有被說明，計畫就只剩下一個日期與範圍目標。

團隊可以逐項檢查幾個問題。每位成員每週可投入多少時間，是否已扣除支援任務與固定會議。相依團隊何時交付介面，是否已有共同確認的交付標準。測試環境是否可用，測試資料是否足以支援驗證。技術方案是否完成概念驗證，資料遷移是否已經演練。

這些問題可以把規劃依據轉成可檢查的條件。若會員系統改版預計六週上線，團隊就要知道這六週是根據哪些功能範圍、哪些人力、哪些相依交付與哪些已知風險估算出來。只要其中一項條件改變，日期、範圍或工作安排就需要重新檢查。

計畫來源確定後，團隊可以把主要假設直接記在發布計畫附近。這些內容不需要另外整理成厚重文件，可以放在路線圖（Roadmap）、產品待辦清單（Product Backlog）、風險清單或團隊 Wiki。後續檢查進度時，就能直接確認這些條件是否仍然成立，再判斷計畫是否需要調整。

團隊可以依下列檢查表問題進行發布計畫「假設與限制」的驗證：

• 可投入容量假設：團隊成員可投入容量是否已扣除維護支援、跨專案會議、休假與日常營運？
• 相依性假設：外部團隊 API／介面的交付時間與規範是否已有雙方簽認的完成定義（Definition of Done, DoD）？
• 環境假設：測試環境、概念驗證環境與測試資料是否會在開發前到位？
• 技術／架構假設：關鍵技術風險是否已安排探針（Spike）／概念驗證？

結語：用計畫來源（Source of Plan）讓發布計畫回到可執行工作

先決定參與者，再討論日期與範圍

計畫來源提醒團隊，在開始發布規劃（Plan the Release）前，先確認哪些角色需要參與制定計畫。團隊要說清楚誰負責引導、誰提供產品優先順序、誰說明技術風險、誰確認可投入容量（Capacity），以及誰負責提供跨團隊相依資訊。

這個步驟需要在發布規劃會議前完成。產品負責人（Product Owner）先整理預期範圍與商業時程，架構負責人（Architecture Owner）列出需要驗證的技術假設，工程師檢查已知限制，專案經理或團隊引導者（Team Lead）則確認需要邀請哪些相依團隊與利害關係人。

參與角色確認後，日期與範圍才能建立在較完整的資訊上。主管提出期望日期時，團隊可以說明哪些條件需要先成立。工程師提出風險時，產品角色也能判斷哪些範圍可以調整。最後形成的發布計畫，會同時包含日期、範圍、責任、主要假設與必要取捨。

把發布計畫當成可調整的工作假設

計畫來源確認後，團隊需要把發布計畫整理成可以持續檢查與調整的工作假設。高層次的發布節奏可以先保留，近期工作再拆成較細的安排。

例如會員系統改版若預計分三個階段發布，第一階段可以明確安排資料清理、登入流程調整、測試環境準備與客服內部演練。第二、第三階段可以先保留在產品路線圖（Product Roadmap）或產品待辦清單（Product Backlog）中，等第一階段的技術驗證與使用者回饋出現後，再進一步細化。

後續檢查進度時，團隊要重新確認原先的計畫假設。相依團隊是否如期交付、測試資料是否可用、成員容量是否改變、技術驗證是否通過，都會影響原本的發布安排。只要其中一項條件改變，團隊就需要重新檢查範圍、發布節奏與利害關係人溝通安排。

發布計畫旁邊應保留計畫來源與主要假設。後續進度檢查時，團隊可以同時查看工作完成狀態，以及原先支撐日期、範圍與節奏的假設前提條件是否仍然成立。

• 制定發行計畫與風險評估：計劃只是開始，追蹤才是關鍵
• Release Strategy 發布策略：從 Disciplined Agile 看上線風險與部署選擇
• Tips for Effective Agile Planning