文章摘自：
瀑布模型是比較傳統一種開發模式，特別是在2b的傳統企業，包括erp，mes，wms，crm，oa，ibms等系統當中可以經常見到他們的影子。現在這種模式仍然流行在一些大的專案或者是外包的一些專案當中。
如上圖所示，瀑布模型優缺點都很突出。
根據以上分析，我們知道瀑布模式強調里程碑，重視文件，強調分工，避免變化，凡事喜歡規劃和做計畫，但是代價就是拖沓笨重，反應遲鈍。
網際網路業務有何特點呢？借用雷軍的七字訣：專注、極致、口碑、快。
敏捷無疑更加貼近網際網路的這種業務需求，如果純用瀑布模式，估計黃花菜都涼了。敏捷還有乙個更極致的做法，直接上ppt通過類似眾籌的方式進行開發，這種從群眾中來到群眾中去的個性化定製功能非常的有創意，如果眾籌的結果是沒有人感興趣，就可以直接否定該產品開發，可以避免無謂的「庫存」導致的開發壓力，節省巨大的成本浪費。
scrum的意思是橄欖球運動的乙個專業術語，表示「爭球」的動作。把乙個開發流程的名字取名為一項體育運動，你一定能感受到其中的碰撞，衝突，激情。如果是這樣，scrum如何能提高開發效率呢？敏捷開發是一種指導思想，scrum和xp則是敏捷開發的具體開發流程，這裡只選擇scrum進行**。
我們先來看下scrum的三個角色：
scrum是乙個理想化的開發流程，前提條件是角色完整，分工明確，配合默契，溝通融洽。如果出現其中任何乙個環節的故障，可能都會破壞流程的效率，比如，開發經理和流程管理員脾氣一樣倔強，脾氣互斥，那麼整個效率就打折扣。我感覺在招聘人員，團結組建的過程中，我們務必要尋找氣味相投的人，這可以減少開發過程中的衝突。
scrum和瀑布的本質區別是，乙個以文件為本，乙個以人為本。在以人為本的團隊裡，領導者的文化就是團隊的文化。如果領導者不透明，喜歡玩虛假，自大，官僚氣十足，這個團隊基本上就沒什麼希望了。人必須是主人，有能動性，這個高度困難。因為如何讓團隊覺得公司的事是我家裡的事是高度困難的，因為有些開發人員自己家的事都沒怎麼認真過。想要做到這點，需要老闆重視，否則中層領導我感覺一般都心有餘力不足 ;
scrum流程圖
首先需要確定乙個產品需求列表，由產品負責人負責；
計畫紙牌怎麼怎麼用的呢？比如a程式設計師開發乙個功能，需要5個小時，b程式設計師認為只需要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，如果時間差距很大，那麼a和b就可以討論a為什麼要5個小時...
開發過程需要設定每日站會，每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面匯報三個問題：a.你昨天完成了什麼；b今天要完成什麼；c.什麼問題不能解決。
每個人回答完成後，要走到黑板前更新自己的sprint燃盡圖；
大家如果認真的看完整個scrum的開發流程，會發現這個過程還真的是很完美，不妨可以用在你的團隊開發過程中。
瀑布敏捷是有邊界的，我覺得團隊在整體學習開發模式優劣後，需要對二者的邊界有乙個清晰的認識，並在整個團隊上下都要達成一致的共識，否則後果可能會很嚴重。雙方的邊界如下圖所示:
既然各有利弊，那麼中間的這個平衡點如何拿捏就非常重要，如何在前期設計的時候既能不過渡導致交付延遲，又能兼顧後續的演進和變化導致的修改可控，這需要開發經理豐富的實戰歷練和審時度勢的判斷力。
另外叨叨一下，開發模式貫穿做整個開發的生命週期，但是團隊各個成員包括產品經理，技術經理，架構師，開發人員對專案管理的流程理解各不相同，深淺不一，很難想象如果大家沒有達成共識，整個開發團隊的效率會有多高？但是現實當中，大部分團隊成員沒有開發模式的培訓和上下達成一致依然在進行著開發的工作……
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...