開發(fā)版版平委，內(nèi)部版本，產(chǎn)線版本滾動前進
背景介紹
在6月25日由InfoQ主辦的GMTC（全球移動技術大會）上仅孩，鏈家網(wǎng)的郭曉銘分享的內(nèi)容是《萬億O2O移動平臺的敏捷之術》。沒機會去現(xiàn)場印蓖，從下載的PPT看辽慕，大體上還不錯，做法也算合理赦肃，有一定的借鑒之處溅蛉。下面這張流程圖就是PPT中的內(nèi)容。
圖畫的不錯他宛，蠻清晰的
能夠運轉(zhuǎn)2周一次的Sprint船侧，也相當不錯
需求領先一個周期，后端領先一個周期厅各，中間層和UI再領先一個周期镜撩，發(fā)布推遲一個周期，基本上也是可行的队塘。
如果是嚴格按照時間滾動進行袁梗，未完成的移到下個周期實現(xiàn)宜鸯，那么就更好了。
需求和后端準備好遮怜，然后客戶端再跟進淋袖，維護一個版本，符合一般大眾的思路锯梁〖赐耄總體上來說，還是不錯的陌凳。
比較理想化拜姿，是大多數(shù)人希望達到的狀態(tài)。
問題點
PM需求出來之后冯遂，關注的是后端實現(xiàn)，這個PM是后端的PM還是移動端的PM谒获？如果是指一個人蛤肌，要求這個PM從后端到移動端都熟悉，是否太理想化了批狱？如果是指好幾個人裸准，相互之間的配合能夠表現(xiàn)得像一個人這么順暢唆貌？
從后臺到前端想暗，這么長的鏈路翅萤，能配合良好嗎檐嚣？
如果有需求變更湿右，這么長的鏈路谜诫，能協(xié)調(diào)一致嗎锌订？相關方這么多陨享，能達成共識嗎推盛？
調(diào)整觀點
寫公司的網(wǎng)絡庫峦阁，在配置一塊，可以看到url分為“Production”耘成、“UAT”榔昔、“Test”三種模式。從這里得到啟發(fā)瘪菌，就分為開發(fā)版版撒会，內(nèi)部版本，產(chǎn)線版本三種师妙，三條生產(chǎn)線诵肛。
開發(fā)版本
移動端PM + UI + 移動端RD + 中間層API + QA 組成一個虛擬團隊
面向終端用戶，進行需求收集默穴、產(chǎn)品設計曾掂、編碼實現(xiàn)
沒有任何依賴惫谤，（只要后臺能實現(xiàn)就行，不需要等后臺進度珠洗，數(shù)據(jù)由QA想辦法造）溜歪，有條件實現(xiàn)2周一個Sprint
按照2周一次的頻率發(fā)版本，遇到完不成的功能许蓖，就延遲到下一個Sprint實現(xiàn)蝴猪。QA測試完，能夠滿足功能就好了膊爪。
開發(fā)版本都不對外發(fā)布自阱，測試通過的作為內(nèi)部版本候選者
有條件的可以做自動構建，自動化測試等
內(nèi)部版本
后臺PM + 后端RD + 中間層API（部分工作）+ QA 組成一個虛擬團隊
參考已經(jīng)完成的開發(fā)版本米酬，進行后臺實現(xiàn)沛豌，并對接真正的數(shù)據(jù)接口
時間周期可以按照后臺的實現(xiàn)節(jié)奏。一般2周一次有點過于頻繁赃额，可以考慮1個月一次加派。
可以根據(jù)實際情況，從眾多的開發(fā)版本中選擇一個合適版本跳芳，進行對接芍锦。
進行內(nèi)部發(fā)布，內(nèi)部試用飞盆。如果發(fā)現(xiàn)bug娄琉，另外拉分支進行bugfix。只要同步到主干以及被選中的開發(fā)版本即可吓歇，其他的版本沒必要去動孽水。
可以采用企業(yè)賬號，自由度大城看，但是要多花錢匈棘；也可以用TestFlight，免費析命，但是有100人的限制主卫，而且還要登記手機的UUID
內(nèi)部試用一段時間，感覺滿意之后鹃愤，作為發(fā)布版本候選者簇搅。
發(fā)布版本
有PM和運營團隊負責
選擇合適的，通過內(nèi)部驗證的內(nèi)部版本候選者作為發(fā)布版本
灰度發(fā)布软吐，10%瘩将，30%，30%，30%姿现，逐步放開流量
時間可以選擇一個月肠仪，每周進行一次擴容
如果遇到bug，可以選擇降級备典，可以額外拉分支進行hotfix
發(fā)布版本從內(nèi)部版本中選异旧，但是并不是每一個內(nèi)部版本都要發(fā)布；具體情況由PM和運營團隊靈活掌握提佣。
優(yōu)勢
開發(fā)吮蛹，內(nèi)部試用，正式發(fā)布三者隔離拌屏，并且由不同團隊負責潮针，從流程和人員上實現(xiàn)了解耦
將很長的一個流程分為兩個獨立的自循環(huán)，降低了整體間的依賴
開發(fā)版本倚喂，內(nèi)部版本每篷，正式版本形成一個類似金字塔的結(jié)構
結(jié)合測試、內(nèi)部試用端圈，灰度發(fā)布焦读，保證了產(chǎn)品質(zhì)量，并且風險可控
從原先的后臺功能推動枫笛，變成用戶的需求拉動，更貼近市場和用戶刚照，更容易創(chuàng)造出用戶愛用的產(chǎn)品
