開發(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)品