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

跑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,但不拘泥於特定工具,重點在於選擇能有效協助溝通與記錄的方式。若某些制度已無必要,即可廢除;而隨時需要時又能靈活啟用,保持高度彈性。

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

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *