環(huán)信聯(lián)合創(chuàng)始人馬曉宇結(jié)合在外企工作的經(jīng)歷，談到外企是如何實(shí)現(xiàn)敏捷開發(fā)的。他用“變態(tài)”（褒義）二字形容日本企業(yè)的工作流程，日企對開發(fā)流程、質(zhì)量、測試、文檔都有嚴(yán)格的要求，寫程序可能花一周，但文檔至少要兩三個(gè)月才能通過，這也保證了能夠產(chǎn)出質(zhì)量如一的工作效果。電信行業(yè)對開發(fā)流程是365天X24小時(shí)的要求，系統(tǒng)能否長期持續(xù)運(yùn)行則是這個(gè)行業(yè)面臨的挑戰(zhàn)。而創(chuàng)業(yè)公司每天則面臨著來自不同客戶各種各樣的需求和挑戰(zhàn)。
1.SaaS需求管理，有何輕重緩急之分？
創(chuàng)業(yè)公司的需求來自項(xiàng)目經(jīng)理、研發(fā)、客戶等方方面面，也會(huì)經(jīng)常面臨各種各樣的bug。就bug的輕重緩急而言，環(huán)信聯(lián)合創(chuàng)始人馬曉宇總結(jié)了三種類型的bug，即嚴(yán)重bug,功能bug,性能bug。
結(jié)合自身的創(chuàng)業(yè)經(jīng)驗(yàn)，馬曉宇認(rèn)為比較嚴(yán)重的bug，需要團(tuán)隊(duì)立刻去執(zhí)行，去解決；而功能性的bug需要團(tuán)隊(duì)進(jìn)行排期，可能會(huì)花幾周的時(shí)間去迭代修復(fù)的；談到性能bug，他認(rèn)為是最難解決的，舉例來說，當(dāng)我們在設(shè)計(jì)的時(shí)候，系統(tǒng)一上線就能支持百萬用戶甚至億級用戶的自由伸縮，往往是不現(xiàn)實(shí)的。環(huán)信的系統(tǒng)從最開始上線，到現(xiàn)在經(jīng)歷了多個(gè)版本迭代，最終從測試用戶，上百用戶，到現(xiàn)在的幾千萬日活。所以，在SaaS需求管理上需要去平衡不同功能的需求程度。
2.關(guān)于SaaS迭代開發(fā)，應(yīng)注意什么？
創(chuàng)業(yè)公司在服務(wù)端上線周期基本上是一個(gè)月，上線有兩個(gè)注意事項(xiàng)，一個(gè)是回退方案，即做到要求的方案都可以回退，遇到問題時(shí)可以及時(shí)做到回退。另一個(gè)是兼容性問題，一個(gè)產(chǎn)品面對不同的用戶存在這不同的兼容性問題，這時(shí)我們需要做開關(guān)，如果產(chǎn)品上線可能造成某方面的損失，可以選擇做降級開關(guān)來處理，保證部分功能實(shí)現(xiàn)。
移動(dòng)端的上線需要注意發(fā)版問題，馬曉宇舉例說，當(dāng)做工具云時(shí)，在很短的周期內(nèi)出了一版，但是沒有測到嚴(yán)重的bug，隨即上線了后續(xù)更新的版本，這就會(huì)在用戶體驗(yàn)上大打折扣。
3.SaaS灰度發(fā)布系統(tǒng)是如何運(yùn)作的？
做SaaS有一個(gè)基于租戶的灰度發(fā)布。一是AB測試，AB測試是一種用于提升產(chǎn)品轉(zhuǎn)化率、優(yōu)化獲客的方法。當(dāng)我們想測試哪個(gè)注冊頁面轉(zhuǎn)化率高時(shí)，我們就可以上線兩個(gè)版本的頁面，通過一周、一月的注冊數(shù)據(jù)監(jiān)測比例來衡量哪個(gè)頁面效果好。在做云服務(wù)，SaaS時(shí)，就是基于租戶的驗(yàn)證，同樣可以適用這種方法。
前后端灰度，就是所有的前端根據(jù)cookie中的租戶id，轉(zhuǎn)發(fā)到不同版本的后端服務(wù)。如果進(jìn)來之后，cookie解決這個(gè)租戶ID，就可以寫個(gè)腳本，根據(jù)當(dāng)前給的配置對應(yīng)的版本打造對應(yīng)的服務(wù)，這是一個(gè)常用的功能。
移動(dòng)端灰度，就是移動(dòng)端登錄后，從路由服務(wù)器請求訪問地址。以做移動(dòng)端的經(jīng)驗(yàn)來說，某一個(gè)用戶想登到指定的版本如何來做？我們可以做DNS解析，就是手機(jī)端不是先去試圖訪問服務(wù)，而是先去訪問我們做的解析入口，當(dāng)前是哪個(gè)租戶，用戶ID是多少，移動(dòng)端什么版本，應(yīng)該訪問哪個(gè)后臺版本，然后整個(gè)服務(wù)會(huì)打造相應(yīng)的后臺版本。如果公司有海外客戶，就可以通過DNS解析到海外的配置，移動(dòng)端的路由可以根據(jù)不同用戶的區(qū)域做不同的配置，鏈接到不同的服務(wù)和版本。
最后談到給新晉創(chuàng)業(yè)公司的建議，馬曉宇總結(jié)了四點(diǎn)：一是核心要保持穩(wěn)定，即自身系統(tǒng)的上線流程不能影響到客戶的業(yè)務(wù)流程，可以采用錯(cuò)峰上線、降級開關(guān)等措施；二是善于提煉客戶需求，產(chǎn)品功能需要滿足大多數(shù)客戶的需求；三是成本控制，可以從架構(gòu)設(shè)計(jì)出發(fā)，盡量用成熟的組件，設(shè)計(jì)一個(gè)低成本的架構(gòu)；四是注重用戶的體驗(yàn)，在移動(dòng)端，需要多注意產(chǎn)品的兼容性問題。
在接下來的演講環(huán)節(jié)，其他講師為嘉賓傾囊分享，嘉賓與講師思維碰撞，干貨滿滿：
Worktile高級架構(gòu)師，WTC成員，孫敬云
分別從研發(fā)的困境、DevOps是什么、對DevOps工程化的個(gè)人分析以及DevOps的實(shí)戰(zhàn)入門這幾個(gè)方向來為大家?guī)怼禗evOps實(shí)戰(zhàn)：工程化管理你的DevOps平臺》
“有很多的工具用起來真的是無孔不入，什么東西都能幫你解決，基本上不需要你打開任何的東西，你只需要鍵盤鼠標(biāo)點(diǎn)一點(diǎn)就能解決。但是我相信沒有最好的實(shí)踐，只有最合適的實(shí)踐，每個(gè)團(tuán)隊(duì)如果想實(shí)踐DevOps，只有你不斷的探索，你才能找到你自己團(tuán)隊(duì)中最合適的那個(gè)DevOps解決方案。因?yàn)椋赫J(rèn)真可以把一件事做對，用心可以把一件事做好。”
石墨文檔研發(fā)負(fù)責(zé)人，李子驊
圍繞關(guān)注“非功能需求”與“DevOps相關(guān)”兩個(gè)關(guān)鍵性的話題為大家?guī)矸窒怼睹艚菟枷朐诋a(chǎn)品周期的延伸》
“產(chǎn)品周期指數(shù)指的是我們產(chǎn)品的迭代周期，我們知道一個(gè)產(chǎn)品可能會(huì)有需求的提出，需求的評審，需求的確定，以及我們實(shí)際的開發(fā)測試和交互。我們知道從01年敏捷開始到現(xiàn)在已經(jīng)有越來越多的項(xiàng)目在使用敏捷。其實(shí)現(xiàn)在敏捷已經(jīng)變成一種常態(tài)，這個(gè)時(shí)候討論敏捷的被大家的忽略點(diǎn)就變得非常有意義。”
著名精益&敏捷轉(zhuǎn)型專家—王明蘭
從我們現(xiàn)在所處于的不確定性、異變性的時(shí)代環(huán)境著手，為大家?guī)矸窒怼洞蛟霽UCA時(shí)代的敏捷型組織》
“VUCA最早來源于冷戰(zhàn)時(shí)期，由美國哈佛商學(xué)院提出。講的是在現(xiàn)在這個(gè)時(shí)代，世界越來越不確定性，越來越異變，越來越不可預(yù)測，我們已經(jīng)進(jìn)入到了VUCA時(shí)代，我們再也不能用原來的那種傳統(tǒng)的、計(jì)劃驅(qū)動(dòng)的方式來工作，因?yàn)闀r(shí)代太不確定性，大家要擁抱變化。敏捷本身也是從2001年敏捷研修院起來也是在那樣一個(gè)時(shí)代背景下，越來越發(fā)展壯大。如果倒回來很多年之前，敏捷不會(huì)發(fā)展壯大，因?yàn)槲覀冞�沒有進(jìn)入這樣的時(shí)代。”
