軟件開發模式：瀑布與敏捷

瀑布和敏捷不是什麼新概念，這裏只是我的在團隊合做中不得不去思考而作的概括和總結，同時記錄本身曾經踩過的坑，新瓶裝舊酒，但願對你有所啓發。

瀑布模式

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

 　　

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

優勢明顯：

• 階段清晰。從計劃到開發最後到上線運行，三個階段很是清晰。
• 時間順序。每一個階段順序必須是從上到下，嚴格按照時間前後進行。
• 環環相扣。在每個階段都必須有產出物而後才能進入到下一個階段進行。
• 黑盒模式。每一個階段都有各自的角色和分工，各自只關心本身的任務。好比需求階段開發人員無需關注。

缺點突出：

• 需求隔離。因爲各階段的人員只能接觸到本身工做範圍內的東西，因此對客戶需求的理解程度高低不等，開發人員更像是定義爲流水線上的工人。
• 變動代價大。既然叫作瀑布，就意味着不該該走回頭路。不然若是出現返工，付出的代價會很大。需求變動，編碼人員會很強的抵觸情緒。
• 束縛創造性。因爲強調文檔管理，因此管理人員會比較喜歡，可是他束縛了開發人員的創造性。
• 週期漫長。整個開發持續的生命週期很長，需求和設計的時間會耗費特別多，有時候會佔用三分之一甚至更多時間，這樣整個週期就會變長，大都在半年到一年左右的時間，因此更適合需求相對穩定的大項目。

概括總結

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

敏捷模式

發展背景

　　敏捷開發藉助互聯網浪潮開始流行起來，這也是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的開發流程，會發現這個過程還真的是很完美，不妨能夠用在你的團隊開發過程當中。

瀑布vs敏捷

對比一覽圖

　　瀑布敏捷是有邊界的，我以爲團隊在總體學習開發模式優劣後，須要對兩者的邊界有一個清晰的認識，並在整個團隊上下都要達成一致的共識，不然後果可能會很嚴重。雙方的邊界以下圖所示

　　

　　爲何說共識很重要呢？就我踩過的坑進行盤點，有以下幾個問題：

• 領導指揮不當：老闆重文檔，以爲必須有文檔往下開發纔是規範的，不然後面的工做都是一種浪費，由於你的頂頭上司不必定懂技術，這樣致使的結果是文檔沒出來前，底下人只能泡茶聊天了。
• 團隊效率極低：由於瀑布強調分工，各自爲戰，因此有可能架構設計人員在等產品經理給需求文檔，開發人員在等待架構設計文檔，測試人員在等待開發成果，老闆在等待產品交付。這裏環環相扣，相似電流串聯工做，一個環節出錯，形成斷電，致使交付延期，後果可能就是互相推諉和扯皮，嚴重的話可能會引起爭吵，團隊分崩離析。

概括盤點

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

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

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

文章引用

• 敏捷開發之Scrum掃盲篇(以上部分圖片摘錄自該地址)
• 敏捷開發之Scrum掃盲篇 
• 百度百科 
• 敏捷開發 模型講解
• 軟件開發模式之敏捷開發