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 種方式外，團隊可在經典專案管理模式下實踐更多協作方式，
團隊評估
從概念、模型、到應用實踐有了基本了解之后，在文末，我們提供了一個精簡的評估來進行敏捷與經典專案管理模式的匹配推薦，您可以基于團隊現狀進行勾選心算一下，粗略的參考，
- 需求穩定性
需求穩定 0 分——需求不穩定 10 分
- 業務與 IT 互動性
業務與 IT 互動難度高 0 分——業務與 IT 互動難度低 10 分
- 專案影響
關鍵系統關聯度高 0 分——關鍵系統關聯度低 10 分
- 系統模塊化程度
系統模塊化程度低 0 分——系統模塊化程度高 10 分
- 環境開放度
環境開放度低 0 分——環境開放度高 10 分
得分 0～20，我們更加推薦使用經典模式
得分 30～50，我們更加推薦使用敏捷模式
前往體驗經典專案管理
參考文獻：
- Jim Highsmith. "Agile Project Management”
- Project Management institute. 專案管理知識體系指南（PMBOK 指南）（第 6 版）
- 羅伯特·C·馬丁 著 申健 何強 羅濤 譯 《敏捷整潔之道》
- https://zh-chs.scrumguides.guru/
- https://en.wikipedia.org/wiki/Winston_W._Royce
- https://zh.wikipedia.org/wiki/Scrum#cite_ref-1
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/248026.html
標籤：其他
上一篇：再見，localhost！