Moon：黛西黛西，為了應對市場的快速變化，我們團隊最近導入了敏捷的 Scrum，但同事們反應每天的站會都像在做無聊的進度報告，感覺大家很疲憊，而且每次排任務都搞得像打仗一樣，好混亂啊！

和黛西一起回到現場~

你是否也曾遇過這樣的場景？團隊花了數月時間， meticulously 地規劃、設計、開發一個「完美」的產品。所有的文件都鉅細靡遺，每一個步驟都照著甘特圖前進。但就在產品即將上線時，市場風向突然變了，競爭對手推出了一個更貼近用戶當下需求的功能，而我們的產品還在開發的路上，動彈不得。

這種傳統「瀑布式」開發一層層推進的方式，在過去需求明確、環境穩定的時代或許管用。但在今日這個需求快速變動、未來難以預測的市場，這種作法就像一艘笨重的巨輪，轉向困難，很容易錯失良機。

這時候，我們需要的是一種擁抱變化的能力，而「敏捷 (Agile)」正是為此而生的開發哲學。他能夠協助我們去應對：市場變動快速，難以預測未來趨勢 的痛苦。

面臨市場快速變化的窘境！這也讓許多產品經理和開發團隊，開始轉向「敏捷」。敏捷不只是一種方法論，更是一種**「心態 (Mindset)」** 。敏捷精神強調：快速迭代、擁抱變化、持續交付、頻繁回饋、以、團隊協作及產出有價值的產品。

然而，當我們真正開始實踐敏捷時，常常會遇到各種意想不到的挑戰。

相信許多敏捷實踐者都有過類似的經歷。今天我我們將一起探討敏捷，並一起來看看幾個敏捷常見框架，讓我們一起在 AI 的潮流下，發展屬於我們高度敏捷精神的 AI 工作流！

敏捷精神：擁抱變化，持續交付價值

敏捷並不是單指一種方法，它更像是一種思維模式 (Agile Mindset)。它的核心精神，可以從 2001 年發表的《敏捷宣言》中窺見一二。

敏捷的四大價值觀：

1. 個⼈與互動 重於 流程與⼯具
2. 可⽤的軟體 重於 詳盡的⽂件
3. 與客⼾合作 重於 合約協商
4. 回應變化 重於 遵循計劃

簡單來說，敏捷鼓勵我們**透過短週期的迭代與增量交付，及早將有價值的產品交到用戶手中，並根據市場回饋快速調整方向。**它不是要我們完全拋棄計畫或文件，而是將重心放在能創造價值的「人」與「可用的產品」上。

敏捷實踐框架 (一)：Scrum

Scrum 是目前最受歡迎的敏捷框架之一，它是一個輕量化的框架，用來幫助人們、團隊與組織，透過提供針對錯綜複雜問題的調適性解決方案來產生價值。Scrum 建立在經驗主義 (empiricism) 和精實思維 (lean thinking) 之上，相信知識來自經驗，並專注於減少浪費。

它把複雜的專案拆分成一個個短週期，稱為衝刺 (Sprint) ，通常為 2-4 週。每個 Sprint 開始前，團隊會從產品待辦清單 (Product Backlog) 中挑選最高優先級的需求來完成。Sprint 結束時，團隊會交付一個可用的產品增量 (Increment)，並透過檢視會議 (Sprint Review) 收集利害關係人的回饋。這個「計畫-執行-檢視-調整」的循環，確保了產品方向始終與市場需求對齊。

要理解 Scrum，可以記住它的「3-5-3」結構：

• Scrum 團隊與3角色 (Accountabilities)：

  • 產品負責人 (Product Owner, PO) ：負責最大化產品價值，管理並排序產品待辦清單 (Product Backlog)。
  • Scrum Master (SM) ：如同團隊的教練，確保團隊遵循 Scrum 規則，並移除障礙。
  • 開發者 (Developers) ：由一群跨職能的專業人士組成，致力於在每個 Sprint 中打造出可用的產品增量 (Increment)。白話說就是：負責執行任務，將待辦事項轉化為實際產品。

• Scrum 5 個事件 (Events)：

  • 衝刺 (The Sprint)： 固定的開發週期，1周到2個月。
  • 衝刺規劃會議 (Sprint Planning)： 決定本次 Sprint 的目標 (Sprint Goal) 以及要完成的任務。
  • 每日站會 (Daily Scrum)： 開發者每日 15 分鐘內的同步會議簡短會議，同步進度與討論障礙。
  • 衝刺審查會議 (Sprint Review)： 向利害關係人展示本次 Sprint 的成果，並收集回饋。
  • 衝刺回顧會議 (Sprint Retrospective)： 團隊內部討論如何改進流程、提升品質與效能。

• Scrum 3 個產出物 (Artifacts)：

  • 產品待辦清單 (Product Backlog)： 一份有順序的功能清單，列出產品需要改善的地方，其承諾為產品目標 (Product Goal)。
  • 衝刺待辦清單 (Sprint Backlog)： 由 Sprint 目標、該 Sprint 所選的任務以及交付計畫所組成，其承諾為衝刺目標 (Sprint Goal)。
  • 產品增量 (Increment)： 邁向產品目標的堅實踏腳石，必須是可用的，其承諾為完成之定義 (Definition of Done)。

優點：

• 高度適應性： 透過短週期迭代，能快速回應變化。
• 高透明度： 透過各項事件與產出物，讓所有利害關係人清楚看見進度與挑戰。
• 及早交付價值： 每個 Sprint 都會產出可用的產品增量，讓價值提早實現。

缺點：

• 導入門檻： 需要團隊成員（特別是 Scrum Master）對框架有深刻理解，否則容易流於形式。
• 對團隊自律要求高： Scrum Team 是自我管理的團隊，若成員缺乏主動性，成效會打折扣。
• 範疇不易控制： 若 Sprint Goal 不明確，容易導致範疇潛變 (Scope Creep)。

敏捷實踐框架 (一)：大型敏捷LeSS (Large-Scale Scrum)
當你的產品越來越成功，一個 Scrum 團隊（通常10人以下）已經忙不過來了，該怎麼辦？當產品規模擴大，需要 3 到 8 個團隊協作時，LeSS 就派上用場了。

LeSS 的核心精神是 「One Product, One Product Owner, One Product Backlog」。它將多個團隊視為一個整體，共同為同一個產品願景努力。它並不是要發明一套全新的複雜規則，而是將 Scrum 的原則應用在多個團隊的協作上。

想像一下，你有多個 Scrum 團隊，但他們共享同一個產品待辦清單 (Product Backlog) 和同一個產品負責人 (Product Owner) 。所有的團隊都在同一個 Sprint 節奏下工作，共同為一個產品願景努力。

LeSS 的目標是在擴大規模的同時，盡可能保持 Scrum 的簡潔與彈性，避免因組織擴大而產生的官僚與流程僵化。

優點：

• 保持 Scrum 的簡潔： 在團隊層面，依然是標準的 Scrum 運作模式，學習成本較低。
• 強化全局觀： 所有團隊都對著同一個產品待辦清單工作，能確保大家朝著「整個產品」的最佳化方向前進，而非各自為政。

缺點：

• 對 PO 要求極高： 一個 PO 要服務多個團隊，工作量與挑戰巨大。
• 跨團隊協調： 雖然 LeSS 提倡團隊間的自行協調，但在實務上，跨團隊的整合與溝通仍是一大挑戰。

痛點一：使用者故事太空泛，團隊「想像」不一致

在 Sprint 計畫會議上，產品負責人 (PO) 講得口沫橫飛，但工程師和設計師對同一個使用者故事 (User Story) 的理解卻南轅北轍。光靠文字描述，很難讓所有人對最終的 UI 介面有一致的畫面感。

解決方案一：

產品經理或設計師可以利用 Uizard 或 Google Stitch，直接輸入文字描述，例如：「一個有搜尋列和商品清單的購物頁面」，AI 就能在幾秒到幾分鐘內生成可視化的原型。Uizard 甚至支援上傳手繪草圖來生成數位設計。這樣一來，團隊就能看著具體的畫面討論，大幅減少溝通成本與誤解。

痛點二：設計到開發的鴻溝，耗時又易出錯

設計師在 Figma 裡完成了精美的設計稿，但工程師需要花費大量時間Coding，這個過程不僅耗時，還常常出現 1:1 還原的偏差。

解決方案二：

Google Stitch 和 Framer AI 正是為了解決這個問題而生。Stitch 不僅能生成 UI 介面，還能直接產出對應的 HTML 和 CSS 程式碼，雖然他現在因為是實驗性工具，有些產出跟我們想像的有出入，但工程師可以直接複製使用或進行微調，但是這個問題，透過一些 AI Agent 工具，就可以大大幫我們解決這個問題，這個後續我們提到 AI Agent 時會再跟大家介紹。但如果你只是要自己產生一頁式的網頁，這時候就可以用Framer AI。

痛點三：靈感枯竭，面對空白畫布的焦慮

每個 Sprint 都要有產出，但靈感不是水龍頭，說來就來。尤其在專案初期，設計師或產品團隊常會陷入「空白畫布焦慮」，不知道第一步該怎麼走。

解決方案三：

Google Stitch 、Framer AI 和 Uizard 在這方面表現出色。Google Stitch 可以透過比較大方向的 Prompt 就可以自己規劃相關細節，對於初步沒有想法時有很大的參考。Framer AI 透過輸入 Prompt，能快速生成一個包含版型、圖片、文案和配色的完整一頁式網站 (Landing Page)，雖然可能有些樣板風，但作為腦力激盪的起點綽綽有餘。Uizard 則被形容為「沒有靈感時的救命稻草」，能幫助我們輕鬆把腦內的模糊關鍵字具體化，讓團隊即使在靈感枯竭時，也能先生出一個 70 分的基礎版本，總比 0 分好。

痛點四：會議淪為形式

• 每日立會是團隊互相支援的機會，但常常變成每個人報告「我昨天做了什麼」的流水帳。
• Sprint Planning 前 PO 需要大量思考及撰寫文件，這些瑣碎的事情，都會拉走注意力，讓會議淪為形式而不自知。
• Sprint Review 或 Retrospective 中，使用 AI 會議助手進行即時語音轉文字、生成摘要和待辦事項，讓團隊能更專注於討論本身，而非忙於記錄。

解決方案四：

• 每日立會，透過 AI 彙整相關會議重點，重心可放在問題提出與排除。
• Sprint Planning 前，PO 可以提供產品願景與核心功能，讓 AI（如：Gemini、ChatGPT、Claude）自動生成一份結構完整的 PRD 草稿或標準的 User Story，縮短會議前準備時間，且所產出的內容相對完整。
• Sprint Review 或 Retrospective 中，使用 AI 會議助手進行即時語音轉文字、生成摘要和待辦事項，讓團隊能更專注於討論本身，而非忙於記錄。

總結一下，Scrum 為我們提供了一個靈活應對變化的基礎作戰單位。而當戰場擴大，LeSS 則告訴我們如何組織一支由多個 Scrum 小隊構成的敏捷軍團。

敏捷的核心是應對變化，而 AI 工具正賦予我們更快速、更直觀的應變能力。

Moon：黛西，聽起來敏捷也是一個很好的開發方式，只是在於我們能不能了解真正的敏捷精神。

黛西：沒錯，真的的敏捷並非只是形式上開開立會或是跑 Sprint ，重要的是把他的精神並落實在團隊中。

Moon：而且原來連敏捷都可以透過 AI 在各種流程中來協助我們~

黛西： 沒錯！AI 的價值不在於取代我們，而在於協助我們專注於那些真正需要人腦發揮創意和判斷力的地方。今天我們談了 Scrum 和 LeSS，下次，我們來聊聊其他也很受歡迎的敏捷框架，像是 Nexus 和 Kanban 吧！