我該選擇敏捷 scrum 或是傳統 waterfall 的專案管理方式?

我該選擇敏捷 scrum 或是傳統 waterfall 的專案管理方式?

前陣子公司一位新同事得知我有 PMP 證照後,突然沒來由地問我「執行專案時,該選擇敏捷 Scrum 或是傳統 Waterfall 的專案管理方式?」他說自己目前依照過去在學校以及前公司學習的經驗,埋頭專注把規格書寫好,以為交給工程師之後,過一段時間就能看到成果,沒想到兩周後工程師非但沒有任何進展,還反過頭來怪他規格不明確,也沒有經過排程,根本不應該插案處理,害他頓時顏面無光。我聽完他的苦水後,反問他三個問題:「你對 Scrum 和 Waterfall 了解多少?」、「你認為公司的管理和策略風格比較偏向哪一種?」、「你認為你的專案團隊屬於哪一種類型?」他搖搖頭,一臉苦惱的模樣......

1. Scrum 和 Waterfall

傳統的 Waterfall 手法,顧名思義,就像瀑布流下的水一樣,無法再回頭。Waterfall 的管理方式起源於 1970、以製造業為主的年代,因此講求效率與交期,特色是低變動,可透過標準化程序管理,所以執行上要求每個環節一棒接一棒逐一進行:工業廠房先處理原料,再進行加工,最後才是包裝與出貨;軟體公司則由企劃先撰寫規格,經過 UI 設計、系統分析,最後才交棒給工程師開發,越下游的工作者修改的彈性越小,多半只能聽命交辦事項行事。

由於資料科技漸趨發達,軟體與網路相關產業蓬勃發展,傳統的 Waterfall 不見得能夠滿足所有的管理需求,因此才有敏捷(Agile)管理的出現,其核心理念是「顧客導向、即時回應、快速迭代」。敏捷管理中最為人熟知的就是 Scrum 管理框架,Scrum 團隊約為十名成員左右,以一個接一個不超過一個月的 Sprint 週期(註1)進行開發,每個 Sprint 相當於一個小型的專案,必須有特定的交付產出,並且在下一個 Sprint 收集用戶回饋,予以修正,藉由這種快速進入市場測試水溫的方式,讓產品搶得先機。

Scrum 看似比 Waterfall 多了許多彈性,但為了能夠維持高效產出,團隊成員必須在 Sprint 運作週期內高頻率溝通,這對彼此作業模式不同的成員來說,是一項非常大的挑戰。同時,敏捷管理弱化了文件的作用,若開發過程中沒有妥善的版控管理,日積月累疊床架屋之後,可能會招來更大的技術債以及陷入規格混淆不清的窘境。

2. 公司的管理與策略風格

初步了解 Scrum 與 Waterfall 的差異後,PM 大致可以知道自己該具備什麼能力,以及該如何引導團隊進行,一般來說,Waterfall 容錯率較低,因此初期的規劃階段相當重要,PM 對於規格的掌控必須精準到位,這也是軟體公司 PM 通常具備技術能力的原因之一。Scrum 則更強調溝通,PM 要快速整合不同成員的意見,針對產品做出修正,對市場需求敏感度也相對較高。

然而,真正決定管理辦法的,往往不見得是 PM 本身。PM 除了領導專案前進之外,也需要對利害關係人與 sponsor 負責,不同的管理方式有不同的回報機制,如果 PM 無法理解公司老闆的管理風格,忽略了主管們的期待,那麼團隊運作得再好,可能也會不斷受到老闆的特別「關愛」。例如公司策略一向較為保守,希望產品經過多次琢磨與品質驗證後才能對外推出,但 PM 卻使用敏捷手法快速將產品推向火線,其結果大概可想而知。

3. 團隊的屬性

即便管理方法符合公司期待,團隊成員是否充分了解自己所扮演的角色?特別是 Scrum 這種講究溝通頻率的運作方式,假設有任何一位成員不肯拋棄過往的作業模式,堅持會議、溝通會影響自己的工作節奏,那麼 Scrum 預構築的敏捷陣型就會出現缺角,其他人很可能要耗費比以往更大的心力才能達到相同的成效。

在 Scrum 團隊中,主要的角色只有三種:Product Owner、Scrum Master(註 2)和團隊成員。成員中不論設計師、工程師、行銷人員等,基本上不會區分資深工程師、技術主管或任何階層高低的差異,凡事講求對等溝通,各自對專案目標提供最有效的建議,這對於較不擅長團體討論的人來說,需要一些時間適應,比起面對面溝通,他們更喜歡自己靜靜閱讀文件,咀嚼其中的細節。

當團隊中有成員無法適應管理方式,PM 務必及早調解與輔導,比起要求團隊交付管理所需的資料、進行表定的會議,更重要的是讓他們理解管理的精神與期望解決的問題,例如選擇 Scrum 管理框架是為了盡早進入市場取得用戶反饋、修正產品功能,因此需要精實、即時反應的開發隊形;選擇 Waterfall 則是因應專案的變化性小,可控性高,因此需要專注單一流程的進行,同時也讓完成任務的成員釋出資源,加入其他專案的運作。團隊成員越理解管理的目的,才越能發揮自身在專案中的最大價值。

事實上多數的企業不一定會執行純粹的 Waterfall 或 Scrum 管理方式,特別是軟體、資訊等講求迭代速度的相關產業,企業可能使用種混搭的形式,例如規劃與設計階段採用 Waterfall 產出初版的企劃規格文件,進入開發階段時,則採用類似 Scrum 的方式,每日召開會議確認進度,輔以腦力激盪等會議來彌補規劃階段的不足,討論出較佳的施工工法,最後再依 2-3 週的頻率安排每次開發的範疇,確保團隊維持固定的產出。

使用哪一種方法進行專案或產品開發的管理,並沒有絕對好或壞,每一種方式都有其優缺點,重要的是找到最適合自己和團隊的運作方式。我那可愛的新同事聽完我的說明後,點點頭說,「管理只是一種手段,還是要回歸問題的核心去思考,才能做出最佳的選擇,對吧?」

 

註1 : Sprint 中文翻譯為短程衝刺,意思是開發團隊固定一個週期完成某些任務並推向市場,一般約為 2-3 週。在 Sprint 開始前會先將產品需求切分為數個小範疇任務(product backlog),接著藉由排程安排每個 Srpint 可消化之任務(srpint backlog),Sprint 開始時經過 Planning Meeting 並估算工時,確認最終交付標的,接著就是一段密集的衝刺開發,期間每天需 5-10 分鐘的會議快速對焦(Daily Meeting),並在 Sprint 結束時召開 Review Meeting 確認成果,以及後續可改善的方向。每個 Sprint 結束後,緊接著就是下一個 Sprint 開始,不斷循環。

註2 : Product Owner,簡稱 PO,負責管理產品需求,並且向團隊說明需求的成員,也是最了解問題背後價值的人。Scrum Master,類似專案 PM 的角色,但更偏重於團隊管理、流程運作,以及協助團隊排除外在干擾的人,由於需要和開發人員密切合作,因此經常有具有技術背景的同仁擔任。

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。