和大多數專案經理（以及組織）一樣，您可能也正在努力選擇最佳的交付方式。我們大多數人都知道，傳統方法不一定能保證成功交付，因此一直在尋找更好的做法。
近年來，敏捷或反覆式開發技術受到許多正面報導，被視為重大改善，能帶來更 成功的專案交付。因此，和現在大多數組織一樣，您們可能也在想，這些敏捷或反覆式開發技術最適合用在什麼地方，以及如何 同時提升專案交付的時效性與成功率。
簡單來說，反覆式開發技術會把專案功能分成小塊 (也就是一個個迭代) 來規劃、開發和實作。反覆式交付成功的關鍵在於，每個小塊都能在整個專案架構下，像較小的迷你專案一樣運作。因此，每個迷你專案迭代都能更精準地規劃所需工作量，而不是用兩年的計畫來估算兩週迭代的工作。此外，因為我們是以兩週為單位進行規劃，所以可以輕鬆調整接下來兩週的計畫，配合任何已識別的變更。
我想先暫停一下，說明一個非技術性的情境，在這個情境中，使用 敏捷方法 比傳統計畫獲得了更高的成功率。
我們用規劃一整天的活動來做例子——這就是專案。和大型專案一樣，這件事也有許多不確定性與風險：我們不知道午餐後會發生什麼事，可能會影響我們的計畫，但依照慣例，我們仍會為一天中每個小時都制定一份完整計畫，從早上 6 點起床到晚上 11 點就寢。
到了上午 9 點，因為交通耽誤了上班時間，我們已經落後進度；上午 10 點又被叫去參加緊急會議；到了中午，當天完成的唯一任務只是到達辦公室，而且連這件事也已經延遲。
現在，讓我們把這當成一個敏捷專案，而我們只規劃下一次迭代：準備出門 (也就是使用者案例: 洗澡、吃早餐，還有送孩子去上學)。這些項目都順利如期、如預算完成。
因此，我們有信心地規劃下一次迭代，也就是前往辦公室 (開車到公車總站、搭通勤火車到車站，然後轉搭市區公車到辦公室)。
這次執行得不太順利: 第一個使用者案例 (開車到公車總站) 因交通出現問題，所以我們把使用者案例改成開車到辦公室，並同意將另外兩個使用者案例從迭代計畫中移除。到達後，我們會規劃下一個迭代。但在規劃週期進行到一半時，又新增了一個使用者案例 (緊急會議)，而這個案例會佔滿下一個完整迭代。
最後，在午餐後，事情逐漸平穩，我們得以查看待辦清單並開始處理優先順序最高的任務；我們在下午成功完成了兩次迭代，處理最高優先順序的項目。
如果我們堅持原本的傳統計畫，就不可能完成這些最高優先順序的項目，因為通勤到辦公室所造成的計畫延誤，已經把它們延到隔天了。
敏捷或反覆式方法最擅長的，就是這種可因應業務需求變化的彈性，也正因如此，許多組織正在採用這種方法。但您的組織真的準備好全面採用敏捷了嗎? 根據我的經驗，要全面導入敏捷，常常會遇到許多阻礙，其中最明顯的就是已經根深柢固、而且常常與 敏捷方法不完全相容的組織政策。
例如，在專案核准前必須先有明確預算、效益實現說明和目標日期等政策，雖然很重要，但其實不太敏捷。同樣地，為了確保不影響現有作業而必須遵循的組織實作政策也很重要，但這些做法顯然不屬於敏捷。
因此，許多組織正苦於如何保留某些關鍵的「傳統流程」，同時改採反覆式方法。答案是混合式交付模型。專案的某些部分可以使用傳統管理方法交付，其他部分則可以採用反覆式方法。
我遇到最常見的混合式模型，是先支援傳統的專案啟動與規劃，接著進行一系列反覆疊代，並在發行時暫停以執行傳統實作活動，然後再進行另一系列疊代與傳統實作。
在這個模式中，我會建立以交付成果為基礎的傳統工作分解結構 (WBS)，用來識別組織在專案核准時所需的核心交付成果，例如專案章程、專案管理計畫和專案預算。
這些前期交付成果可以用傳統方法開發和管理，讓管理階層知道這個專案是適合的，也值得投入資源。
專案核准後，就可以轉為反覆式方法，在其中維護待辦清單，並在下一次迭代中選出優先順序最高的使用者案例加以完整開發。專案的視圖會從傳統的甘特圖，改為 可互動的拖放式看板，讓使用者案例能動態分配到各次迭代中。
產品擁有者可以隨時，通常是每天，新增、刪除和變更待辦清單中的使用者案例，以反映不斷變化的業務需求。
每次迭代結束時，我們會先暫停，回顧成功與失敗，並進行必要的變更以實作所需改進。接著，也是最重要的，我們會檢視產品待辦清單，並挑選最重要的使用者案例，作為下一次迭代的候選項目。這種做法可確保專案在任何時候都專注於最適當、價值最高的工作。
在每次迭代中，團隊可以使用敏捷原則，例如每日站立會議，並討論排定於目前迭代中的使用者案例狀態。如此一來，團隊就能完全掌控迭代內完成的工作，同時也能確保整體專案保持最新狀態，方便企業依據資源容量，以及組合和計畫狀態進行報表彙整。
敏捷原則的一個關鍵，是能以小規模發行的方式實作最終解決方案。這樣的好處是可以先使用初步功能，盡快實現部分預期的業務效益。
此外，還能及早驗證解決方案，讓任何調整都能輕鬆納入產品待辦清單中剩餘的使用者案例。因此，一旦迭代中完成足夠多的高優先順序使用者案例，專案就會回到傳統週期，並執行組織所需的標準實作工作。
這些發行與實作活動將使用傳統方法來規劃和控管，並確保在導入新專案時，遵循已定義的程序，以降低對現有作業的任何影響。
第一個發行完成後，專案會回到敏捷方法，並開始進行另一系列迭代，以持續開發剩餘的使用者案例。
雖然這種將敏捷與傳統方法結合的「分階段」做法最常見，但您也可以依特定的專案交付需求來組合不同方法。例如，我曾管理一個專案，該專案在將新產品導入高度受管制的產業時，需要極高層級的合規性與驗證。因此，我的大部分專案都是採用傳統方法來規劃和控管。
不過，專案中有一部分是商業智慧，當時我的公司正在分析系統產生的大量效能資料；這一部分最適合採用敏捷方法。針對專案的 BI 元件 (與傳統工作同步進行)，我們會選出可在三週衝刺中完成的最高優先順序使用者案例，並完成一個迭代。
由於這些使用者案例多半屬於探索性質，我們通常會建立新的使用者案例，進一步探索，或用來建立特定的效能報表。接著，我們只要將這些案例新增到待辦清單中，留待下一個衝刺再評估。
採用這個方法時，我有一份單一的專案排程，確保我能完成所有必要的報告與法規步驟，同時仍可用非常彈性的方式來開發專案中不受法規約束的商業報告元件。
將所有工作排在同一個排程中，讓我能用單一視角掌握這個專案中的所有進展:
敏捷是一種非常強大的專案交付方法，應該能為貴組織的整體專案交付工具組帶來顯著效益。它可以作為獨立方案使用，也可以納入分階段交付方法中，或整合到混合式交付架構裡。
關鍵在於採用能幫助貴組織達成交付成功的敏捷原則，同時遵循至今一直協助貴組織成功的傳統流程。
Steve Caseley 在 Microsoft Project 方面擁有超過 35 年的經驗，自從 Microsoft Project 首次推出以來，他一直是其積極使用者。他是數本與 Microsoft Project 及專案管理最佳做法相關書籍的編輯。他是 Sensei Project Solutions 的首席顧問，協助大型組織運用 Microsoft Project 專案組合管理 (PPM) 工具組達成卓越的專案交付。
商業見解與構想不會構成專業的稅務或財務建議。您應該連絡您的稅務或財務專家以討論您的情況。
關注 Microsoft 365