經典項目管理 OR 敏捷項目管理，我該怎麼選？

CODING 項目協同近期爲支持傳統項目管理推出了「經典項目管理」。至此，CODING 已全面支持敏捷項目管理以及傳統項目管理。那麼問題來了，「經典項目管理」和「敏捷項目管理」，我該怎麼選呢？本文將從理念差別、常見的研發模型、適用場景、實踐應用等角度來提供選型參考。

價值理念

首先來看看在理念方面，二者有何不一樣。項目管理的鐵三角是圍繞着範圍、成本和時間展開的。傳統項目管理的特色是強計劃驅動，需求範圍固定下來後纔可分配人員和時間，並在項目推動過程當中積極跟蹤和控制風險。敏捷項目是價值驅動的，在敏捷項目管理中，先固定了成本與時間，需求在交付期間頻繁細化，在固定的時間盒中優先交付高價值的需求。

傳統項目管理和敏捷項目管理的背後，也是預約義過程和實驗性過程的理念差別。預約義過程更注重計劃，控制變化。實驗性過程更加擁抱變化，經過快速實踐得到反饋後調整前進。PMBOOK 將項目的開發生命週期可分爲預測型（計劃驅動型）、適應型（敏捷型）、迭代型、增量型或混合型。

一個項目可能具有上述一個或者多個階段，在一家企業當中的不一樣團隊可能使用着一到多種項目管理模式。好比對於企業核心系統、外包式項目、交付性質強的項目會以傳統項目管理的方式進行，這些系統要麼需求變化少，要麼須要詳細的項目計劃和業務承諾。針對互聯網產品，其需求和用戶每每都不穩定，採用敏捷模式能夠更快地得到市場反饋，這種狀況下沒法也不適合進行長期細緻的計劃。

研發模型

瞭解理念差別以後，咱們來看看常見的研發模型。在傳統項目管理當中最多見的模型爲瀑布模型，敏捷項目管理中最多見的模型爲 Scrum 框架。

瀑布模型

業界廣泛認爲瀑布模型是由溫斯頓·羅伊斯（Winston Royce）於 1970 年提出的 。瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，以便於協做。瀑布模型將軟件生命週期分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

另外，瀑布模型很是強調文檔，前一個階段的輸出就是下一個階段的輸入，文檔是各階段銜接的惟一信息。從瀑布模型角度出發，在設計和記錄不充分的狀況下，若是團隊成員在項目完成以前離開，知識就會丟失，項目可能很難從損失中恢復過來。若是存在能夠正常使用的設計文檔，新團隊成員甚至是全新團隊都應該可以經過閱讀文檔來接手項目。

其實 Royce 最先提出這個模型時，並非爲了力挺瀑布。偏偏相反，他指出了瀑布模型可能會存在較大風險，由於在面對常常變化需求的項目時，瀑布模型毫無價值。

但也許意外每每也暗含着某種必然性，瀑布模型提供了一種結構化、易於理解的階段線性流程；它還在開發過程當中提供了易於識別的里程碑。因爲這個緣由，瀑布模型被用做許多軟件工程課本和課程中開發模型的開始示例。截止目前它依然是軟件開發企業使用的重要開發模型之一，瀑布模型可適用於要求和範圍固定的產品，產品自己牢固穩定且技術易於理解的項目。

Royce 真正提出的是改良版瀑布模型，他將原型設計放到了和瀑布模型並重的地位，而這個原型設計就相似於敏捷當中的一次迭代，經過一次迭代來驗證項目的可執行性，從而下降風險。接下來咱們來看看迭代思想是如何在 Scrum 當中被深入使用的。

Scrum 框架

Scrum 是一個解決複雜多變問題的框架。基於經驗主義和精益思惟，採納了一種迭代和增量的方法來優化對將來的預測性並控制風險，幫助團隊和組織創造價值。

1986 年竹內弘高和野中鬱次郎闡述了一種新的總體性的方法，他們將這種新的總體方法與英式橄欖球相類比：由一個跨職能團隊在不一樣的階段完成整個過程，團隊「做爲一個總體前進，把球傳來傳去」。該方法可以提升商業新產品開發的速度和靈活性。

這一類比在經歷了若干年的引用與演進以後，終於在 1995 年的在奧斯汀舉辦的 OOPSLA '95 （計算機協會 ACM 的一個年度性會議），傑夫·薩瑟蘭和肯·施瓦伯聯合發表了論文首次提出了 Scrum 概念。二人在接下來的幾年裏合做，將理念結合經驗、業界最佳實踐，造成咱們如今所知的 Scrum。2020 年二人發佈了最新版 Scrum 敏捷指南，感興趣的讀者可在相關閱讀中繼續查閱。

Sprint 是 Scrum 的核心，在這裏創意轉化爲價值。它們是固定時長的事件，爲期 1～4 周。前一個 Sprint 結束後，下一個新的 Sprint 緊接着當即開始。實現產品目標所需的全部工做都發生在 Sprint 內，包括 Sprint 計劃會議、每日站會、Sprint 評審會議和 Sprint 回顧會議。

Scrum 的生命力在於面對多變的市場時，它提供的小步快跑思路。產研團隊經過「把手弄髒」來獲得產品的快速反饋，從而改進產品。爲了可以保持緊湊的迭代節奏，Scrum 框架對項目管理過程中的信息和流程的「透明度」要求很高。透明使檢視成爲可能，常常性的「檢視」能夠快速發現項目中存在的問題。檢視使適應成爲可能，針對發現的問題，能夠快速的調整。Scrum 實踐可讓組織擁有應對變化的能力。

實踐應用

咱們並不認爲傳統項目管理模式和敏捷項目管理模式是全然互斥的關係，二者是有着各自的特色和適用的場景，而且兩種項目都有數字化的訴求。CODING 項目協同，除了敏捷管理模式，近期推出了經典管理模式。您能夠基於 CODING 實踐瀑布開發、增量開發、Scrum 框架等多種研發模式。咱們但願可以提供給更多組織與更多團隊，多樣化的項目管理解決方案，而不是一個錘子敲全部的釘子。

下圖中列出了在 CODING 項目協同中，敏捷項目管理模式與經典項目管理模式的工做流對比：

CODING 近期推出的經典項目管理，旨在解決傳統項目管理的五大難題：

• 統一協同，不一樣階段、職能信息在同一個平臺彙總；
• 全局視圖，計劃頁彙總項目進度，實時掌握多個迭代的進展與狀況；
• 項目進度，計劃、迭代概覽等頁面跟蹤進度，過程透明、進度可控；
• 資源管理，計劃頁可隨時查當作員任務、分配和協調人員；
• 質量管控，經過測試管理、缺陷管理等隨時跟蹤測試進度和缺陷修復進度。

除上述能力外，基於 CODING 的文件網盤以及Wiki 知識庫，團隊還能夠輕鬆管理傳統項目管理過程當中的文檔，可隨時經過 Web 直接訪問與分享，文件歷史可隨時回溯文件歷史版本；您還能夠在需求、任務等事項中，經過引用功能一鍵定位到相關文檔，省時省心。

經典項目管理模式的使用方式很是靈活，如下兩個例子可實踐大瀑布模式和小瀑布模式：

大瀑布

將項目定義爲有開始和結束時間的軟件開發項目。使用迭代將項目劃分爲 6 個階段：規劃、需求分析、軟件設計、程序編碼、軟件測試和運行維護。按時間前後順序依次完成。每一個階段完成後輸出的文檔（需求文檔、設計文檔、測試文檔等）可錄入到文件網盤以及 Wiki 中。完成最後一個迭表明明整個項目的完成。

小瀑布

在小瀑布的使用場景中，每個需求有 6 個狀態：定義、設計、實現、測試、運行、維護。設置需求的工做流，只有鄰接狀態纔可流轉，不容許跳躍。對應這 6 個狀態，將需求分別分解成 6 個階段的任務。在每一個階段的任務都完成後，需求進入到下一個狀態。

如下圖的「用戶管理」的需求爲例，目前需求分析、設計兩個階段相關的任務都已所有完成，正在處理編碼實現相關的任務，後續階段測試、運行、維護的任務都處於未開始階段。

除了以上 2 種方式外，團隊可在經典項目管理模式下實踐更多協做方式。

團隊評估

從概念、模型、到應用實踐有了基本瞭解以後，在文末，咱們提供了一個精簡的評估來進行敏捷與經典項目管理模式的匹配推薦，您能夠基於團隊現狀進行勾選心算一下，粗略的參考。

1 需求穩定性

需求穩定 0 分——需求不穩定 10 分

2 業務與 IT 互動性

業務與 IT 互動難度高 0 分——業務與 IT 互動難度低 10 分

3 項目影響

關鍵系統關聯度高 0 分——關鍵系統關聯度低 10 分

4 系統模塊化程度

系統模塊化程度低 0 分——系統模塊化程度高 10 分

5 環境開放度

環境開放度低 0 分——環境開放度高 10 分

得分 0～20，咱們更加推薦使用經典模式
得分 30～50，咱們更加推薦使用敏捷模式

前往體驗經典項目管理

參考文獻：

1. Jim Highsmith. "Agile Project Management」
2. Project Management institute. 項目管理知識體系指南（PMBOK 指南）（第 6 版）
3. 羅伯特·C·馬丁 著 申健 何強 羅濤 譯 《敏捷整潔之道》
4. https://zh-chs.scrumguides.guru/
5. https://en.wikipedia.org/wiki/Winston_W._Royce
6. https://zh.wikipedia.org/wiki/Scrum#cite_ref-1