近日，由Worktile主辦的「2019敏捷大會--北京站」在北京東升國際科學園成功舉辦，環(huán)信聯(lián)合創(chuàng)始人馬曉宇受邀出席，并結(jié)合自己創(chuàng)業(yè)過程中的所見、所得、所想做了《SaaS敏捷開發(fā)實踐》主題分享，與到場的200余位來自各大公司的企業(yè)高管、CTO、研發(fā)總監(jiān)、敏捷教練、項目經(jīng)理等共同探討了以敏捷開發(fā)的“ 流程—實踐—思想—團隊轉(zhuǎn)型 ”為主題的相關(guān)內(nèi)容。

現(xiàn)場，環(huán)信聯(lián)合創(chuàng)始人馬曉宇從一個云服務創(chuàng)業(yè)公司的角度，分享了該如何去實現(xiàn)敏捷開發(fā)，以及在親身創(chuàng)業(yè)實踐中的經(jīng)驗和教訓。以下是根據(jù)馬曉宇現(xiàn)場演講內(nèi)容進行的梳理部分：

1.SaaS需求管理，有何輕重緩急之分?

創(chuàng)業(yè)公司的需求來自項目經(jīng)理、研發(fā)、客戶等方方面面，也會經(jīng)常面臨各種各樣的bug。就bug的輕重緩急而言，環(huán)信聯(lián)合創(chuàng)始人馬曉宇總結(jié)了三種類型的bug，即嚴重bug,功能bug,性能bug。

結(jié)合自身的創(chuàng)業(yè)經(jīng)驗，馬曉宇認為比較嚴重的bug，需要團隊立刻去執(zhí)行，去解決;而功能性的bug需要團隊進行排期，可能會花幾周的時間去迭代修復的;談到性能bug，他認為是最難解決的，舉例來說，當我們在設(shè)計的時候，系統(tǒng)一上線就能支持百萬用戶甚至億級用戶的自由伸縮，往往是不現(xiàn)實的。環(huán)信的系統(tǒng)從最開始上線，到現(xiàn)在經(jīng)歷了多個版本迭代，最終從測試用戶，上百用戶，到現(xiàn)在的幾千萬日活。所以，在SaaS需求管理上需要去平衡不同功能的需求程度。

2.關(guān)于SaaS迭代開發(fā)，應注意什么?

創(chuàng)業(yè)公司在服務端上線周期基本上是一個月，上線有兩個注意事項，一個是回退方案，即做到要求的方案都可以回退，遇到問題時可以及時做到回退。另一個是兼容性問題，一個產(chǎn)品面對不同的用戶存在這不同的兼容性問題，這時我們需要做開關(guān)，如果產(chǎn)品上線可能造成某方面的損失，可以選擇做降級開關(guān)來處理，保證部分功能實現(xiàn)。

移動端的上線需要注意發(fā)版問題，馬曉宇舉例說，當做工具云時，在很短的周期內(nèi)出了一版，但是沒有測到嚴重的bug，隨即上線了后續(xù)更新的版本，這就會在用戶體驗上大打折扣。

3.SaaS灰度發(fā)布系統(tǒng)是如何運作的?

做SaaS有一個基于租戶的灰度發(fā)布。一是AB測試，AB測試是一種用于提升產(chǎn)品轉(zhuǎn)化率、優(yōu)化獲客的方法。當我們想測試哪個注冊頁面轉(zhuǎn)化率高時，我們就可以上線兩個版本的頁面，通過一周、一月的注冊數(shù)據(jù)監(jiān)測比例來衡量哪個頁面效果好。在做云服務，SaaS時，就是基于租戶的驗證，同樣可以適用這種方法。

前后端灰度，就是所有的前端根據(jù)cookie中的租戶id，轉(zhuǎn)發(fā)到不同版本的后端服務。如果進來之后，cookie解決這個租戶ID，就可以寫個腳本，根據(jù)當前給的配置對應的版本打造對應的服務，這是一個常用的功能。

移動端灰度，就是移動端登錄后，從路由服務器請求訪問地址。以做移動端的經(jīng)驗來說，某一個用戶想登到指定的版本如何來做?我們可以做DNS解析，就是手機端不是先去試圖訪問服務，而是先去訪問我們做的解析入口，當前是哪個租戶，用戶ID是多少，移動端什么版本，應該訪問哪個后臺版本，然后整個服務會打造相應的后臺版本。如果公司有海外客戶，就可以通過DNS解析到海外的配置，移動端的路由可以根據(jù)不同用戶的區(qū)域做不同的配置，鏈接到不同的服務和版本。

在活動的演講環(huán)節(jié)，講師為嘉賓傾囊分享，嘉賓與講師思維碰撞，為活動掀起了陣陣高潮。

Worktile高級架構(gòu)師，WTC成員，孫敬云

分別從研發(fā)的困境、DevOps是什么、對DevOps工程化的個人分析以及DevOps的實戰(zhàn)入門這幾個方向來為大家?guī)怼禗evOps實戰(zhàn)：工程化管理你的DevOps平臺》

“有很多的工具用起來真的是無孔不入，什么東西都能幫你解決，基本上不需要你打開任何的東西，你只需要鍵盤鼠標點一點就能解決。但是我相信沒有最好的實踐，只有最合適的實踐，每個團隊如果想實踐DevOps，只有你不斷的探索，你才能找到你自己團隊中最合適的那個DevOps解決方案。因為：認真可以把一件事做對，用心可以把一件事做好。”

石墨文檔研發(fā)負責人，李子驊

圍繞關(guān)注“非功能需求”與“DevOps相關(guān)”兩個關(guān)鍵性的話題為大家?guī)矸窒怼睹艚菟枷朐诋a(chǎn)品周期的延伸》

“產(chǎn)品周期指數(shù)指的是我們產(chǎn)品的迭代周期，我們知道一個產(chǎn)品可能會有需求的提出，需求的評審，需求的確定，以及我們實際的開發(fā)測試和交互。我們知道從01年敏捷開始到現(xiàn)在已經(jīng)有越來越多的項目在使用敏捷。其實現(xiàn)在敏捷已經(jīng)變成一種常態(tài)，這個時候討論敏捷的被大家的忽略點就變得非常有意義。”

著名精益&敏捷轉(zhuǎn)型專家—王明蘭

從我們現(xiàn)在所處于的不確定性、異變性的時代環(huán)境著手，為大家?guī)矸窒怼洞蛟霽UCA時代的敏捷型組織》

“VUCA最早來源于冷戰(zhàn)時期，由美國哈佛商學院提出。講的是在現(xiàn)在這個時代，世界越來越不確定性，越來越異變，越來越不可預測，我們已經(jīng)進入到了VUCA時代，我們再也不能用原來的那種傳統(tǒng)的、計劃驅(qū)動的方式來工作，因為時代太不確定性，大家要擁抱變化。敏捷本身也是從2001年敏捷研修院起來也是在那樣一個時代背景下，越來越發(fā)展壯大。如果倒回來很多年之前，敏捷不會發(fā)展壯大，因為我們還沒有進入這樣的時代。”

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。