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