傳統與敏捷專案管理：主要差異與鐵三角解析

傳統專案管理

傳統專案管理（瀑布模型）的方法是線性的，所有流程階段依序進行。此方法依賴可預測的工具與可預測的經驗。每個專案都遵循相同的生命周期，包括可行性、規劃、設計、建置、測試、生產與支援階段，如下方圖示所示。

瀑布模型與敏捷軟體開發

整個專案皆事先規劃，需求變動空間極小——如同瀑布模型、PMI 的 PMBOK 與 PRINCE2，皆具高度僵化與嚴格控制。它們明確劃分從開始到結束的各個階段，並假設您已擁有所有所需的需求與資訊。

此方法假設時間與成本為變數，而需求則為固定——這正是傳統專案管理常面臨預算與時程問題的原因。

敏捷專案管理

雖然傳統系統高度著重於事前規劃，成本、範圍與時間等要素至關重要。相反地，敏捷則強調團隊合作、客戶協作與彈性。

敏捷否定了傳統專案管理，認為其枯燥、受限，不適合快速變化的現代世界。敏捷專案管理是迭代式的，旨在持續整合使用者反饋與每次開發迭代中的持續發行，如上圖所示。每一項任務的產出皆是您向利害關係人銷售的產品。團隊與工作流程皆以創造對客戶直接有用的成果為核心。

傳統或敏捷——如何選擇？

根據 Standish Group 於 2011 年發布的 CHAOS 報告，敏捷專案的成功率是瀑布模型專案的三倍。下圖顯示了 2002 年至 2012 年間研究的具體結果：

瀑布模型與敏捷專案的成功率

傳統與敏捷之間的差異

下表總結了 Scrum 與傳統專案管理模型之間的許多關鍵差異。

變更成本

傳統上，軟體專案的變更會被避免，因為專案後期變更成本會大幅增加。敏捷軟體開發承認變更是不可避免的，且過度投入前期規劃是不切實際的。這一點在敏捷宣言的四個價值觀之一中明確表達：

「比起遵循固定計畫，更重視回應變更的需求。」

敏捷挑戰此觀念，並主張變更成本可能相對平坦，如下圖所示：

傳統與敏捷中的變更成本

專案管理中敏捷與傳統的鐵三角

傳統上，專案管理的成功與管理範圍、時間、成本和品質等限制的能力相關，如下圖所示。這是一個廣為人知的隱喻，暗示專案經理應合理地平衡這些限制。

敏捷與傳統專案管理中的鐵三角

傳統鐵三角的問題在哪裡？

例如，透過增加預算或縮減範圍，專案可以更快完成。同樣地，擴大範圍通常需要相應增加預算和時間。若不調整時間表或範圍而減少預算，品質將會下降。然而實際上，各限制條件之間的權衡並非總是可行。例如，在資源充足的專案中投入更多資金（和人力）反而可能拖慢進度。此外，在表現不佳的專案中，若不對品質造成負面影響，很難改善預算、進度或範圍。

因此，傳統的鐵三角明顯不足以作為專案成功的模型，因為它忽略了成功的重要面向，包括利害關係人影響、學習成果以及使用者滿意度。

敏捷鐵三角——一種范式轉移

在傳統方法中，三角形通常如下方左側所示。如您所見，產品需求具有固定的範圍。因此，為確保產品能提供所有所需功能，我們需要在資源（及預算）和時間表（截止日期）上具備彈性。若我們必須確保產品包含初始需求規格中所描述的所有功能，可能需要將發行日期延後數月甚至更久。

在敏捷觀點中，時間表是固定的（在Scrum中，這透過時間盒 迭代以及固定資源來達成）。因此，當事情不如預期時，必須縮減範圍。但在敏捷方法中，即使必須在範圍上妥協，我們仍確保從產品待辦事項清單中交付最高優先順序的項目，以最大化專案所產生的價值。

敏捷情境下的鐵三角