跑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 的核心是幫助團隊靈活應對變化並提升效率。在產品開發初期,重要的是設計適合當下情境的工作方式,而不是執著於敏捷的形式化流程。專注於快速驗證、團隊共識和基礎規範的建立,能讓團隊在不確定性中保持效率。
當產品進入穩定期後,可以逐步引入更多敏捷的元素,但前提是每項實踐都能真正為團隊和產品帶來價值。