團隊衝突管理 2 大模型：用 TKI 與五階段衝突觀點提升協作品質
團隊衝突不是壞事，真正危險的是忽視衝突或在錯的階段用錯方式處理。本文結合湯瑪斯–基爾曼衝突模型（TKI）與 Speed Leas 的衝突五階段，說明如何判斷衝突正在升級，以及在各階段應採取的對應策略。透過場景案例（Planning、Retro、技術決策、跨部門協作），說明何時該合作、妥協、設界線，或尋求外部協助，協助敏捷團隊建立健康的衝突管理文化。
團隊衝突不是壞事，真正危險的是忽視衝突或在錯的階段用錯方式處理。本文結合湯瑪斯–基爾曼衝突模型（TKI）與 Speed Leas 的衝突五階段，說明如何判斷衝突正在升級，以及在各階段應採取的對應策略。透過場景案例（Planning、Retro、技術決策、跨部門協作），說明何時該合作、妥協、設界線，或尋求外部協助，協助敏捷團隊建立健康的衝突管理文化。
Product Backlog 是敏捷團隊的核心節奏工具。本篇完整解析 Backlog 的定義、動態特性、DEEP 原則、來源類型、EPIC／Feature／Story／MBI 的顆粒度拆解、排序方法、估算時機、AI 協作方式，以及常見反模式與改善做法，幫助團隊降低不確定性、提升對齊品質並建立穩定的交付節奏。
敏捷宣言（Agile Manifesto）不只是一份歷史文件，而是一種工作哲學。它的核心是：「以人為本、快速回饋、持續改進、擁抱變化」。敏捷強調：「流程應服務於人、文件應支撐理解、計畫應能調整、學習永遠持續」。本文將從宣言的起源、價值觀到實務誤解，一步步看見敏捷的真正精神與落地實踐方式：「在變化中創造穩定的價值」。
Retrospective 會議是敏捷團隊的學習節奏，也是持續改善的起點。它讓團隊定期停下腳步，回顧過去、提煉學習、制定行動。本文完整介紹回顧會的定義、流程、範本與心理安全技巧，幫助讓反思成為團隊文化的一部分，打造持續學習的敏捷團隊。
傳統的產品需求文件（Product Requirements Document, PRD）已不只是記錄需求的文件，而是讓團隊與 AI 一起對齊思考的「共創工具」。本文從 PRD 的核心結構、撰寫重點、範例、常見錯誤，到 AI 協作、敏捷整合與常見錯誤與改進建議，完整解析 PRD 的新角色：從「交付文件」轉變為「對齊思考」的工具。一份清晰、可解析、能被持續使用的 PRD，才是讓團隊保持一致的基礎。
在敏捷開發的世界裡，產品負責人（Product Owner, PO） 是連接願景與團隊的關鍵角色。他不只是負責 backlog 或需求管理，更是引導團隊理解「為什麼要做」與「做這件事能帶來什麼價值」的人。本文將深入介紹產品負責人的角色定位、核心職責、與產品經理及專案經理之間的差異，說明 PO 如何讓產品從「完成任務」轉變為「創造真正價值」。
每日站立會議（Daily Stand-up）是敏捷開發中最重要的日常會議，在固定的時間和地點，透過 15 分鐘快速同步進度、揭露問題、提高透明性與即時應變力，讓團隊保持節奏與協作效率，是導入敏捷文化的最佳起點。從這裡出發，讓團隊開始逐步學會用節奏推動改變，用協作驅動成長。
規格驅動開發（SDD）可以說是工程師版的「氛圍開發（Vibe Coding）」。藉由先撰寫完整的產品需求文件，再讓生成式 AI 依據文件內容，逐步完成各階段產出，最終以系統化方式建構出可執行的軟體。
Disciplined Agile 不是一套固定流程，而是一個協助團隊依情境選擇最適工作方式的決策工具箱。它整合多種敏捷、精實與傳統方法，提供「流程目標與選項圖」，幫助團隊做出有根據的選擇。
團隊層級的改進必須與其他團隊及部門協作對齊，否則只會出現「一邊快、一邊慢」的落差。DA 透過 Foundation、Disciplined DevOps、Value Streams 到 Disciplined Agile Enterprise 的四層結構，將戰略與執行緊密連結，確保策略目標能有效落地到日常工作。