瀑布型敏捷型項目管理

本文目錄一覽：

• 1、傳統項目管理VS敏捷項目管理
• 2、瀑布開發、敏捷開發的優缺點是什么？
• 3、.net敏捷開發和瀑布開發的分別是啥意思
• 4、敏捷項目管理相關知識
• 5、敏捷開發與瀑布有那么大區別么，瀑布開發就不能重視
• 6、敏捷項目管理與傳統項目管理比較

傳統項目管理VS敏捷項目管理

很多人都知道，項目管理領域有兩種管理方式：傳統項目管理和敏捷項目管理。很多人在團隊引入敏捷的時候，會有一個疑惑，傳統項目管理和敏捷項目管理的區別是什么？

在1969年以前，不管是制造汽車還是制造輪船，全世界的項目管理都沒有太多的章法和規則。

直到1969年美國成立了PMI組織，推出了PMBOK一整套規則、PMP認證后，全世界的項目管理就有了章法、有了規則。

直到現在，絕大部分行業還是使用這套標準項目管理方法——傳統的項目管理。

直到2001年，有17個軟件行業開發者在猶他州Snowbird滑雪勝地里聚會，他們白天滑雪，晚上喝酒聊天，聊著聊著發現，他們一致認為傳統項目管理不適用于軟件行業的，然后他們制定并簽署了行業最重要的文件之一：敏捷宣言。他們還在這里塑造了許多關于軟件的構想、開發和交付的方式，甚至是世界如何運作的方式。

所以敏捷這個概念是非常新穎的，2006-2007年期間，敏捷就被引入中國，騰訊就是最早使用敏捷的企業之一。同時，對于一些要考慮很多問題的項目，例如：“有沒有流量？”、“別人愿不愿意來”等等，所以他們需求是不確定的，按照以前傳統項目管理方法是行不通的，所以敏捷就誕生了。

傳統項目管理

通常采用的是瀑布式、部分迭代開發模式，要求在項目建設時，需求足夠明確、文檔足夠規范，迭代過程中需求變更越多、越晚，對項目影響越大，會影響到項目的交付質量。

敏捷項目管理

作為新興的項目管理模式，簡化了傳統項目管理的繁瑣流程和文檔。以 Scrum 為代表，歡迎需求變更，在客戶需求不明確的時候，以在較短的周期內開發出可用的軟件為目標，來幫助客戶描述自己的需求。迭代過程中的需求變更會加入到項目繼續迭代需求池，豐富項目的產品功能。

敏捷項目管理

聲稱要擺脫繁冗的流程制度文檔，但是對于關鍵的項目文檔，比如需求規格說明書等等，也是要求必須具備的。所以，敏捷項目管理的項目流程制度上的管理可以看作是對一套完善的項目管理流程制度的裁剪，只不過這個裁剪的尺度比較大，從而也對敏捷項目團隊成員的適應性，自主性提出了較高的要求。

具體的敏捷方法在每個迭代周期中都存在立會制度，燃盡圖、看板監控、計劃發布等，這些和PMBOK中對項目生命周期的五個過程組啟動、規劃、執行、監控和收尾的定義沒有沖突矛盾，實際上敏捷項目管理的這些措施可以看作是PMBOK項目生命期五個過程組執行的微縮版，區別在于敏捷項目管理的迭代周期，時間很短，在去執行過程中裁剪了很多規范正式的項目管理流程制度。

1、不同的管理方式適用于不同類型的項目，敏捷更適用于未知、不可知或持續變化的項目；

2、傳統的管理方式有如計劃經濟體制，敏捷有如市場經濟體制，適應變化的能力不同；

3、極大地縮短了用戶與開發者，預期目標與實施狀況，投資與投資回報之間的反饋回路；

4、將小型團隊轉化為自身命運的管理者，團隊接受挑戰，找尋應對挑戰的方法，發揮創意，避開工作障礙，而這一切都無法由中央控制及調度系統預先安排。

當處于快速發展的社會環境、面臨復雜而多變的項目時，傳統項目管理方式常常面臨進度延期、成本超支、質量不過關、客戶滿意度低、變更頻繁等問題，而敏捷項目管理可以說是在原本完善的項目管理流程制度上進行了尺度較大的裁剪，從而對敏捷項目團隊成員的適應性，自主性提出了較高要求，可以使項目經理將最大限度的項目資源和活動用于產生增值結果上。

瀑布開發、敏捷開發的優缺點是什么？

瀑布模型式就是是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。

一、瀑布開發

瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對后期需求的變化難以調整，代價高昂。瀑布式方法在需求不明并且在項目進行過程中可能變化的情況下基本是不可行的。

需求隔離：由于各階段的人員只能接觸到自己工作范圍內的東西，所以對客戶需求的理解程度高低不等，開發人員更像是定義為流水線上的工人。

變更代價大：既然叫作瀑布，就意味著不應該走回頭路。否則如果出現返工，付出的代價會很大。需求變更，編碼人員會很強的抵觸情緒。

束縛創造性：由于強調文檔管理，所以管理人員會比較喜歡，但是他束縛了開發人員的創造性。

周期漫長：整個開發持續的生命周期很長，需求和設計的時間會耗費特別多，有時候會占用三分之一甚至更多時間，這樣整個周期就會變長，大都在半年到一年左右的時間，所以更適合需求相對穩定的大項目。

二、敏捷軟件開發

敏捷軟件開發是基于敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱。自組織、跨職能團隊運用適合他們自身環境的實踐進行演進得出解決方案。

敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。

缺點：

很難進行準確的資源規劃

很難準確的定義“輕量的“或必要的文檔

很難把握整體產品的一致性

很難預測有限的終點

很難有效地進行度量

希望能幫到你，謝謝！

.net敏捷開發和瀑布開發的分別是啥意思

簡單的說，敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

系統開發方式眾多，項目管理者只需決定何時采取何種開發模式即可。瀑布開發模式就是一種最常用的開發模型，因為這種開發方式不但簡單直觀而且大大便利了項目管理的運做。

瀑布開發模式可以令項目管理人員非常方便地把整個項目置于自己的掌握之下。瀑布開發模式限制了開發期間團隊間的交互，評估起來相當方便，由于開發計劃穩定而且幾乎不會發生經常性的變化從而有效地簡化了項目開發的管理工作。

瀑布開發也有一些缺點，但是，在你初履新職，剛剛接手管理一個新的團隊，同時獲得了一種支持瀑布開發模式的解決方案的情況下，這種開發模式可以令你很快進入角色把工作開展起來，從而為將來采用更高級的開發方式做好了準備。

瀑布開發過程在政府項目中特別受到歡迎，在這樣的軟件開發項目中，其規劃階段超出了大多數企業部署階段的時間和力度。采用這種方式的其他用戶包括那些理解比較全面和深入的軟件項目，相關的解決方案對團隊而言非常熟悉，或者只需要小小的改動。

敏捷項目管理相關知識

客戶對持續創新和降低試驗成本的需求，標志著從預見性開發方式到適應性開發方式的重大轉變。不確定性、不斷縮短的進度以及迭代研究的需求不僅限于新產品開發。但只有創新和更快的開發還不夠，公司必須給客戶交付更好的、更符合需要的產品。雖然公司需要從高強度的產品開發工作中獲得成果，但不應該以質量為代價。 敏捷開發強調速度、機動性和質量 ，要創造高質量的產品且速度要快。為了實現這個目標，個人和團隊必須要有高度的紀律性，這里說的是自律而不是被迫遵守紀律。

構建創新產品、流程和商業模式需要有一個新的通用的管理方法和有針對性的項目管理方法。一個良好的敏捷項目管理需要實現5個關鍵的商業目標：

敏捷 是制造并響應變化從而在動蕩的商業環境中創造利潤的能力。

敏捷 是平衡靈活性和穩定性的能力。

制造變化需要創新：開發新產品、建立新的銷售渠道、縮短產品開發周期、為日益變小的細分市場定制個性化產品。此外，公司還必須能夠迅速響應競爭對手和客戶制造的可預見和不可預見的變化。

敏捷強調的是 態度 而不是流程，它是 氛圍 而不是方法。

團隊為何存在、要創造什么產品、為誰而創造以及如何共同工作，這些組成了敏捷項目管理的核心原則。 “在業績優良的團隊中，領導管理原則，而原則管理團隊。” 想要創造優秀的產品，就需要優秀的人才，想要留住優秀的人才，就需要有優秀的原則。

任務管理團隊管理：

團隊管理者 鼓勵團隊成員自我管理，通過完成拆分任務從而實現產品功能的開發。而 任務管理者 只關注任務的完成情況，并用其評估團隊是否遵循計劃行事。 團隊管理者 是幫助團隊（或者更廣泛意義的項目組）成員協同有效的工作從而保證他們能夠成功的完成任務。而 任務管理者 只是監督其成員，以確保他們在工作并能跟上計劃進度。

敏捷項目管理者應該具有的 核心價值觀 ：

提供客戶價值涉及三個重要話題：一是將重點放在 創新和適應性 而不是效率和優化，二是專注于 執行 ，三是 精益 思維。

傳統瀑布式開發方式在項目結束時交付價值，而敏捷項目可以快速并遞增地在整個項目期內交付價值。采用迭代、基于功能的交付方式，能在早期捕獲價值，而且通常可以極大地提高項目的投資回報率。

敏捷的 迭代 組成部分主要有：迭代、基于功能、時間框和增量。迭代開發是指要建造產品的部分版本，然后通過連續的短期開發以及評審和修改，拓展該版本。時間框強制迭代的結束，強迫在充分準備之前，制造出部分實體。增量開發是指建造的產品，在經過一次或者多次迭代后可以及時的被調用。

迭代長度分為三種——每周、每月和每季度。每周的迭代目標是維護和微小改進工作，每月的迭代目標是專項改進，每季度的迭代目標是重要的新功能的開發。

敏捷領導者領導團隊，非敏捷領導者管理任務。“敏捷”是社會技術運動，它有兩個推動力：一個是愿望——創造一種特定的工作環境；另一個是信念——適應性強的環境是向客戶提供創新產品目標的關鍵。

自我組織團隊 是敏捷項目管理的核心，他們結合了自由和責任、靈活性和結構。在自我組織的團隊中， 個人負責管理自己的工作量，根據需要和最合適的原則輪班工作，并對團隊效率負責 。

敏捷領導管理團隊，敏捷團隊管理自己的任務。敏捷領導闡明團隊目的和目標、產品構想、關鍵性能和約束，然后激勵團隊成員交付——團隊人員自己弄清楚如何完成任務的細節。這種方式賦予團隊靈活性和適應性，而不是盲目遵循既定的任務，而且這種方法可以鼓勵團隊自我組織，找到最好的方式實現目標。

傳統的項目管理者注重按計劃行事，盡量做到和計劃沒有出入；而敏捷項目領導者關注如何成功地去適應不可避免出現的變化。 適應性原則 可以概括如下：

有效的團隊在進行回顧時往往涉及四個領域： 產品 ——從客戶角度和技術質量角度； 流程 ——團隊正在使用的優秀流程和做法； 團隊 ——作為高績效團隊的工作情況； 項目 ——項目按計劃進行得如何。

開發優質的產品需要探索，而不是遵循計劃。探索和適應是創新的兩個特質——擁有探索未知世界的勇氣、擁有承認錯誤并適應形勢的謙遜。

一個組織要想保持快速增長，就必須明確績效評估方法。

傳統項目管理績效評估鐵三角 ：范圍、進度和成本。許多情況下范圍被認為是首要要素，而成本和進度是可變的。

早期衡量敏捷項目鐵三角 ：進度是固定的，范圍可以有變化。實質上，跟前一個評價方式是一樣的。

敏捷三角形 ：考量指標是價值（向客戶交付價值）、質量（需要向客戶交付可持續的價值）、約束（范圍、進度和成本）。這里，約束仍然是重要的項目評估參數，但不是最終要實現的目標。價值是目標，為了提升客戶價值，這幾個約束可以隨著項目的進展適時做出調整。

因此 敏捷項目評估 的3個目標為：

敏捷項目管理交付方法包括五個階段：構想、推測、探索、適應和結束。

敏捷開發與瀑布有那么大區別么，瀑布開發就不能重視

簡單的說，敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

系統開發方式眾多，項目管理者只需決定何時采取何種開發模式即可。瀑布開發模式就是一種最常用的開發模型，因為這種開發方式不但簡單直觀而且大大便利了項目管理的運做。

瀑布開發模式可以令項目管理人員非常方便地把整個項目置于自己的掌握之下。瀑布開發模式限制了開發期間團隊間的交互，評估起來相當方便，由于開發計劃穩定而且幾乎不會發生經常性的變化從而有效地簡化了項目開發的管理工作。

瀑布開發也有一些缺點，但是，在你初履新職，剛剛接手管理一個新的團隊，同時獲得了一種支持瀑布開發模式的解決方案的情況下，這種開發模式可以令你很快進入角色把工作開展起來，從而為將來采用更高級的開發方式做好了準備。

瀑布開發過程在政府項目中特別受到歡迎，在這樣的軟件開發項目中，其規劃階段超出了大多數企業部署階段的時間和力度。采用這種方式的其他用戶包括那些理解比較全面和深入的軟件項目，相關的解決方案對團隊而言非常熟悉，或者只需要小小的改動。

板BIOS被破壞的故障，可以插上ISA顯卡看

敏捷項目管理與傳統項目管理比較

傳統項目管理通常采用的是瀑布式、部分迭代開發模式，要求在項目建設時需求足夠明確、文檔足夠規范，迭代過程中需求變更越多、越晚，對項目影響越大，會影響項目的交付質量。

敏捷項目管理作為新興的項目管理模式，簡化了傳統項目管理的煩瑣流程和文檔。以Scrum為代表，歡迎需求變更，在客戶需求不明確的時候，以在較短的周期內開發出可用的軟件為目標，來幫助客戶描述自己的需求。迭代過程中的需求變更會加入項目繼續迭代需求池，豐富項目的產品功能。

1.管理流程差異

完整的項目管理流程可以分為5?個過程組:?啟動、規劃、執行、監控、收尾。

(1)?傳統項目管理

傳統項目管理要對項目的所有過程進行管理和風險把控，并要求在不同環節都要有文檔輸入和輸出。例如，PMBOK對項目整合管理的過程組做了文檔輸入和輸出的整理。但是，項目管理主要是對范圍、進度、成本、質量、人力資源、溝通、風險、采購和利益相關者進行管理，每個環節都存在啟動、規劃、執行、監控和收尾過程。

如果采用傳統的項目管理模式，每個環節都必須進行嚴格的規劃，一旦出現規劃以外的變更，則需要經過批準后才能執行。

(2)?敏捷項目管理

敏捷項目管理簡化了煩瑣的流程和文檔管理，主張團隊內部的面對面溝通和交流。以Scrum為代表，簡單、持續集成、不斷交付、價值優先、擁抱變化的原則在面對時刻變化的市場經濟和不斷發展的技術時變得十分友好。

在敏捷項目中，項目管理計劃分為不同的等級，可以用洋蔥圖來表示，也就是洋蔥計劃圖，如圖2-9?所示。戰略和投資規劃在敏捷項目管理的最外層，由更廣泛的組織管理系統來處理。由外往內，不斷切分項目計劃，最后，實現最小周期的可行性版本迭代。對復雜或不明確的客戶需求進行合理的分割，最終實現總體上的統一。

圖2-9洋蔥計劃圖

2.風險控制環節

項目風險是指在任何項目中都存在的不確定性，一旦發生，會對項目造成積極或消極的影響，如范圍、進度、成本和質量。

(1)?傳統項目管理

????傳統項目管理要求項目在規劃過程中規劃風險管理、識別風險，并且對風險進行定性/?定量分析，給出風險應對方案。雖然對已知的風險可以在被識別和分析后采取應對措施，但正是因為風險的不確定性，要求項目風險管理必須給未知風險或者已知卻又無法主動管理的風險分配一定的資源儲備。

所以，傳統項目管理會要求提供風險登記表，并且記錄風險應對措施在處理已識別風險及其根源方面的有效性，完成風險再評估和風險審計，直到風險被降到最低。

(2)?敏捷項目管理

敏捷項目管理不同于傳統項目管理，開發評估是以工作量為導向而非以時間為導向。所以，在進行開發任務評估時，采用的是相對估算而不是絕對估算，為風險留足了應對空間。同時，Scrum集合了一線人員，分享經驗，集思廣益，將小型團隊轉化成獨立的管理者，更有利于問題的解決。

敏捷項目管理在項目正式結束前交付的可用軟件是允許風險存在的，并且是根據風險的優先級來進行排期修復的。