2017年PMBOK® Guide（專案管理知識體系指南）9月7日出版後，我帶領100位志工一起翻譯這本書直到今年的3月3日出版時，許多人問起，為何不是應用純Waterfall（瀑布式）手法或是純Agile（敏捷式）手法，其實是有原因的。我做了以下三種專案管理手法的探討，在最後選擇Hybrid（混合式）手法，也得到了最佳解，在此分享。
傳統的Waterfall開發手法
專案管理的Waterfall手法，在1970年由Winston Royce發表。之所以被稱為瀑布式，是因為使用這個方法的專案工作流程，如瀑布般大量往同一個方向，由上而下地流動。
Waterfall是一種線性的設計手法，源起於製造業及建築業，因為這兩個產業都屬於高度結構化的設計，故特別需要預先的規劃，並強調文件及管理變更控制流程的重要性。如果有完整的工作文件，團隊成員可以透過文件熟悉工作流程、專案進行中，如果有成員退出，也不會因此流失知識；有變更控制的管理流程，則可避免專案後期提出的任何設計變更，造成昂貴的專案成本損失。
再細部一點說明，Waterfall手法的過程通常包含：概念、啟動、分析、設計、建構、測試、部署、維護……等階段，與PMI（美國專案管理學會）在PMBOK內所傳遞的專案管理五大過程：起始、規劃、執行、監控、結束，及十大知識領域：整合、範疇、時間、成本、品質、資源、溝通、風險、採購、利害關係人，概念相符。而不只PMBOK內容充分支持Waterfall所需的邏輯及預先規劃架構，專案管理國際標準 ISO 21500 及專案管理國家標準 CNS 21500，也採用PMBOK的五大過程及十大知識的架構展開。
因為這些特性，所以Waterfall又被稱為Plan-Driven（計畫導向）或Predictive（預測式），但名詞眾多，容易造成混淆，故PMI於2017年出版的PMBOK，將此方法正名為Predictive（預測式）。相較於敏捷，預測式較不適合應用於需快速因應客戶需求變動的軟體開發產業，但特別適用於：有固定需求和範疇、產品開發流程穩定、科技易於掌握的專案。
敏捷的Scrum開發手法
對於軟體開發產業而言，客戶在規劃階段時，腦袋中的需求及想要產出的軟體，可能還是很抽象的，無法像預測式手法規劃完整的工作文件，故以商業環境或市場需求的變化而發展、產品及價值導向、為開發過程提供更大靈活性的調適性手法就此誕生。
調適性手法包含了Scrum、XP、Lean、DSDM、Crytal family……等敏捷手法。其中最廣為人知的是Scrum體系（2018年Versionone統計佔70%，含Hybrid）。Scrum由Jeff Sutherland與Ken Schwaber聯合於1995年在Texas OOPSLA上發表正式論文。在此之前，1990年Ken Schwaber在其公司的進階開發方法使用Scrum，Jeff Sutherland則在Easel發展相同方法，將之取名為Scrum。兩人於1995年共同發表論文，並開發了Scrum Guide。
Scrum的架構是將一個專案切割成許多小的週期，每個週期約1~4週（典型2週），稱為Sprint（又名Iteration）。每個週期完成後，會提供Increment（增量）給客戶驗收，主要目的有三個：一是請客戶確認需求是否正確；二是確認開發方向是否正確；三則利用過程中與客戶互動，抓住客戶關注的焦點，就算增量驗收失敗，也僅有一個週期的時間及成本損失而已。
實施Scrum需要三個重要角色，分別是負產品成敗之責、設計產品及排序開發工作優先順序的產品負責人（Product Owner）；本身不管理團隊做專案，故不是PM，但擔任指導者協助成員使用Scrum的Scrum Master；及負責開發，將Increment展示給客戶確認的開發團隊（Development Team）。
開發團隊成員會盡量維持在3~9位，保持少量的原因，是可以讓成員充分發揮自我組織的效能。開發團隊每天會固定開15分鐘的站立會議，向彼此回報進度、規劃當天的工作量及所遭遇的瓶頸。
敏捷能因應市場需求快速調整，故雖然發展較晚，卻在當今這個時代引爆瘋潮。一個方法過於盛行，會讓人誤以為可以解決所有管理的問題（One size fits all），實則不然。在管理的領域裡，沒有所謂的萬靈丹，敏捷手法無法適用於需要嚴謹瀑布式開發手法的製造業或建築業。
Scrum本身有先天上的限制，故在許多公司無法順利地推廣開來。
一、開發團隊成員不適合分散在不同的地理位置或身兼數職。
二、成員需學習多種技能，以能處理各式各樣不同的任務需求。
三、推動Scrum時，如果包含無法由團隊掌握的外部因素，如：需等待廠商回件後，Scrum團隊才可接續工作，可能會導致整個進度延遲和失敗。
四、成熟或傳統的產品如果用Scrum手法開發，無法在單一的週期裡被充分測試，需要長期及大量測試的產品，如：醫療設備或汽車控制，比較適合長週期的瀑布式手法。
為何本專案不適用於預測式或敏捷式手法？
預測式及敏捷式開發手法各有其擁護的支持者，但也有缺點。綜合以上，預測式偏向工程及建築開發（硬實力），而敏捷式則適用於軟體開發（軟實力），各有千秋。依專案特性選擇適當的開發手法，會有較佳的結果，但以本專案來說，百位志工的協同運作，僅選擇以上兩種方法之一，皆不適合。因此我採用預測式+敏捷式的Hybrid混合式方法，將預測式與價值導向兩者的元素截長補短，讓兩者更加相輔相成。
在啟動本翻譯專案前，我們也有帶領50位志工，共同翻譯PMI的另一本官方書籍，《商業分析實務指南》（BUSINESS ANALYSIS FOR PRACTITIONERS: A Practice Guide）的經驗。當時採用單純的敏捷式手法，可是因為志工們都是第一次執行翻譯任務，對於翻譯流程沒有架構，也沒有預先規畫好的制度，於是團隊的產出多數呈發散狀態、翻譯產出的品質變異極大。
因為沒有做好源頭管理，故在收尾階段，有些不及格的翻譯產出，還由審查委員重新翻譯過，終審也花了半年的時間，方完成定稿。有了這一次的前車之鑑，這次百位志工的翻譯專案，我們在前期採用預測式的開發手法，充分完成預先的規劃，如：設計嚴謹的標準工作流程、對志工進行翻譯教育訓練及交流讀書會、設計明確的組織分工、名詞版本控制、卓越志工的表揚計畫等，方開始使用敏捷式手法運作專案。
混合式的Hybrid開發手法
混合式開發手法，結合預測式及敏捷式兩種專案類型的特性。PMI於2017年出版的Agile Practice Guide提出下面四種混合專案管理開發的組合：
一、前期敏捷式+後期預測式。將專案的生命週期區分成多個階段，前期採用敏捷式開發手法，後續以預測式手法推展開來。
二、同時使用預測式+敏捷式手法（如封面圖所示）。同一個專案，同時使用預測式與敏捷式的手法，可以讓團隊有足夠的時間，轉換為價值導向的敏捷式手法。
三、主要為預測式，小部分為敏捷式。專案主要為預測式，一小部分採敏捷式，適用於專案性質穩定、例行的工作手法中。採用敏捷式處理專案一小部分不確定及複雜的內容。如：工程公司建造工廠都使用相同的流程，但針對新建的客製化需求則採用敏捷式手法。
四、主要為敏捷式，小部分為預測式。專案主要採敏捷式手法，一小部分採預測式。這種手法可以應用於專案被要求得採用敏捷式手法時，最後以預測式手法來整合。如：整合由不同的敏捷外包商所開發的產出，因為這些外包商不能彼此互相整合，所以所有的產出都交付後需要再做單獨一次的整合工作。
本專案採用第二種混合式專案管理手法。使用預測式的預先規劃加上敏捷式的開發方法，大幅降低敏捷專案初期的風險，並有效提昇團隊產出品質的穩定性。透過預先規劃的嚴謹流程加上層層的把關，確保翻譯品質的嚴謹。如果本案例僅使用純預測式的手法，因為沒有敏捷式的每日會議及每週定期審查，還是無法在如此短的期程內完成專案；使用純預測式的規劃，則太過於繁重，不適合百位志工團隊每日訊息萬變的特性，因此採用混合式專案管理手法是最佳解。
探索更多來自 Roger 老師｜周龍鴻的Blog 的內容
訂閱即可透過電子郵件收到最新文章。