最近看了一些敏捷開發的書籍，對敏捷開發有些初步的瞭解。今天就想來談談敏捷開發與傳統的項目管理之間的區別。
傳統的項目管理也稱爲瀑布流式管理，學過PMP的同學應該知道項目管理有5大過程組：啓動過程組，規劃過程組、執行過程組、監控過程組，收尾過程組。而5個過程組裏面還有49個過程，就拿範圍管理來說，我就需要做的是 規劃範圍管理->收集需求->定義範圍->創建WBS->確認範圍->控制範圍。例如：我們需要爲客戶開發一個項目，工作流程就是先與項目發起人一起定義項目章程，然後開一個項目啓動會議，確定這個項目的項目經理與這個項目的地位。然後開始規劃各種管理，編寫各種文檔（規劃範圍管理，規劃進度管理，規劃資源管理，規劃質量管理，規劃成本管理等等），所有的文檔規劃經過項目委員會評審確定後。就可以進入了項目的開發，這時候項目團隊成員就開始實施需求分析，程序設計文檔的編寫，經過評審確定，進入開發，進入測試，最後交付。這就是項目管理開發模式的其中一種：預測型開發。這種開發模式適合確定性非常高的項目，這種管理方式可以大大提高項目的成功。但如果使用在確定性不高的項目，就會是一個比較繁瑣的過程了。比如你在開發的過程中出現了變更了，就要開始走變更流程。如果變更影響了成本，進度，範圍都要提交到項目委員會進行討論確定要不要做，做就要更新上述中的所有文檔。如果是大變更大到需要推倒重做，那對程序員來說簡直的折磨煎熬。還有不知道你們注意到沒有，其實對於客戶來說，這其中的管理流程都是透明的。客戶是最後一個見到產品的人的，也是最能決定產品是否成功的人。這是一個很大風險，所以裏面就還有一個項目相關方管理，管理客戶的期望。如果客戶見到產品才發現不是自己想要的，那就很難受了，這就是一個不成功的項目了。當然啦，傳統的項目管理開發的方式可不止這一種。除了預測型開發意外，還有迭代開發、增量開發、混合開發。
因爲傳統的項目管理模式有了：無法一次性消化所有需求、懼怕需求變更、不斷重做。所以有了很多偏向敏捷開發，敏捷開發是歡迎變更，持續交付價值，快速反饋。在說敏捷開發的流程之前，需要先說說敏捷開發的幾個方法論：Scrum、極限編程、看板方法等等。我這裏分享的主要是Scrum，Scrum是個專有名詞，它沒有中文翻譯，沒有意思，也不是縮寫。只需知道這個單詞是專有名詞。Scrum有以下幾個概念：
Product Ower(PO)-用戶/客戶/代言人，就是可以做出業務決策的。就是可以確定需求及其優先級
Scrum Master-熟悉Scrum流程的人，指導和確保團隊以Scrum方式進行交付
Sprint-Scrum中對迭代的說法，一個項目或者產品的交付是由一個一個Sprint構成的。
User Story-用戶故事。具有業務價值的交付單位，一個項目或產品是由多個用戶故事構成的。
Product Backlog-項目的代辦列表，由用戶故事構成。
Sprint Backlog-一個Sprint的代辦列表，確定Sprint有哪些用戶故事，框定Sprint的開發範圍。
一個項目或產品是由很多個Sprint構成的，而Sprint的週期是固定的，一般都是2~4周，最好不要超過4周。在每個Sprint開始的時候，PO都會和IT團隊一起開會，PO會對Product Backlog中的故事進行排序，IT團隊對這些故事進行估算。因爲Sprint週期是固定的，IT團隊的成員數量也是確定。所以可以協商出哪些用戶故事放到Sprint進行開發，從而確定了Sprint的開發範圍。
接下來IT團隊圍繞Sprint Backlog中的用戶故事進行開發。IT團隊每天都會進行一次15分鐘左右的站會，站會只討論三個問題：昨天做了什麼？今天會做什麼？遇到了什麼問題？注意：暴露了問題後，私下再組織相關人員開會進行討論解決方案，而不是在站會上進行討論，站會只負責儘早暴露問題。怎麼解決站會後再組織會議討論。
在Sprint結束後，PO有會和IT團隊聚在一起開Sprint評審會議，IT團隊會對PO展示這次Sprint的交付成果，PO有任何反饋或者需求變更都可以作爲新的用戶故事放到Product Backlog中重新排隊，這就是敏捷開發應對需求變化的方法。縮短迭代週期就可以縮短反饋週期，即時整個項目的方向錯了也可以儘早發現和調整回來，儘可能降低損失。IT團隊可以在這個時候舉行回顧會議，審視哪些地方在Sprint做的好的，哪些地方需要調整的，然後訂下調整計劃，在下個Sprint中進行優化調整。
以上就是敏捷開發中的Scrum方法論的工作流程，與傳統項目管理是有挺大區別的。但是沒有說那個管理的方式是最好的，每個管理方法都各自有優缺點。不同項目情況針對的使用管理方法纔是對項目，對客戶最好的。最後給大家推薦一個關於敏捷開發的書《獵豹行動：硝煙中的敏捷轉型之旅》，這本可以幫助你瞭解敏捷開發的一些知識。