在傳統(tǒng)企業(yè)應用開發(fā)中虽画，大家都是按版本進行發(fā)布
客戶意見收集 》形成需求文檔 》 需求評審 》 系統(tǒng)設計 》 開發(fā) 》 測試 》發(fā)布 》 客戶驗收。荣病。码撰。第二輪。个盆。脖岛。第三輪；
在這種背景下砾省，一般版本的發(fā)布時間是固定死的鸡岗，比如簽合同的時候就約定了幾月幾日進行項目的上線。而且這個時間基本都是很趕的编兄，合同一簽訂下來轩性，就意味著開始沒完沒了的加班，大家天天都是忙得天昏地暗的狠鸳，誰還管發(fā)布幾個中間版本揣苏，做幾個里程碑。件舵。卸察。
而做互聯(lián)網(wǎng)產(chǎn)品，天生就要求按需求發(fā)布
做產(chǎn)品開發(fā)的在版本發(fā)布方面的自主性會好一些铅祸，畢竟來自公司內(nèi)部的壓力比來自客戶的壓力還是要小很多的坑质。然而對版本更新的頻次要求就高很多合武，甚至是沒有上限的，道理很簡單涡扼，誰先最先面向市場推出了一個新功能稼跳，誰就是整個市場的No1，誰就在這個功能上深深的打上自己的烙印吃沪。從各大公司的情況看汤善，MIUI是每周一次（黑色星期五）；同程每周四發(fā)布票彪；亞馬遜是每天幾十次版本更新红淡；（這里的對比數(shù)據(jù)并不是說明亞馬遜比小米牛逼幾個檔次，這里的情況是由產(chǎn)品特點決定的）
一提起按需發(fā)布降铸，各位開發(fā)團隊的老大們首先要面對的至少有以下方面的挑戰(zhàn)：
- 測試壓力會很大：這個應該是我們還是在按版本發(fā)布的主要原因在旱，每一次需求的上線，意味著至少要經(jīng)歷開發(fā)自測推掸、測試人員測試環(huán)境測試颈渊、業(yè)務人員開發(fā)環(huán)境驗收三個階段，而其中“測試人員測試環(huán)境測試”這個步驟需要考慮當前代碼的影響范圍终佛，范圍內(nèi)的進行深入測試俊嗽，范圍外的也需要進行冒煙測試。這個時間成本是很大的铃彰。
- 頻繁部署耗時绍豁、易出錯：開發(fā)自測環(huán)境的部署、測試環(huán)境的部署牙捉、生產(chǎn)環(huán)境的部署竹揍，每一次部署都需要時間，都可能導致生產(chǎn)故障邪铲。出的故障次數(shù)多了芬位，大家潛意識就想離部署遠一點；
- 升級影響正常業(yè)務運行：線上的頻繁啟痛剑可能會臨時性的中斷業(yè)務訪問昧碉。
但是帶來的好處更是意味深長：
- 搶占市場先機：盡可能快速的響應市場需求，對搶占市場具有戰(zhàn)略意義揽惹；快速的更新意味著可以第一時間得到用戶的反饋被饿，并進行優(yōu)化后快速推出，形成良性循環(huán)搪搏；
- 能充分發(fā)揮研發(fā)的價值：研發(fā)出來的東西是丟倉庫一段時間狭握，還是馬上就賣出去，這個意義是大不一樣的疯溺；這還涉及到丟倉庫一段時間后论颅，開發(fā)人員自己都忘記當初的需求和設計了哎垦，一旦出現(xiàn)問題，開發(fā)人員需要苦苦追憶過往恃疯，個中煩躁撼泛，誰經(jīng)歷誰知道。澡谭。。
- 降低團隊管理的復雜度：這里的降低是相對于按照版本發(fā)布來說的损俭，每一次版本的開發(fā)計劃安排蛙奖，都意味著需要平衡不同開發(fā)人員的進度，因為不同開發(fā)人員的經(jīng)驗杆兵、解決難題的能力雁仲、學習的能力等都是不一樣的，導致任務的安排很難面面俱到琐脏。任務安排后攒砖，同樣要每天去了解大家的開發(fā)進度，確認是不是有人的計劃延遲了日裙，會不會導致A程序員等B程序員的情況發(fā)生等吹艇。在測試階段，為了保證改bug的時間昂拂，又不能放新的需求進來受神，部分bug少的程序員就會處于waiting狀態(tài)。當然以上三個階段格侯，在真實情況下鼻听，都會協(xié)調(diào)程序員之間相互協(xié)助，但這個協(xié)調(diào)本身就是導致管理復雜的原因之一联四。
- 降低開發(fā)團隊管理的技術(shù)門檻：國內(nèi)的開發(fā)團隊管理者（或者是項目經(jīng)理）基本都是開發(fā)出身撑碴，而且是屬于學而優(yōu)則仕的那種。原因也很簡單朝墩，非這樣的人沒法把控項目的進度醉拓，因為開發(fā)任務安排、工時評估收苏、協(xié)調(diào)資源解決技術(shù)難題廉嚼、面向需求提出技術(shù)解決方案等，都需要深厚的技術(shù)根底倒戏。但是按需求發(fā)布可以弱化這方面的要求怠噪，只要有一定開發(fā)經(jīng)驗、擅長溝通協(xié)調(diào)的人即可擔任管理工作杜跷。技術(shù)方案方面的事情可以以“專家評審會”的形式來解決傍念。
- 打造面向創(chuàng)造價值的團隊文化：作為開發(fā)人員矫夷，誰也不想整天被領導站在后面監(jiān)督，畢竟大家做的是創(chuàng)造性的工作憋槐，天天被人監(jiān)督的話双藕，連起碼的尊重都得不到，剛?cè)肼毜男』镒舆€能操兩年阳仔，經(jīng)驗豐富的老鳥們呢忧陪？面向需求的發(fā)布，可以把大家的關注點都集中到完成了多少需求的開發(fā)近范、以及該需求產(chǎn)生了多少價值上來嘶摊，團隊的領導者也和大家一樣是一個需求的開發(fā)者，而不僅僅是一個監(jiān)督者评矩。至于團隊的管理者叶堆，那更是為大家服務的，團隊內(nèi)部并沒有對立點斥杜。共同的價值取向就會把大家緊緊團結(jié)在一條船上虱颗。
既然好處有這么多，而且都有著不可抗拒的誘惑力蔗喂，那就只能盡力去克服困難了：
- 測試壓力大：
- 最終極的解決辦法肯定是提高自動化測試覆蓋的范圍忘渔，減少人工測試的工作量。各大互聯(lián)網(wǎng)公司的流水線開發(fā)為什么這么牛B缰儿，自動化測試應該說是首功辨萍。
- 但是小公司沒法一下就打造這么完善的自動化測試體系出來，只能說前期先用人力頂上返弹，這部分的人力成本投入相對廉價锈玉，但是可以提高開發(fā)的輸出，還是比較合算的义起。另一方面拉背，逐漸提高自動化測試的覆蓋范圍。
- 頻繁部署耗時默终、易出錯：
- 規(guī)范代碼管理椅棺，按需求開分支，專人合并齐蔽，提高代碼質(zhì)量两疚；
- 增量發(fā)布，只有增量發(fā)布含滴，才能減少影響范圍诱渤，減少線上業(yè)務驗收的范圍，當然就會減少出錯的可能性谈况；
- 搭建自動發(fā)布平臺勺美，增量發(fā)布會導致發(fā)布更復雜递胧，自動發(fā)布平臺能大大減少這部分工作。
- 升級影響業(yè)務：
- 這個問題其實在引入集群赡茸、分布式session后已經(jīng)影響很小的缎脾，只有在數(shù)據(jù)庫表發(fā)生變更時必須停機發(fā)布以外，其他情況都可以做到用戶無感知占卧；
- 接口做版本遗菠，接口有變化需求時，升級版本华蜒，以免影響調(diào)用者辙纬。
總結(jié)：只要有了明確的方向，每天進步一點友多，目標并不是那么遙不可及！
各位開發(fā)團隊的帶頭大哥們堤框，你們也不想整天盯著小伙子們有沒有在賣力干活域滥，整天揪心版本能不能按時發(fā)布，整天干著這些毫無技術(shù)含量的事吧蜈抓；你們也想和大家一起去創(chuàng)造實實在在價值（做開發(fā)）启绰，也想研究一下最新最前沿的技術(shù)（提升技能），也想消除和團隊的對立點融為一個整體吧沟使！那還等什么委可，按需求發(fā)布走起來！
