Disciplined Agile（DA）的重用既有資產（Reuse Legacy Asset）提供設定資產、直接使用、演進可重用資產與複製後調整四種選項。
選擇時應比較需求落差、完整成本、修改波及範圍與交付條件，並確認誰負責開發、審查、發布及後續維護。
產品團隊可與共用團隊共同擴充資產，採用後仍需驗證版本更新是否影響產品。當重用投入超出可接受範圍，且已確認自建可行與維護人力，就可改採從零建置。
先驗證關鍵需求，再記錄選擇理由、責任分工與重新評估條件，讓採用決策有據可查。
重用既有資產（Reuse Legacy Asset）的決策範圍
從運用與增強既有基礎設施理解重用情境
開發新產品時，可以先盤點組織內已有的服務、資料、設計指引與作業程序。
例如，團隊準備推出會員平台，需要在註冊完成後寄送通知，而另一個產品已經有運作中的通知服務。團隊可以先了解這項服務的能力，再決定如何接入新產品。
Disciplined Agile（DA）的「運用與增強既有基礎設施（Leverage and Enhance Existing Infrastructure）」目標，協助團隊評估如何運用組織已有的成果，並依需求改善。
這裡的基礎設施涵蓋功能、資料、指引與流程材料，既有的通知服務也是其中一種資產。
「重用既有資產」決策點聚焦於團隊如何使用及調整選定的資產。
沿用通知服務之前，應先確認現有功能是否符合需求、哪些地方需要調整，以及調整後如何維護。
團隊應依需求差異與資產狀況，選擇適合的採用方式。
將需求落差、調整幅度與後續更新一起納入考量
假設既有通知服務已能寄送郵件，新產品還需要自己的品牌樣式與簡訊通知。若服務支援設定郵件樣板，團隊便能透過設定處理品牌需求。簡訊通知若超出現有能力，就應進一步討論擴充功能，以及由誰負責開發。
逐項對照需求與現有能力，有助於確認重用所需的工作。
調整幅度也會影響選擇。現有功能完全符合需求時，可以直接使用。需求可由設定滿足時，則需花時間理解與驗證設定。
涉及程式修改時，還要考慮與資產負責人的協商、測試及後續維護。修改範圍擴大時，應重新估算重用與從零建置的完整投入。
採用之後，原有資產仍會更新。通知服務修正錯誤或調整功能時，使用它的團隊需要確認新版本是否符合產品需求，並安排必要的驗證與發布。若團隊自行維護副本，還要處理原版與副本之間的差異。
這些工作都需要在採用前納入考量，如果專案結束後沒有後續發布計畫，應先確認由誰接手更新與維護。
重用既有資產的四種選項
設定資產（Configure asset）：以設定調整既有行為
設定資產是保留原始程式碼，透過修改設定資訊，讓資產呈現符合需求的行為。
例如，通知服務已經支援不同的寄件者與郵件樣板，新會員平台就能填入自己的寄件者名稱、品牌標誌與通知內容，沿用既有的寄信功能。
團隊可省下重新開發寄信功能的工作，將時間投入會員註冊等產品需求。
可調整的範圍由資產提供方預先設計的設定能力決定。提供方需要決定哪些行為可調整、設定如何組合，以及設定錯誤時如何處理。使用團隊也需要閱讀說明，確認設定生效的條件，並測試實際寄出的郵件。
設定資產的適用範圍，取決於資產已經開放哪些調整能力。如果通知服務只有郵件功能，單靠修改設定無法加入簡訊管道。團隊需要向資產負責人提出需求，確認是否能擴充，以及何時能提供需要的功能。
直接使用（Use as is）：採用現有能力
直接使用是採用資產現有的功能，不對資產進行修改。
例如，新會員平台接受通知服務既有的寄件者與郵件樣式，便可在註冊完成後，將收件者與必要資料傳給服務，由它完成寄送。
呼叫既有服務或採用商用程式庫，都是這類重用方式。
沿用經過使用與驗證的功能，可以省去重複開發的工作，也能減少組織內功能相同的程式碼。
團隊仍需確認資產在自己的使用情境下能否正常運作，例如註冊通知是否送到正確收件者，以及寄送失敗時能否取得處理所需的資訊。
直接使用需要接受資產現有的功能範圍。若產品要求專屬郵件樣式，而服務沒有提供相應設定，團隊就需要與產品負責人討論是否接受現有樣式，或向資產負責人提出擴充需求。
採用前應先確認這些差異，避免整合完成後才發現交付內容不符合預期。
演進可重用資產（Evolve reusable asset）：讓共同資產支援新需求
演進可重用資產，是調整既有資產以滿足團隊需求，並將變更提供給其他使用者採用。
例如，會員平台需要簡訊通知，團隊可以與通知服務的負責人合作，把簡訊管道加入共同維護的服務。完成後，其他產品也能使用這項新能力。
採用這個選項，需要協商需求與共同開發。通知服務的負責人必須考慮既有使用者，會員平台團隊則有自己的上線日期，雙方需要談清楚功能範圍、開發分工與發布時間。
如果新需求只符合單一產品的特殊規則，或超出服務預定支援的範圍，資產負責人也可能拒絕納入。
讓功能可供不同產品使用，還需要處理不同需求之間的差異，並確認修改後既有功能仍能運作。
若組織設有重用工程（Reuse Engineering）團隊，可以請其協助設計與整合。
可重用設計需要實際的使用情境來驗證。簡訊功能尚未有其他使用者時，應先確認已知需求，避免為想像中的使用方式加入大量設定與擴充機制。
複製後調整（Copy and tailor）：建立由團隊維護的副本
複製後調整，是建立一份既有資產的副本，再由團隊修改成需要的樣子。
例如，在允許複製與修改的前提下，會員平台團隊可以複製通知服務的程式碼，自行加入專屬的發送規則。
團隊能安排自己的修改時程，短期內也能沿用已有功能完成需求。
副本建立後，原版與副本便需要分別維護。假設原版修正了重複寄信的錯誤，副本不會自動取得修正。團隊需要追蹤原版變更，判斷副本是否有相同問題，再將修正套用到自己的程式碼並重新測試。兩邊修改的位置重疊時，合併還可能需要額外調整。
組織因此多出一份需要維護的相似資產，也可能增加技術債（Technical Debt）。
選擇複製後調整時，團隊也承接了副本的後續維護工作。若為了符合需求，必須大幅改寫既有結構，應把理解舊程式、修改、測試及日後合併修正的投入一起估算，再與從零建置所需的工作比較。
| 選項 | 是否需修改原始碼 | 維護責任歸屬 | 適用情境 |
|---|---|---|---|
| 設定資產 | 否，透過設定調整行為 | 資產提供方維護共用程式，產品團隊維護自身設定與整合 | 需求差異落在可設定範圍內，例如調整寄件者與郵件樣板 |
| 直接使用 | 否，沿用現有功能 | 資產提供方維護資產，產品團隊負責接入、使用情境驗證與更新評估 | 現有功能已符合需求，例如直接呼叫既有寄信服務 |
| 演進可重用資產 | 是，修改共同資產並提供其他使用者採用 | 資產負責團隊管理共用版本，產品團隊可參與開發與測試，新增功能的後續維護由雙方約定 | 需求適合納入共同資產，且能協調開發與發布，例如新增共用簡訊管道 |
| 複製後調整 | 是，修改副本 | 產品團隊負責副本維護、追蹤原版修正與合併驗證 | 需要自行調整功能與時程，且能承擔副本維護，例如加入產品專屬的發送規則 |
選擇重用方式的評估條件
需求符合程度與完整投入
評估重用方式時，先將產品需求與資產現有能力逐項對照。
以通知服務為例，團隊可以確認寄件者是否能調整、郵件樣式是否符合品牌要求，以及是否支援簡訊。
每項需求都應標明可直接使用、可透過設定滿足，或需要修改程式。尚未確認的能力，則安排一次測試或向資產負責人查證。
只有寄件者需要調整，而且服務已提供設定時，工作主要落在理解設定、接入服務與驗證結果。
新增簡訊管道則涉及功能開發，還要確認失敗處理與現有郵件功能是否受到影響。
兩種需求都使用同一項資產，所需人力與交付時間仍有差異。
估算重用成本時，應納入學習、整合、修改、測試與後續維護的工作。
團隊可以用同一組產品需求，比較各種可行做法需要完成哪些工作。
當修改範圍接近重新開發，或副本需要頻繁合併原版修正時，就應把從零建置（Build from Scratch）納入比較。自行開發的估算也要包含重做既有功能、建立測試及上線後維護的時間。
從零建置的評估指標與決策門檻
團隊可以在投入修改前，先約定何時重新評估重用方案。比較時，兩個方案應採用相同的必要功能、驗收要求與維護期間，例如上線後 12 個月。
工時以人日估算，等待審查與發布的時間則另外計入交付日期。
| 評估維度 | 具體量測方式 | 重新評估或停止重用的條件示例 |
|---|---|---|
| 修改投入 | 計算「調整原資產的開發人日 ÷ 自建相同必要功能的開發人日」，兩者的測試與整合工時另列 | 比值達 50% 時，啟動完整成本比較，並暫緩非必要修改 |
| 完整成本 | 加總兩案的開發、學習、整合、測試、遷移、部署及 12 個月維護投入，另列授權與執行費用 | 重用的完整成本已達自建方案，且沒有可確認的交付優勢時，評估改採自建 |
| 耦合與修改波及範圍 | 用一項代表性需求試改，記錄必須連動修改的模組數，以及需要共同發布的系統數 | 例如新增簡訊卻需修改 3 個以上與簡訊無直接關係的模組，或無法獨立測試與發布，應估算拆開相依關係所需的工作 |
| 驗證負擔 | 估算補齊關鍵流程測試所需人日，並記錄每次更新需要的人工驗證時間 | 補測試與回歸驗證超出事先保留的預算，且無法在期限內確認必要功能正確時，暫停採用 |
| 交付與維護可行性 | 確認最早可用日期、審查與發布等待時間，以及後續修正的負責人 | 在決策截止日前，仍無法滿足必要上線日期或確認維護承接者，應停止把重用列為已確定的交付方案 |
團隊可以定義當修改工時達到自建的 50%，作為重新評估的觸發點。例如，調整通知服務預估需 12 人日，自建所需功能預估需 20 人日，比值為 60%。
加入測試、整合與 12 個月維護後，若重用合計為 35 人日，自建合計為 30 人日，就需要進一步確認兩案的估算範圍與不確定性。
可各自列出樂觀、最可能與保守估算，檢查少算測試或低估維護是否會改變結果。
若代表性需求的試作已確認自建可行，自建方案也有明確的開發與維護人力，而重用方案在成本或必要交付條件上已超出可接受範圍，團隊便可記錄理由，停止新增重用相關修改，改排自建工作。
若兩案估算差距尚未釐清，可先限定一段查證時間，例如 2 個工作天，針對耦合最深或成本最不確定的部分進行試作，並在截止日依結果作出選擇。
已投入的探索工時另行記錄，後續決策比較的是從現在開始仍需投入的工作。
資產負責人的合作意願與交付安排
需要擴充共同資產時，團隊應先與資產負責人確認需求是否適合納入，以及雙方能投入多少人力。
資產負責人也需要顧及其他使用者，評估新功能是否符合服務方向、是否增加維護負擔，以及現有工作能否容納這項需求。
產品團隊可準備具體的使用情境與必要功能，讓雙方有依據討論範圍。
假設會員平台預計下個月上線，通知服務的簡訊功能卻排在下一季，團隊便需要協調這段時程落差。
如果首版能先以郵件完成必要通知，可以與產品負責人討論分階段交付。若簡訊是上線條件，則需進一步協調開發人力與發布時間，或重新評估其他可行做法。
尚未確認的功能與日期，應在交付計畫中標示為待確認事項。
若組織設有重用工程（Reuse Engineering）團隊，且由它負責共用資產，可以採取「共用團隊維護核心、產品團隊參與擴充」的分工。
共用團隊負責核心框架、共用介面、相容性審查與版本發布，產品團隊則提出使用情境、驗收條件與需要的日期，並負責產品端的整合驗證。
這項分工可以依組織情況調整。若重用工程團隊主要提供諮詢與協調，則需另外指定實際負責資產維護與發布的團隊。
提出共用需求後，雙方可約定由共用團隊排入開發計畫，或由產品團隊投入人力共同開發。
例如，新增簡訊管道時，產品團隊可以先與共用團隊確認設計，再提交包含程式、測試與使用說明的合併請求（Pull Request，PR）。
共用團隊審查對既有使用者的影響，確認符合要求後合併並安排發布，產品團隊再完成會員平台的整合驗證。
產品團隊貢獻程式碼時，也需要事先約定審查、發布與後續維護責任。需求討論時就應確認審查人員、預計回覆時間，以及合併後的錯誤由誰處理，再將共同開發排入交付計畫。
現有品質與技術債的處理範圍
即使資產已投入使用，團隊仍需確認它能否承接新需求。這些檢查常常會發現原有的技術債（Technical Debt），例如寄信功能缺少自動化測試，或郵件樣板與發送邏輯混在一起，修改品牌樣式就可能動到寄送流程。
團隊可以先查看與本次需求相關的程式、已知問題及測試結果，確認哪些地方會增加修改與驗證的工作。
重構（Refactoring）是在保留既有對外行為的前提下調整程式結構。若資產需要透過重構才能安全重用或擴充，就應將這項工作納入採用計畫。
例如，新增簡訊管道前，可以先整理共用的訊息處理邏輯，並補上必要測試，再加入新功能。這項工程活動需要另外估算與驗證，應一併放入採用方案的工作範圍。
重用資產要能償還技術債，需要安排具體的修正工作與負責人。對於會阻礙本次整合或造成錯誤的問題，雙方應確認是否在接入前修正，以及修正是否納入共同資產。其他問題則可記錄影響與後續處理安排。
例如，若既有重複寄信問題會讓會員收到多封註冊通知，就應先指定修正負責人，並把驗證結果列為接入前的檢查項目。
採用之後的版本更新與維護責任
以自動化回歸測試確認更新後的行為
通知服務更新後，原本正常的註冊通知仍需驗證。自動化回歸測試（Automated Regression Testing）會重複執行已建立的檢查，協助團隊確認修改是否破壞既有行為。
例如，團隊可以使用測試帳號完成註冊，檢查通知是否送往指定收件者、是否套用正確的品牌樣式，以及發送結果能否被會員平台正確處理。
資產提供方與使用團隊需要驗證的範圍各有側重。通知服務的維護者要檢查服務支援的寄送與錯誤處理功能，會員平台團隊則需要確認註冊流程、傳入資料與通知服務之間的整合。共用資產通過測試後，使用團隊仍需驗證自己的使用情境。
例如，服務能成功寄信，會員平台仍要確認傳入的是新會員的信箱，且郵件內容包含正確的啟用連結。
採用資產前，可以先確認現有測試涵蓋哪些行為，再為產品需要的情境補上檢查。之後更新版本時，就能重複執行這些測試，將結果作為是否採用更新的依據。
測試發現問題時，團隊應記錄使用版本、設定與觸發步驟，讓資產負責人能重現問題，修正後再執行相同測試確認結果。
為持續更新與專案結束後的維護安排負責人
共用資產會修正錯誤、調整功能，也會推出新版本。使用團隊需要有人接收變更資訊，判斷更新是否影響產品，並安排驗證與必要的發布。
可在採用紀錄中留下目前使用的版本、資產負責人的聯絡方式，以及團隊內承接更新的人員。若呼叫的是由其他團隊統一更新的服務，還要約定變更通知與驗證時間，避免等到服務更新後才開始檢查影響。
專案結束後，這些工作仍可能出現。例如，會員平台上線後開發團隊解散，通知服務隨後提供一項錯誤修正，卻沒有人負責評估影響或安排測試。若修正需要會員平台配合調整與發布，即使通知服務已經完成修改，產品也無法直接取得預期結果。
專案結束前，應確認後續更新由哪個團隊承接，以及是否有可用的維護時間與預算。
交接時，可以把資產版本、設定位置、測試執行方式及發布步驟交給承接團隊，並由接手人員實際完成一次驗證。自行維護副本的團隊，還需指定人員追蹤原版修正，記錄哪些變更已經合併、哪些仍待處理。每次收到更新資訊後，再依影響與處理急迫性安排工作，完成測試及必要的發布後，更新採用紀錄中的版本與處理結果。
結語：為重用既有資產（Reuse Legacy Asset）留下可執行的決策
先選一項資產驗證採用條件
團隊可以從下一項待開發需求著手，評估是否重用既有資產。挑選一項預計採用的資產，寫下產品需要的能力，再確認現有功能、可用設定與必須修改的範圍。
以通知服務為例，團隊可以先驗證品牌樣式能否透過設定完成，實際寄出一封測試郵件，檢查寄件者、內容與啟用連結是否符合需求。
取得驗證結果後，再與資產負責人討論適合的採用方式。能直接使用或透過設定滿足的部分，可以安排整合。需要擴充的部分，則確認開發範圍與發布時間。若考慮複製後調整，也要把副本維護列入工作。
先驗證會影響選擇的需求，再將確認過的工作排入交付計畫。仍未釐清的事項，應指定查證人員與回覆日期。
記錄選擇理由與重新評估的條件
採用方式確認後，可以用一份簡短紀錄留下選擇的理由，包含採用選項、驗證結果、需要配合的修改，以及後續維護負責人。
例如，團隊決定透過設定沿用通知服務，就可記下已驗證的郵件樣式、使用版本與更新聯絡窗口。接手人員可依紀錄了解當時的需求與判斷依據。
這份紀錄也可以約定重新評估的時點與條件，例如下一次新增通知管道時，重新檢查現有服務是否仍適用。若修改範圍擴大、共同資產停止維護，或副本已難以合併原版修正，就需要重新估算後續投入。
團隊可依產品情境調整紀錄內容，並在作出新決定後，更新採用方式、負責人與待完成的工作。
- 從混亂到穩定：極限編程（XP）的重構、TDD 與持續整合實踐
- 團隊各自最佳化，組織效率卻下降？與路線圖對齊（Align With Roadmaps）解析
- What do Reuse Engineers do?
- Technical Debt
- Agile Legacy System Analysis and Integration Modeling
