瀑布和敏捷不是什么新概念，這里只是個人在團隊合作中不得不去思考而做的歸納和總結，同時記錄自己曾經踩過的坑，新瓶裝舊酒，希望對你有所啟發。

瀑布模式

瀑布模型是比較傳統一種開發模式，特別是在2B的傳統企業，包括ERP，MES，WMS，CRM，OA，IBMS等系統當中可以經常見到他們的影子。現在這種模式仍然流行在一些大的項目或者是外包的一些項目當中。

如上圖所示，瀑布模型優缺點都很突出。

優點明顯：

階段清晰。從計劃到開發最后到上線運行，三個階段非常清晰。

時間順序。每個階段順序必須是從上到下，嚴格按照時間先后進行。

環環相扣。在每一個階段都必須有產出物然后才能進入到下一個階段進行。

黑盒模式。每個階段都有各自的角色和分工，各自只關心自己的任務。比如需求階段開發人員無需關注。

缺點突出：

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

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

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

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

歸納總結

根據以上分析，我們知道瀑布模式強調里程碑，重視文檔，強調分工，避免變化，凡事喜歡規劃和做計劃，但是代價就是拖沓笨重，反應遲鈍。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

敏捷模式

發展背景

敏捷開發借助互聯網浪潮開始流行起來，這也是2C的業務特點決定的，看過QQ和微信長大的人，這種體會特別深。互聯網產品不可能一步規劃到位，一般都是核心功能優先，比如微信，先是實現聊天功能，然后才是漂流瓶，錢包，小程序……

互聯網業務有何特點呢？借用雷軍的七字訣：專注、極致、口碑、快。

唯有專注才能聚焦能量，引爆燃點。

唯有極致才能排除競爭，爭取用戶。

金杯銀杯不如口碑。

天下武功唯快不破。

敏捷無疑更加貼近互聯網的這種業務需求，如果純用瀑布模式，估計黃花菜都涼了。敏捷還有一個更極致的做法，直接上PPT通過類似眾籌的方式進行開發，這種從群眾中來到群眾中去的個性化定制功能非常的有創意，如果眾籌的結果是沒有人感興趣，就可以直接否定該產品開發，可以避免無謂的“庫存”導致的開發壓力，節省巨大的成本浪費。

Scrum是什么

Scrum的意思是橄欖球運動的一個專業術語，表示“爭球”的動作。把一個開發流程的名字取名為一項體育運動，你一定能感受到其中的碰撞，沖突，激情。如果是這樣，Scrum如何能提高開發效率呢？敏捷開發是一種指導思想，Scrum和XP則是敏捷開發的具體開發流程，這里只選擇Scrum進行探討。

我們先來看下Scrum的三個角色：

產品負責人： 提供整體產品需求清單，確定產品邊界，功能組合圖譜，交付內容和日期。另外產品負責人有權拒絕開發團隊的開發成果。

開發團隊： 因為追求快，開發人員需要很強的自我管理能力，需要主動反饋，主動溝通。

流程管理員： 主要任務是疏通開發和業務的障礙，起到一個膠水的粘合作用，所以一旦開發進行，流程管理員有權拒絕需求的變更或修改。

Scrum是一個理想化的開發流程，前提條件是角色完整，分工明確，配合默契，溝通融洽。如果出現其中任何一個環節的故障，可能都會破壞流程的效率，比如，開發經理和流程管理員脾氣一樣倔強，脾氣互斥，那么整個效率就打折扣。我感覺在招聘人員，團結組建的過程中，我們務必要尋找氣味相投的人，這可以減少開發過程中的沖突。

Scrum和瀑布的本質區別是，一個以文檔為本，一個以人為本。在以人為本的團隊里，領導者的文化就是團隊的文化。如果領導者不透明，喜歡玩虛假，自大，官僚氣十足，這個團隊基本上就沒什么希望了。人必須是主人，有能動性，這個高度困難。因為如何讓團隊覺得公司的事是我家里的事是高度困難的，因為有些開發人員自己家的事都沒怎么認真過。想要做到這點，需要老板重視，否則中層領導我感覺一般都心有余力不足。

Scrum流程圖

首先需要確定一個產品需求列表 ，由產品負責人負責；

開發團隊根據列表，做工作量的預估和安排 ；

有了產品需求列表，我們需要通過計劃會來從中挑選出一個故事作為本次迭代完成的最小目標 ，這個目標的時間周期是1~4個星期，然后把這個故事進行細化，形成一個最小產品需求。比如該故事是登陸的功能故事，那么登陸的需求就要進行完整的細化工作；

開發成員根據故事再細化 成更小的任務（細到每個任務的工作量在2天內能完成）；

計劃紙牌怎么怎么用的呢？比如A程序員開發一個功能，需要5個小時，B程序員認為只需要半小時，那他們各自取相應的牌，藏在手中，最后攤牌，如果時間差距很大，那么A和B就可以討論A為什么要5個小時...

開發過程需要設置每日站會 ，每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報三個問題：A.你昨天完成了什么；B今天要完成什么；C.什么問題不能解決。

每個人回答完成后，要走到黑板前更新自己的sprint燃盡圖；

每日集成 ，也就是每天都要有一個可以成功編譯、并且可以演示的版本，可以機制CI,CD工具進行輔助開發；

當一個故事完成，也就是最小目標被完成，這時，我們要進行演示會議 ，也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個開發成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；

最后就是回顧會議 ，也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪sprint的產品需求中；

大家如果認真的看完整個Scrum的開發流程，會發現這個過程還真的是很完美，不妨可以用在你的團隊開發過程中。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

瀑布vs敏捷

對比一覽圖

瀑布敏捷是有邊界的，我覺得團隊在整體學習開發模式優劣后，需要對二者的邊界有一個清晰的認識，并在整個團隊上下都要達成一致的共識，否則后果可能會很嚴重。雙方的邊界如下圖所示

為什么說共識很重要呢？就我踩過的坑進行盤點，有如下幾個問題：

領導指揮不當 ：老板重文檔，覺得必須有文檔往下開發才是規范的，否則后面的工作都是一種浪費，因為你的頂頭上司不一定懂技術，這樣導致的結果是文檔沒出來前，底下人只能泡茶聊天了。

團隊效率極低 ：因為瀑布強調分工，各自為戰，所以有可能架構設計人員在等產品經理給需求文檔，開發人員在等待架構設計文檔，測試人員在等待開發成果，老板在等待產品交付。這里環環相扣，類似電流串聯工作，一個環節出錯，造成斷電，導致交付延期，后果可能就是互相推諉和扯皮，嚴重的話可能會引發爭吵，團隊分崩離析。

歸納盤點

就個人的經驗來看，瀑布和敏捷不是天然分割的，只是針對業務各有側重，應該是你中有我，我中有你的混合體。比如微信第一版的時候，聊天核心功能的迭代一定也有內部的小瀑布，如果沒有計劃-開發-測試-運維根本就無法進行下去。再比如瀑布，特別對創業團隊，剛開始人手不多，分工不明，架構師有可能要去畫原型圖，做需求調研；產品經理業務模糊，還在探索，各種短板和不足就像黑洞一樣存在你的周邊，你渾然無知。如果你一定要等整個調研完成，PRD文檔周全再做開發，估計也要歇菜。

既然各有利弊，那么中間的這個平衡點如何拿捏就非常重要，如何在前期設計的時候既能不過渡導致交付延遲，又能兼顧后續的演進和變化導致的修改可控，這需要開發經理豐富的實戰歷練和審時度勢的判斷力。

另外叨叨一下，開發模式貫穿做整個開發的生命周期，但是團隊各個成員包括產品經理，技術經理，架構師，開發人員對項目管理的流程理解各不相同，深淺不一，很難想象如果大家沒有達成共識，整個開發團隊的效率會有多高？但是現實當中，大部分團隊成員沒有開發模式的培訓和上下達成一致依然在進行著開發的工作……

審核編輯：劉清