在傳統(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é)調程序員之間相互協(xié)助，但這個協(xié)調本身就是導致管理復雜的原因之一。
- 降低開發(fā)團隊管理的技術門檻：國內(nèi)的開發(fā)團隊管理者（或者是項目經(jīng)理）基本都是開發(fā)出身，而且是屬于學而優(yōu)則仕的那種。原因也很簡單，非這樣的人沒法把控項目的進度，因為開發(fā)任務安排、工時評估、協(xié)調資源解決技術難題、面向需求提出技術解決方案等，都需要深厚的技術根底。但是按需求發(fā)布可以弱化這方面的要求，只要有一定開發(fā)經(jīng)驗、擅長溝通協(xié)調的人即可擔任管理工作。技術方案方面的事情可以以“專家評審會”的形式來解決。
- 打造面向創(chuàng)造價值的團隊文化：作為開發(fā)人員，誰也不想整天被領導站在后面監(jiān)督，畢竟大家做的是創(chuàng)造性的工作，天天被人監(jiān)督的話，連起碼的尊重都得不到，剛入職的小伙子還能操兩年，經(jīng)驗豐富的老鳥們呢？面向需求的發(fā)布，可以把大家的關注點都集中到完成了多少需求的開發(fā)、以及該需求產(chǎn)生了多少價值上來，團隊的領導者也和大家一樣是一個需求的開發(fā)者，而不僅僅是一個監(jiān)督者。至于團隊的管理者，那更是為大家服務的，團隊內(nèi)部并沒有對立點。共同的價值取向就會把大家緊緊團結在一條船上。
既然好處有這么多，而且都有著不可抗拒的誘惑力，那就只能盡力去克服困難了：
- 測試壓力大：
- 最終極的解決辦法肯定是提高自動化測試覆蓋的范圍，減少人工測試的工作量。各大互聯(lián)網(wǎng)公司的流水線開發(fā)為什么這么牛B，自動化測試應該說是首功。
- 但是小公司沒法一下就打造這么完善的自動化測試體系出來，只能說前期先用人力頂上，這部分的人力成本投入相對廉價，但是可以提高開發(fā)的輸出，還是比較合算的。另一方面，逐漸提高自動化測試的覆蓋范圍。
- 頻繁部署耗時、易出錯：
- 規(guī)范代碼管理，按需求開分支，專人合并，提高代碼質量；
- 增量發(fā)布，只有增量發(fā)布，才能減少影響范圍，減少線上業(yè)務驗收的范圍，當然就會減少出錯的可能性；
- 搭建自動發(fā)布平臺，增量發(fā)布會導致發(fā)布更復雜，自動發(fā)布平臺能大大減少這部分工作。
- 升級影響業(yè)務：
- 這個問題其實在引入集群、分布式session后已經(jīng)影響很小的，只有在數(shù)據(jù)庫表發(fā)生變更時必須停機發(fā)布以外，其他情況都可以做到用戶無感知；
- 接口做版本，接口有變化需求時，升級版本，以免影響調用者。
總結：只要有了明確的方向，每天進步一點，目標并不是那么遙不可及！
各位開發(fā)團隊的帶頭大哥們，你們也不想整天盯著小伙子們有沒有在賣力干活，整天揪心版本能不能按時發(fā)布，整天干著這些毫無技術含量的事吧；你們也想和大家一起去創(chuàng)造實實在在價值（做開發(fā)），也想研究一下最新最前沿的技術（提升技能），也想消除和團隊的對立點融為一個整體吧！那還等什么，按需求發(fā)布走起來！
