瀑布和敏捷不是什么新概念，這里只是個人在團(tuán)隊(duì)合作中不得不去思考而做的歸納和總結(jié)，同時記錄自己曾經(jīng)踩過的坑，新瓶裝舊酒，希望對你有所啟發(fā)。
瀑布模型是比較傳統(tǒng)一種開發(fā)模式，特別是在2B的傳統(tǒng)企業(yè)，包括ERP，MES，WMS，CRM，OA，IBMS等系統(tǒng)當(dāng)中可以經(jīng)常見到他們的影子?，F(xiàn)在這種模式仍然流行在一些大的項(xiàng)目或者是外包的一些項(xiàng)目當(dāng)中。
如上圖所示，瀑布模型優(yōu)缺點(diǎn)都很突出。
階段清晰。從計(jì)劃到開發(fā)最后到上線運(yùn)行，三個階段非常清晰。
時間順序。每個階段順序必須是從上到下，嚴(yán)格按照時間先后進(jìn)行。
環(huán)環(huán)相扣。在每一個階段都必須有產(chǎn)出物然后才能進(jìn)入到下一個階段進(jìn)行。
黑盒模式。每個階段都有各自的角色和分工，各自只關(guān)心自己的任務(wù)。比如需求階段開發(fā)人員無需關(guān)注。
需求隔離。由于各階段的人員只能接觸到自己工作范圍內(nèi)的東西，所以對客戶需求的理解程度高低不等，開發(fā)人員更像是定義為流水線上的工人。
變更代價大。既然叫做瀑布，就意味著不應(yīng)該走回頭路。否則如果出現(xiàn)返工，付出的代價會很大。需求變更，編碼人員會很強(qiáng)的抵觸情緒。
束縛創(chuàng)造性。由于強(qiáng)調(diào)文檔管理，所以管理人員會比較喜歡，但是他束縛了開發(fā)人員的創(chuàng)造性。
周期漫長。整個開發(fā)持續(xù)的生命周期很長，需求和設(shè)計(jì)的時間會耗費(fèi)特別多，有時候會占用三分之一甚至更多時間，這樣整個周期就會變長，大都在半年到一年左右的時間，所以更適合需求相對穩(wěn)定的大項(xiàng)目。
根據(jù)以上分析，我們知道瀑布模式強(qiáng)調(diào)里程碑，重視文檔，強(qiáng)調(diào)分工，避免變化，凡事喜歡規(guī)劃和做計(jì)劃，但是代價就是拖沓笨重，反應(yīng)遲鈍。
敏捷開發(fā)借助互聯(lián)網(wǎng)浪潮開始流行起來，這也是2C的業(yè)務(wù)特點(diǎn)決定的，看過QQ和微信長大的人，這種體會特別深?；ヂ?lián)網(wǎng)產(chǎn)品不可能一步規(guī)劃到位，一般都是核心功能優(yōu)先，比如微信，先是實(shí)現(xiàn)聊天功能，然后才是漂流瓶，錢包，小程序……
互聯(lián)網(wǎng)業(yè)務(wù)有何特點(diǎn)呢？借用雷軍的七字訣：專注、極致、口碑、快。
唯有專注才能聚焦能量，引爆燃點(diǎn)。
唯有極致才能排除競爭，爭取用戶。
金杯銀杯不如口碑。
天下武功唯快不破。
敏捷無疑更加貼近互聯(lián)網(wǎng)的這種業(yè)務(wù)需求，如果純用瀑布模式，估計(jì)黃花菜都涼了。敏捷還有一個更極致的做法，直接上PPT通過類似眾籌的方式進(jìn)行開發(fā)，這種從群眾中來到群眾中去的個性化定制功能非常的有創(chuàng)意，如果眾籌的結(jié)果是沒有人感興趣，就可以直接否定該產(chǎn)品開發(fā)，可以避免無謂的“庫存”導(dǎo)致的開發(fā)壓力，節(jié)省巨大的成本浪費(fèi)。
Scrum的意思是橄欖球運(yùn)動的一個專業(yè)術(shù)語，表示“爭球”的動作。把一個開發(fā)流程的名字取名為一項(xiàng)體育運(yùn)動，你一定能感受到其中的碰撞，沖突，激情。如果是這樣，Scrum如何能提高開發(fā)效率呢？敏捷開發(fā)是一種指導(dǎo)思想，Scrum和XP則是敏捷開發(fā)的具體開發(fā)流程，這里只選擇Scrum進(jìn)行探討。
我們先來看下Scrum的三個角色：
產(chǎn)品負(fù)責(zé)人：提供整體產(chǎn)品需求清單，確定產(chǎn)品邊界，功能組合圖譜，交付內(nèi)容和日期。另外產(chǎn)品負(fù)責(zé)人有權(quán)拒絕開發(fā)團(tuán)隊(duì)的開發(fā)成果。
開發(fā)團(tuán)隊(duì)：因?yàn)樽非罂?，開發(fā)人員需要很強(qiáng)的自我管理能力，需要主動反饋，主動溝通。
流程管理員：主要任務(wù)是疏通開發(fā)和業(yè)務(wù)的障礙，起到一個膠水的粘合作用，所以一旦開發(fā)進(jìn)行，流程管理員有權(quán)拒絕需求的變更或修改。
Scrum是一個理想化的開發(fā)流程，前提條件是角色完整，分工明確，配合默契，溝通融洽。如果出現(xiàn)其中任何一個環(huán)節(jié)的故障，可能都會破壞流程的效率，比如，開發(fā)經(jīng)理和流程管理員脾氣一樣倔強(qiáng)，脾氣互斥，那么整個效率就打折扣。我感覺在招聘人員，團(tuán)結(jié)組建的過程中，我們務(wù)必要尋找氣味相投的人，這可以減少開發(fā)過程中的沖突。
Scrum和瀑布的本質(zhì)區(qū)別是，一個以文檔為本，一個以人為本。在以人為本的團(tuán)隊(duì)里，領(lǐng)導(dǎo)者的文化就是團(tuán)隊(duì)的文化。如果領(lǐng)導(dǎo)者不透明，喜歡玩虛假，自大，官僚氣十足，這個團(tuán)隊(duì)基本上就沒什么希望了。人必須是主人，有能動性，這個高度困難。因?yàn)槿绾巫寛F(tuán)隊(duì)覺得公司的事是我家里的事是高度困難的，因?yàn)橛行╅_發(fā)人員自己家的事都沒怎么認(rèn)真過。想要做到這點(diǎn)，需要老板重視，否則中層領(lǐng)導(dǎo)我感覺一般都心有余力不足。
首先需要確定一個產(chǎn)品需求列表，由產(chǎn)品負(fù)責(zé)人負(fù)責(zé)；
開發(fā)團(tuán)隊(duì)根據(jù)列表，做工作量的預(yù)估和安排；
有了產(chǎn)品需求列表，我們需要通過計(jì)劃會來從中挑選出一個故事作為本次迭代完成的最小目標(biāo)，這個目標(biāo)的時間周期是1~4個星期，然后把這個故事進(jìn)行細(xì)化，形成一個最小產(chǎn)品需求。比如該故事是登陸的功能故事，那么登陸的需求就要進(jìn)行完整的細(xì)化工作；
開發(fā)成員根據(jù)故事再細(xì)化成更小的任務(wù)（細(xì)到每個任務(wù)的工作量在2天內(nèi)能完成）；
計(jì)劃紙牌怎么怎么用的呢？比如A程序員開發(fā)一個功能，需要5個小時，B程序員認(rèn)為只需要半小時，那他們各自取相應(yīng)的牌，藏在手中，最后攤牌，如果時間差距很大，那么A和B就可以討論A為什么要5個小時...
開發(fā)過程需要設(shè)置每日站會，每次會議控制在15分鐘左右，每個人都必須發(fā)言，并且要向所有成員當(dāng)面匯報(bào)三個問題：A.你昨天完成了什么；B今天要完成什么；C.什么問題不能解決。
每個人回答完成后，要走到黑板前更新自己的sprint燃盡圖；
每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本，可以機(jī)制CI,CD工具進(jìn)行輔助開發(fā)；
當(dāng)一個故事完成，也就是最小目標(biāo)被完成，這時，我們要進(jìn)行演示會議，也稱為評審會議，產(chǎn)品負(fù)責(zé)人和客戶都要參加（最好本公司老板也參加），每一個開發(fā)成員都要向他們演示自己完成的軟件產(chǎn)品（這個會議非常重要，一定不能取消）；
最后就是回顧會議，也稱為總結(jié)會議，以輪流發(fā)言方式進(jìn)行，每個人都要發(fā)言，總結(jié)并討論改進(jìn)的地方，放入下一輪sprint的產(chǎn)品需求中；
大家如果認(rèn)真的看完整個Scrum的開發(fā)流程，會發(fā)現(xiàn)這個過程還真的是很完美，不妨可以用在你的團(tuán)隊(duì)開發(fā)過程中。
瀑布敏捷是有邊界的，我覺得團(tuán)隊(duì)在整體學(xué)習(xí)開發(fā)模式優(yōu)劣后，需要對二者的邊界有一個清晰的認(rèn)識，并在整個團(tuán)隊(duì)上下都要達(dá)成一致的共識，否則后果可能會很嚴(yán)重。雙方的邊界如下圖所示
為什么說共識很重要呢？就我踩過的坑進(jìn)行盤點(diǎn)，有如下幾個問題：
領(lǐng)導(dǎo)指揮不當(dāng)：老板重文檔，覺得必須有文檔往下開發(fā)才是規(guī)范的，否則后面的工作都是一種浪費(fèi)，因?yàn)槟愕捻旑^上司不一定懂技術(shù)，這樣導(dǎo)致的結(jié)果是文檔沒出來前，底下人只能泡茶聊天了。
團(tuán)隊(duì)效率極低：因?yàn)槠俨紡?qiáng)調(diào)分工，各自為戰(zhàn)，所以有可能架構(gòu)設(shè)計(jì)人員在等產(chǎn)品經(jīng)理給需求文檔，開發(fā)人員在等待架構(gòu)設(shè)計(jì)文檔，測試人員在等待開發(fā)成果，老板在等待產(chǎn)品交付。這里環(huán)環(huán)相扣，類似電流串聯(lián)工作，一個環(huán)節(jié)出錯，造成斷電，導(dǎo)致交付延期，后果可能就是互相推諉和扯皮，嚴(yán)重的話可能會引發(fā)爭吵，團(tuán)隊(duì)分崩離析。
就個人的經(jīng)驗(yàn)來看，瀑布和敏捷不是天然分割的，只是針對業(yè)務(wù)各有側(cè)重，應(yīng)該是你中有我，我中有你的混合體。比如微信第一版的時候，聊天核心功能的迭代一定也有內(nèi)部的小瀑布，如果沒有計(jì)劃-開發(fā)-測試-運(yùn)維根本就無法進(jìn)行下去。再比如瀑布，特別對創(chuàng)業(yè)團(tuán)隊(duì)，剛開始人手不多，分工不明，架構(gòu)師有可能要去畫原型圖，做需求調(diào)研；產(chǎn)品經(jīng)理業(yè)務(wù)模糊，還在探索，各種短板和不足就像黑洞一樣存在你的周邊，你渾然無知。如果你一定要等整個調(diào)研完成，PRD文檔周全再做開發(fā)，估計(jì)也要歇菜。
既然各有利弊，那么中間的這個平衡點(diǎn)如何拿捏就非常重要，如何在前期設(shè)計(jì)的時候既能不過渡導(dǎo)致交付延遲，又能兼顧后續(xù)的演進(jìn)和變化導(dǎo)致的修改可控，這需要開發(fā)經(jīng)理豐富的實(shí)戰(zhàn)歷練和審時度勢的判斷力。
另外叨叨一下，開發(fā)模式貫穿做整個開發(fā)的生命周期，但是團(tuán)隊(duì)各個成員包括產(chǎn)品經(jīng)理，技術(shù)經(jīng)理，架構(gòu)師，開發(fā)人員對項(xiàng)目管理的流程理解各不相同，深淺不一，很難想象如果大家沒有達(dá)成共識，整個開發(fā)團(tuán)隊(duì)的效率會有多高？但是現(xiàn)實(shí)當(dāng)中，大部分團(tuán)隊(duì)成員沒有開發(fā)模式的培訓(xùn)和上下達(dá)成一致依然在進(jìn)行著開發(fā)的工作……
聯(lián)系客服
