在深入探討標題中的問題之前，我們首先需要明確您期望達成的最終專案目標是什麼。
想像一下您的產品在一個月、半年甚至一年後會呈現什麼樣貌。先對此進行描繪，這將有助於您建立觀點，並對專案的可預測性、靈活性、敏捷性、上市速度以及成本控制等基本要素設定期望。
在現今看來，採用瀑布式專案管理方法似乎有些不合時宜。尤其是當無數次的實踐證明，如果您想要快速應對市場變化，敏捷方法幾乎是唯一的選擇。然而，如果您的目標是在一年後交付一款功能明確且受限的產品，且您的團隊成員對於敏捷方法並不熟悉，那麼保守地選擇瀑布式方法也許更為穩妥。
並非所有情況都能如此簡單地做出決策。接下來，我們將探討如何更好地評估哪種方法更適合您的專案。
瀑布式專案管理模式是怎樣的？
以下是瀑布式專案實際運作的流程，而非深入探討那些眾所周知的定義：
整個過程可能需要數月甚至數年的時間。正如您所預料的，使用者只有在流程結束時才能看到結果。因此，經過漫長的等待，關鍵時刻（或是失敗時刻）到來了。
如果在此期間發生任何變化，導致最終產品與原先預期的有所不同，這便稱為變更請求。設計必須重新啟動、返工並重新批准。這將延長整個時程。每一次變更都需要重新啟動之前的整個流程。
另一方面，您擁有嚴謹的階段定義，每個階段的預算和時間都是固定的。即使您需要等待很長時間才能獲得初步成果，但如果過程中發生變更的可能性很小，這仍然是一個較好的選擇。
敏捷專案管理模式是怎樣的？
以下是敏捷專案的運作方式：
這只是一個簡要概述，但與瀑布式專案的差異已經顯而易見。快速回饋、適應、即時反映當前變化的需求，以及在最短時間內交付第一個有價值的產品，這些都是您在瀑布式專案中無法獲得的優勢。
敏捷與瀑布的比較
若缺乏合適的專案管理方法，專案很難取得成功。這意味著需要為參與專案的團隊制定流程、指標、評估和一般工作方式。
團隊需要了解應遵循的規則、里程碑的定義、何時達成目標以及如何衡量和評估成功。同時，相關利益者需要了解他們對專案的期望，以及何時能夠看到初步成果。
簡單來說，在雲端環境中運行的專案更可能傾向於採用敏捷方法（或者至少應該如此）。使用本地基礎設施的專案通常仍然偏好瀑布式流程。這是一個自然而然的結論。
雲端環境是從頭開始構建的，旨在適應不斷變化的環境。它可以盡可能快速地適應新的現實（透過各種「彈性」服務）。本地環境通常在一開始就已經預先定義。隨著時間的推移，很難對其進行改變，因此團隊在整個專案週期中使用確定的變數。
以下是敏捷與瀑布式方法的總結。
| 功能 | 瀑布式方法 | 敏捷方法 |
| 處理使用者需求變更 | 視為正式流程（變更請求）。可能需要重做，從而影響成本和時間表。 | 將變更視為標準流程的一部分，對成本或時間表沒有重大影響。 |
| 專案規劃和範圍 | 從一開始就定義範圍並堅持執行。階段嚴謹，並遵循最初的計畫。 | 對最終產品有清晰的願景，但允許變更。工作被組織成衝刺，任務的完成方式具有靈活性。 |
| 專案進度追蹤 | 追蹤每個階段的進度。一個階段的延遲可能會影響整個專案時間表。 | 在每個衝刺結束時透過展示會議追蹤進度。專注於可行的產品。 |
| 團隊協作 | 不同的人在不同的專案階段，互動有限。 | 跨職能團隊，團隊成員和相關利益者之間不斷溝通。 |
| 風險管理 | 基於階段進度的狀態追蹤。在遵守計畫的同時回顧性地應對風險。 | 注重主動解決團隊和活動之間的依賴關係。調整計畫以消除預計風險。 |
| 實施框架 | 傳統方法。 | 需要轉型實踐以適應敏捷方法。涉及改變習慣和心態。 |
然而，這種選擇將定義專案執行屬性的幾個方面。
#1. 專案需求和變更管理
定義選擇的最重要面向之一是如何處理使用者的需求。另外，如果之後需要變更已經商定的需求，其流程又是如何？
對於瀑布式專案，所有需求在一開始就由相關利益者定義並簽署；如果該狀態發生任何變更，專案會將其視為變更請求。它必須再次得到驗證、同意和確認。
在那之前已經完成的任何工作都必須重新檢視並重新開始。成本需要重新調整（因為這是原始合約未涵蓋的額外工作）。在最壞的情況下，甚至整個專案的工期也需要延長。
透過敏捷的設置，變更是受歡迎的。您將這些變更視為標準的日常業務。您同意相關利益者的觀點（可能是最新衝刺演示的結果），即為了維持專案的願景，變更至關重要。然後，您立即為下一個衝刺安排這些變更。
之前的工作也會隨之改變，從那天起，團隊將繼續根據新的需求進行工作。沒有時間或成本損失。您只需立即適應新的現實，並用新的計畫取代原來的計畫。根本不需要特殊的變更請求管理。這都是衝刺計畫的一部分。
#2. 專案規劃和範圍
正如您所預期的，瀑布式專案在一開始就設定並固定了所有範圍。您會圍繞此範圍制定專案計畫。然後，將專案持續時間劃分為特定階段（通常是分析、設計、開發、測試、部署、支援和維護），並圍繞這些階段固定團隊和資源。在專案時程的大部分時間，您的主要目標是在成本和時間安排方面盡可能堅持原來的計畫。
敏捷專案有最終產品的願景，而不是硬性計畫。最終狀態是明確的，但到達該狀態的路徑可以自由改變。此外，專案時程仍然是根據對需求的初步估計和專案團隊的容量負載經驗來定義和商定的。該計畫沒有單獨的階段。相反，每個衝刺本身就是一個小階段，其中包含團隊成功發佈增量產品所需的所有活動。
總之，瀑布式專案將這些變更視為需要解決的複雜問題（也是供應商獲得額外資金的機會）。相比之下，敏捷專案將變更視為正常業務，沒有額外的後果（除了更合適的最終產品）。
#3. 專案進度追蹤
瀑布式專案追蹤專案階段內計畫的進度。在分析階段完成之前，設計階段無法開始，在整個建置完成之前，測試無法開始，依此類推。
如果某些階段出現延遲，將會影響專案其餘階段的進度。這就是為什麼檢查每個階段內的活動並確保它們在此期間線性進展很重要。否則，您將增加延遲特定階段乃至整個專案的風險。
敏捷專案追蹤進度，主要是在每個衝刺結束時進行展示會議。可行的產品是衡量進度的主要標準。當然，您希望確保每個衝刺都以完整的衝刺內容結束。沒有或只有最少的故事會延續到下一個衝刺。
最終，如果您可以直接嘗試當前的產品增量，並立即向團隊提供非常具體的回饋，那麼更容易看到專案的整體進度。
#4. 團隊協作
這裡探討的是嚴格獨立的瀑布式活動與敏捷團隊所有各方之間持續協作的差異。
瀑布式專案通常有不同的人在專案的不同階段工作。他們可能在某種程度上互相協作，但他們仍然是不同的人群。可以說，幾乎是各自獨立的孤島。
敏捷團隊的定義在於溝通和價值。它還應該是一個能夠執行所有產品生命週期活動的跨職能團隊。團隊孤島是您不希望存在的。團隊和外部相關利益者之間不斷的來回溝通是成功的敏捷專案的基本定義。
#5. 風險管理
顯然，您希望有一個流程來追蹤專案在其時程內可能帶來的任何風險、問題或任何類型的障礙。
對於瀑布式專案，這將轉化為專案目前階段的狀態追蹤。標準的類似信號燈的狀態報告將顯示綠色（一切正常並符合計畫）、黃色（一些重要問題已經存在，但仍然清楚地了解如何解決它們）或紅色（意味著專案存在嚴重問題，可能會影響原始時程或預算）。
敏捷專案在這方面也有所不同。您並不是真正追蹤目標的進度。相反，您可以解決不同團隊和活動類型之間的依賴關係。目標是確保沒有團隊在等待另一個團隊進行進度活動。
當然，風險可能會出現，但解決方案必須改變未來的計畫，使風險消失，而不是在保留原來計畫的情況下找出風險的解決方案。
換句話說，專案的敏捷設置使用一切可能的方法來改變計畫，以避免面臨預計的風險，這意味著風險管理是主動的。對於瀑布式專案，您會回顧性地應對風險，並在堅持原計畫的同時嘗試在最短的時間內解決它們。
#6. 實施框架
瀑布式專案的實施策略顯然比敏捷專案的問題要少。通常，瀑布式方法是人們已經實踐多年的現狀。
另一方面，專案需要敏捷的轉型實踐來改變他們的習慣、心態和工作方式。這是一個困難且往往也是相當持久的過程。公司正在投入大量時間和資源來教導人們適應敏捷流程。
快速適應客戶不斷變化的需求所帶來的效益是顯著的，但改變人們的思維方式和整體工作環境是最困難的部分。
大多數時候，這也是保持市場競爭力的唯一途徑，因此對於那些成功的人來說，這種權衡會帶來巨大的成功。
最後的話
讓我們明確地說。除非您有一個非常保守的客戶，沒有很大的動力快速向生產交付結果（無論他們出於什麼原因），否則您最好的選擇是從一開始就開始對敏捷團隊進行建模。在當今世界，這確實是理所當然的事情。即使在傳統的本地系統設置的情況下也是如此。特別是如果團隊是新的或由原來的人員從頭開始，那麼轉變流程以與敏捷方法保持一致仍然是有意義的。
話雖如此，我仍然看到人們拒絕遵循這種敏捷流程或任何其他設置，但嚴格按階段特定的工作組織專案。他們遵循通常的方式，在特定的時間和預算內承包工作。然後，他們期望專案將遵循此設置，而不會偏離計畫和資金（產生各種結果，通常不是好的結果）。
這是他們有權做出的決定，但最終，有了這樣的決定，他們也決定留在過去。它可能在未來一段時間內對他們有用，但它不再起作用只是時間問題。
接下來，請參閱有關敏捷測試生命週期的詳細文章。