使用者提出一項需求，可能需要多個功能配合才能滿足。例如，為了辨認客戶資料中尚未填寫的欄位，系統需要提供查看清單與未填寫提示功能。

安排交付範圍時，可以先確認使用者目前需要哪些功能，以及哪些功能可以延後提供。先完成的部分通過必要驗證、具備交付條件後，就能提供給使用者，再逐步提供其他功能，讓使用者及早取得價值。

拆分需求時，也要確認現有程式是否支援分步實作。有些部分可以直接分開交付；有些則需要先調整程式結構。這些調整即使沒有立即增加使用者可用的功能，仍可能需要優先完成。

確認用途與交付範圍

拆分功能，提早整合說明如何分開未填寫提示功能與匯出功能的程式，讓其他開發者先取得模組。接下來沿用同一個假想情境，回到客戶清單開發前的需求討論。

客戶清單最初規劃的功能包含查看資料、顯示未填寫提示、篩選與匯出，但尚未決定交付範圍與順序。Elvina 與 Mandy 需要與需求方確認使用者要完成什麼事，再決定先提供哪些功能。

使用者最先需要的是辨認待補欄位；篩選功能用來減少逐筆查找，匯出功能則用於把資料交給其他人。由於目前每次只處理少量資料，逐筆查看就能找出待補欄位，只要需求方接受延後篩選與匯出功能，第一次就可以先交付查看清單與未填寫提示功能。

以下用兩張時序圖比較交付順序，時間由上往下。每次交付前，都須通過必要驗證並完成交付準備。

一次交付

分批交付

注意： 如果使用者必須透過篩選功能才能找出待補資料，第一次交付就需要包含篩選功能。拆分時要保留完成用途所需的功能，不能只為了減少開發量而刪減。

反模式：以為縮減功能就能提高效率

我曾聽過一個案例是：產品經理為了趕交付期限，以為只要縮減功能、縮小工程範圍，就能提高開發效率、加快交付。他依據自己的經驗，沒有與利害關係人討論，就刪減了原本規劃的功能。

結果，開發者為了符合調整後不合理的規格，需要採取更多捷徑，留下技術債，增加實作與維護的負擔，也讓功能更難驗證。

產品端也沒有因此得到符合最初需求的功能，交付價值反而降低，使用者體驗也受到負面影響。

因此，縮減功能時，不能只看少做了哪些功能，就認定能提高效率。需要與利害關係人確認哪些功能可以延後、哪些用途與使用體驗必須保留，以及剩下的功能是否仍能滿足使用者目前的需要，也要與開發者確認調整後的規格是否會增加實作與驗證的負擔。

這也是我時常提醒產品經理的說法：

最好實作與維護的規格，就是符合合理需求的規格。

使用者故事與實作步驟

從使用者的目的描述需求，說明誰需要完成什麼事，以及為什麼需要，就是使用者故事（User Story）的表達方式。這段描述是討論的起點，實際範圍與完成條件還要一起確認。

使用者開啟客戶清單，逐筆查看欄位內容，再依「尚未填寫」的提示辨認哪些欄位還沒填。

開發者需要實作資料讀取介面、提示模組與清單畫面。這些程式可以分步開發與整合，但只有介面或只有畫面，都還不能讓使用者辨認待補欄位。它們必須一起運作，並符合約定的完成條件，這則使用者故事才算完成。

功能依賴與交付順序

Nathan 團隊規劃的匯出功能提供完整清單，不需要篩選結果，因此可以在篩選功能完成前先交付；篩選功能也不必等待匯出功能。

若需求方要求匯出的資料必須是篩選結果，匯出功能就需要篩選功能提供的行為。此時可以先交付篩選功能，再交付匯出功能，或將兩項功能一起交付。若希望匯出功能先交付，就需要與需求方確認，只提供完整清單是否仍符合當下的用途。

確認功能的完成條件

決定先提供哪些功能後，還要確認這些功能在不同情況下應該如何運作，才能判斷是否已經完成。

使用者開啟客戶清單後，要能看到可辨認每筆資料的客戶名稱，以及本次要檢查的欄位。Elvina 與 Mandy 需要在實作前和需求方確認以下情況的顯示方式：

• 欄位有內容時，顯示原本內容；數字零仍顯示為零。
• 欄位未提供、為空值或空字串時，顯示「尚未填寫」。
• 沒有任何資料時，顯示沒有資料的提示。
• 讀取失敗時，顯示失敗訊息，不能讓使用者誤以為資料已經查完。

兩人按照討論好的內容準備測試。Mandy 負責確認後端回傳的資料，Elvina 負責確認畫面顯示。

估算開發與驗證所需的時間

確認功能的完成條件後，要把實作與測試所需的時間一起算進去，才能安排開發，並判斷這次交付的範圍是否太大。

這個案例中的系統已保存客戶資料，但清單頁面尚未開發。Mandy 需要確認資料來源、讀取權限與介面內容；Elvina 則確認共用模組是否提供所需行為，以及畫面還要處理哪些情況。如果還不清楚需要修改哪些程式或做哪些測試，就先釐清，再估算所需時間。

估算不必精確到每個小時。若發現無法在短時間內完成實作與驗證，就再與需求方討論是否能縮小範圍，同時保留使用者需要的用途。

小結

Elvina 與 Mandy 按照前面確認的完成條件，驗證客戶清單的完整使用過程。若有不符合預期的地方，就先修正並重新驗證。確認通過、完成交付準備後，就能先提供查看清單與未填寫提示功能，不必等待篩選與匯出功能完成。

清單需求中的這些判斷，對應到使用者故事的六項特性，合稱為 INVEST：

INVEST 是這六個英文單字的首字母，用來協助團隊判斷拆出的需求是否適合逐步交付價值，不是依序執行就會自動得到拆分結果的流程。

需求拆分決定先提供哪些功能，程式拆分則讓實作能逐步整合。但有時程式已經可以整合，新功能卻還不能開放給使用者。接下來說明如何分開安排程式整合與功能啟用。

參考資料

• IREB：CPRE Glossary — Requirement
• Ron Jeffries：The Nature of Software Development
• Bill Wake：INVEST in Good Stories, and SMART Tasks
• Martin Fowler：An example of preparatory refactoring