資料團隊敏捷宣言、原則與指引 | 2025 台灣敏捷行動綱領

資料團隊的定義

有別於資訊科技團隊 (IT Team)以「資訊系統」與「程式碼」為主要交付物型態，資料團隊 (Data Team)以交付資料集 (無產品級保證)、資料分析結果、資料產品[註1]為主要交付物型態 。對資料團隊而言，「資訊系統」與「程式碼」係為產生交付物所使用之輔助工具。

[註1]資料產品型態包含原始資料集 (Raw Data), 整合資料集 (Derived Data), 演算法 (Algorithm), 輔助決策系統 (Decision-support), 自動化決策系統 (Automated decision-making)。

資料團隊現況困境

• 資料專案應用情境複雜
• 專案利害關係人識別困難
• 人員與資源的變動衝擊專案執行
• 專案訊息交換不足或缺少
• 技術變動頻繁、沒有慣行的解決方法
• 專案風險評估精確性低，專案實際成果落差大
• 品質控制困難

資料團隊特有的現況困境

• 專案情境複雜：資料專案(Data Project)跨越「業務(Business)」、「資料(Data)」與「資訊科技基礎建設(IT Infrastructure)」關聯部門，專案情境複雜度經常超越資訊專案(IT Project)。
• 專案利害關係人識別困難：資料專案是新型態專案，所以難以憑經驗正確識別專案成員與利害關係人。尤其是 Data Owner 特別難以識別，Data Owner 是來源資料(Source Data)的提供者。因為企業才剛開始推動資料治理(Data Governance)，而在資料產生和處理過程常涉及多方利害關係人，各方對原始與衍生資料的權利主張可能相互衝突，增加了識別和確認資料所有者的複雜性。
• 人員與資源經常變動衝擊專案執行：資料專案(Data Project)跨越「業務(Business)」、「資料(Data)」與「資訊科技基礎建設(IT Infrastructure)」關聯部門，專案成員多自然異動機率就會更大。
• 專案訊息交換不足或缺少：因為資料專案利害關係人識別困難，無法建立專案權責地圖，專案訊息就無法正確傳遞。
• 技術變動頻繁、沒有慣行的解決方法：Data & AI 領域的技術更新超越傳統資訊領域(IT)，目前大約以 2 年為週期劇烈變動。且資料專案的交付可以使用的技術眾多，Data & AI 技術的細分領域尚未有真正的霸主。
• 專案風險評估精確性低，專案實際成果落差大：資料專案的事前評估與指標設定，尚未有成熟方法論。加上 Data & AI 領域熱潮，經常可見脫離現實、”高大上”的目標出現在專案計畫中。
• 資料品質不易控制：資料專案中所使用之來源資料(Source Data)經常是其他專案的衍生物，且有類似製造業批次概念，與具有固定功能的「資訊系統」、「程式碼」不同。資料品質是個別資料專案的重要項目，且為企業內跨專案、跨部門之事項。

資料團隊的未來願景

• 資料團隊對資料專案價值有跨產業的共識
• 甲乙方組建有相同公轉週期的資料團隊
• 甲方當責建立資料專案權責地圖、精準識別 Business Owner, Product Owner 與 Data Owner
• 乙方當責作為資料專案引導者、提供資料專案執行框架
• 資料驗證測試左移、資料品質提升
• 建立各產業資料專案共通標準的可執行框架
• 資料團隊端對端協作順暢、達成共通目標

資料團隊敏捷宣言

藉著親自並協助他人進行資料供給，我們正致力於發掘更優良的資料產品開發方法。透過這樣的努力，我們已建立以下價值觀：

個人與互動	重於	流程與工具
可用的資料與一致的後設資料(Metadata)	重於	浮於形式的文件
多元角色協作	重於	合約協商
衝擊影響的回應	重於	遵循計劃

也就是說，雖然右側項目有其價值，但我們更重視左側項目。

資料團隊敏捷原則

我們遵守這些原則：

我們最優先的任務，是透過及早並持續地交付有品質的資料來滿足客戶需求。

竭誠歡迎在下個小週期改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，我們以資料產品促進客戶的競爭優勢。

經常交付可用的資料，頻率可以從數週到數個月，以較短時間間隔為佳。

Data User (資料使用者)、Data Owner (資料擁有者)與開發者必須全程參與專案。如果企業已經導入資料治理，Data Governance Organization 也應指派各功能代表全程參與。

以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。

面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。

可用的資料是最主要的進度量測方法。

敏捷程序提倡可持續的開發。贊助者、開發者及Data User(資料使用者)應當能不斷地維持穩定的步調。

持續追求高品質資料與優良資料服務設計，以強化企業敏捷性。

精簡──或最大化未完成工作量之技藝──是不可或缺的。

最佳的架構、需求與設計皆來自於能自我組織的團隊。

團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。

資料品質是跨部門的共同事務，在企業導入資料治理前，應推動跨資料團隊定期自省，以形成企業共通之資料品質標準。

資料團隊使用 Scrum Guide 時的附加指引

如何識別資料專案中的 Business Owner

• 核准資料專案預算、提供執行資源者，包含核准可使用之來源資料(Source Data)
• 有權限確立資料專案需求、核准專案目標層級的變更
• 有權限選任 Product Owner，授權 Product Owner 組成團隊
• 有權限核准資料服務上線者、評價專案最終產出

如何識別資料專案中的 Product Owner

• 應該每日與開發者協作，釐清資料專案範疇與內容，資料產品邊界的守門人
• 與開發者、Data User (資料使用者)、Data Owner (資料擁有者)共同確認資料規格(Data Spec)
• 選任開發者、Scrum Master
• 向 Business Owner 負責、應定期溝通與回報
• 有權限評價 Sprint Incremental、啟動下一個 Sprint

資料專案需求確認階段特有的 Sprint Backlog

• 確認來源資料與整合需求
  • 描述：確認業務需求所需的來源資料，並確定資料整合的方式。
  • 範例：確定需要整合來自 CRM 系統、網站日誌和第三方 API 的資料，並列出來源資料的格式、頻率和方式（例如批次處理還是實時同步）。
• 資料品質與一致性要求
  • 描述：確認資料的品質標準和一致性要求，以確保資料符合業務需求。
  • 範例：定義資料的驗證規則，如客戶資料不能有重複值、電話號碼格式應統一，並設立清理程序來處理缺失值或異常資料。
• 確認資料處理業務邏輯
  • 描述：確定資料在處理過程中的業務邏輯需求，例如資料轉換和計算規則。
  • 範例：在處理銷售資料時，需根據不同的地區和時間進行匯總，並計算區域市場的月度成長率。
• 資料隱私與安全需求
  • 描述：確認敏感資料的隱私保護要求，並制定合規策略（如 GDPR）。
  • 範例：在處理客戶資料時，需要對個人身份信息進行加密，並確保只有授權用戶能夠查詢這些資料，還要建立資料刪除機制以符合個人隱私法規。
• 資料可視化與報表需求
  • 描述：確認Data User(資料使用者)如何查看和使用資料，包括報表與可視化需求，資料新鮮度的即時揭露將影響使用者分析的結果。
  • 範例：業務部門需要儀表板，顯示每月的銷售趨勢、客戶分佈和產品銷售排行，這些資料應該以何種圖表類型和表格呈現，並允許過濾不同的時間範圍或地區。