跑Scrum 或敏捷Agile於產品開發專案管理之心路歷程 初期到穩定期

產品開發初期：Scrum與敏捷是否必要？

敏捷和Scrum在軟體業已經非常普遍，許多團隊會透過看板、每日站會（Daily）、短衝（Sprint）和回顧會議（Retro）來實踐敏捷的理念。然而，這些形式化的制度是否能真正解決團隊面臨的挑戰，尤其是「隕石」（突發問題或需求）頻繁炸下的情境？或者，我們(PM或管理者)是否本身也是問題的源頭？這需要反思。

從 0 到 1 的探索與收斂過程

過去一年，我們經歷了從 0 到 1 的產品開發階段。這個階段有如大海撈針，我們透過探索和實驗來收斂設計出「想要的產品」，一個能夠解決問題、具長遠價值的產品。在這個階段，工作主要分為設計規劃和開發執行，但在產品尚未成熟且進入穩定維運的生命週期前，是否適合導入Scrum或敏捷中的周期性制度，值得探討。

我認為，這個階段更需要有經驗的成員主導專案方向。他們不僅需要掌握專案的核心要素，還需建立開發規範、命名規則和開發測試制度(還好我們有建立這個習慣)，自動化測試、建置與佈署(這時會很需要SRE團隊與OPS工程的支援)，為團隊的開發文化奠定基礎。換句話說，專注於定義初期的開發原則，比追求形式化的敏捷制度更為重要。

初期核心目標：快速驗證與凝聚共識

在產品初期，快速驗證概念與想法是最重要的。我們更關注如何凝聚團隊共識，而非盲目執行Scrum的形式化流程。這時期的Daily站會是有價值的，因為它能協助確認方向並快速解決問題；明確的里程碑設定也幫助團隊聚焦目標。但是否需要定期的Planning或Retro？實際上，開會的重點應該是溝通與共識確認，而不是形式化的流程。

我們花了大量時間討論與推演劇情，甚至有一整週都在設計與驗證產品的基礎架構。這時，「會議」更像是一種靈活的討論方式，目的是保持團隊步調一致。因此，無論是否有正式的Planning或Retro，只要能達到溝通目的，就已經足夠。

團隊目標與成員特質的重要性

在這個階段，團隊的遠期目標必須清晰，並以團隊成果為核心導向。團隊成員應具備創新、探索和創業家的特質。如果有成員無法融入這種工作模式，反而可能成為阻礙。這就像運動隊伍在比賽中追求勝利，所有人必須全力以赴，並保持一致的目標。

產品穩定後的開發節奏

進入產品穩定期後，POC（Proof of Concept）和快速驗證仍然是重要的開發方式。尤其是當功能需求超過兩個Sprint的範疇時，將任務拆解為可驗證的小單位並進行規劃，更能提高效率與質量。

分工與合作的平衡

在團隊中，分工與合作同等重要。任何工作項目都應包含整合的環節，並確保質量驗證（包含自我測試）的時間被納入估時過程。這不僅與成員的成熟度相關，也能提升專案的可交付性。定期進行Demo是個好方法，能讓團隊對自己的成果更負責。當團隊成員習慣隨時展示成果，就能自然而然地減少估時過多或過少的問題。

結論：形式服務於目標

敏捷和Scrum的核心在於靈活應對變化與提升團隊效能。在產品初期，不應執著於形式，而應根據當前的階段和需求，設計最適合的工作方式。專注於快速驗證與凝聚共識，保持靈活性，讓團隊更接近成功。

穩定期：專案管理與產品生命週期的敏捷要素

當產品進入穩定期，例如 1.0 版本上線，開始有客戶使用，CICD 流程穩定後，我們需要進一步調整工作模式，確保開發與維運節奏一致。這時，產品版本的週期規劃成為關鍵，可能是一週、兩週，甚至一個月，但無論週期長短，都需透過固定的節奏來同步團隊的開發進度與時鐘。

在這個階段，Scrum 的實踐方法可以發揮重要作用，但重點在於每項會議或流程是否能達到預期的價值。主持人（PM 或 Leader）需要思考每次會議的核心目標，而團隊成員，包括前端、後端、PM 和測試人員，則需主動參與、提出建議，而非僅僅作為執行者。

以下是我們團隊在穩定期實踐敏捷的五個要素：

1. 看板（Kanban）

• 隨時確保兩個 Sprint 內的工作能見度。不用便利貼，我們採用簡單但實用的方法，例如 Excel，來協助進行工作追蹤。這是從 PM 那裡學到的古老但有效的技巧， Excel可以直接對所有成員的Task以半日為單位進行展開，其實 Jira或其他專案管理能有效攤開的話也沒問題(但有時就是沒有鳥瞰圖，就是渾身不自在)

2. 每日站會（Daily Standup）

• 根據團隊需求調整每日站會的重點。通常，我們關注即將上看板的事項是否準備就緒，並針對重要問題進行協助或排除。

3. 計劃會議（Planning）

• 在每次 Sprint 的開始，我們對齊目標與分工。PM 會展示需求規格，團隊成員則需要主持討論、同步共識，並確保理解一致性。這時，成員應該積極提問，避免日後產生誤解。

4. 細化會議（Refinement）

• 計劃會後，我們會對工時進行估算，並更新看板或 Jira。若某功能涉及超過兩位關係人、任務需時超過三天，或功能開發橫跨一個 Sprint，則會建立里程碑計劃與檢查點。此過程會補充測試與驗證 Demo 的緩衝時間，確保每個開發與整合項目都有完整計劃。

5. 展示與回顧（Demo and Retro）

• 在 Sprint 結束時，我們強制進行成果展示。前端展示視覺效果與用戶案例，後端展示數據流與 API，文件也需完成同步更新並展示。這樣能確保所有關係人對成果有清晰的認知。

6. 文件同步與團隊知識管理

• 我們的 PM 習慣使用 Excel 和 Figma，結合 Wiki 平台進行資訊同步。技術規格文件則以 Markdown 搭配 Mermaid 圖表，方便適用於各種 Wiki 平台。若有共筆需求，也會採用 Google Docs，但不拘泥於特定工具，重點在於選擇能有效協助溝通與記錄的方式。若某些制度已無必要，即可廢除；而隨時需要時又能靈活啟用，保持高度彈性。

穩定期的核心，是透過靈活的敏捷實踐，平衡計劃與執行，讓團隊能專注於目標，並持續改進產品。形式應服務於目標，而非成為拘束團隊的框架。