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

在產品開發的初期階段，Scrum 和敏捷的方法真的有必要嗎？這是個值得探討的問題。敏捷和 Scrum 在軟體業界很普遍，很多團隊透過看板、每日站會、短衝（Sprint）和回顧會議（Retro）來落實敏捷的理念。然而，這些形式化的流程能不能真的解決實際問題？特別是在突發需求頻繁出現的情況下，可能需要更靈活的處理方式。

初期階段的挑戰：探索與定義基礎

在從 0 到 1 的產品開發過程中，關鍵在於快速探索和實驗，收斂出「理想中的產品」——一個真正解決用戶痛點並具有長期價值的產品。這個階段的主要工作是設計規劃和開發執行，但產品還處於不穩定階段時，是否需要導入 Scrum 的周期性制度，其實需要根據實際情況來決定。

我認為，這個階段更需要有經驗的團隊成員來主導方向。他們要能掌握專案的核心，建立必要的開發規範，比如命名規則、測試流程、自動化測試和部署等等。這些規範是為未來的開發文化打基礎的，比形式化的敏捷流程更為重要。

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

在產品初期，快速驗證概念和想法是最重要的。我們需要團隊內部的高度共識，而不應該盲目執行敏捷框架裡的所有流程。

例如，每日站會是有價值的，因為它能幫助我們快速對齊進度和方向。但像定期的計劃會議或回顧會議，未必是必需的。開會的重點應該放在解決問題和確認目標，而不是為了執行某種固定的流程。

在實際操作中，我們可能花一整週時間設計和驗證基礎架構，而這些會議更像是靈活的討論，目的是確保團隊方向一致。無論是用什麼形式，只要能達到溝通和協作的效果就可以了。

成員特質與團隊目標

初期階段的成功很大程度上取決於團隊的特質和目標是否一致。這個時期的團隊需要具備創新和探索精神，所有人要能夠靈活應變並投入實驗。如果有成員無法融入這樣的節奏，可能會拖慢整個團隊。

產品穩定後：調整工作方式

當產品進入穩定期，比如 1.0 版本上線，開始有用戶使用，並且 CICD 流程已經成熟時，我們需要根據新的需求來調整工作模式。

穩定期的開發節奏會更加規律，我們可能引入更多的敏捷實踐，比如 Sprint 計劃、回顧會議和里程碑規劃等。這個時候，Scrum 的實踐方式會更有價值，因為穩定的節奏能幫助團隊同步開發進度和目標。

以下是我們實踐的一些要素：

1. 看板（Kanban）：確保工作可視化，通常會追蹤兩個 Sprint 內的所有任務。我們使用 Excel 或簡單的工具來輔助管理，確保每個人都能鳥瞰全局。

2. 每日站會（Daily Standup）：關注當前的障礙和即將進入看板的任務，解決問題更高效。

3. 計劃會議（Planning）：對齊目標和分工，並確保每個成員理解需求。

4. 細化會議（Refinement）：拆解功能並進行估算，確保大型需求能夠分階段完成。

5. 展示與回顧（Demo and Retro）：每個 Sprint 結束時進行成果展示，前端、後端和文件更新都需要同步完成，確保所有人對進展有清楚認識。

6. 知識管理與文件同步：使用 Excel、Figma 或 Markdown 結合 Wiki 平台，記錄關鍵資訊，讓團隊成員能快速上手並保持靈活。

結論：形式為目標服務

敏捷和 Scrum 的核心是幫助團隊靈活應對變化並提升效率。在產品開發初期，重要的是設計適合當下情境的工作方式，而不是執著於敏捷的形式化流程。專注於快速驗證、團隊共識和基礎規範的建立，能讓團隊在不確定性中保持效率。

當產品進入穩定期後，可以逐步引入更多敏捷的元素，但前提是每項實踐都能真正為團隊和產品帶來價值。