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