環信聯合創始人： Saas敏捷開發實踐！

馬曉宇 --環信聯合創始人/執行總裁

咱們是一個作雲服務的創業公司，因此我就雲服務創業公司的角度，來談談咱們是怎麼去實踐敏捷開發的。確切地說，就是講講咱們這幾年的這些教訓...

1-創業公司敏捷開發流程有哪些？

日本企業：個人第一份工做，我發現它這個文化，或者它這個流程設計的是和他們的特色很是相關，若是你們接觸過日本，就會知道他們有一個特色，兩個字—「變態」。

爲何這麼說呢？這多是褒義，由於他們對文檔，對質量，對流程，對測試要求就是兩個字：變態。因此他們的整個流程就是很是變態。

你們若是寫過概要設計、說明書這些的，你可能寫程序花最多一週，可是寫文檔至少兩三個月才能經過。可是這個好處是說保證隨便的一個普通工程師，剛大學畢業，他進到這個企業，進到這個組織，他就能產出一樣質量的一個軟件，因此這個是不少公司其實作不到的。核心團隊人員離職了，尤爲創業公司，有時候面臨挑戰就會比較大。可是在這種變態流程裏，它其實不缺人，由於每個人都是螺絲釘。

電信軟件：發現又不同，咱們通常作系統，出問題重啓，可是電信它的要求是，但願這個系統一年不重啓...

開源社區：通常一年開一次會，整個一個團隊大概七八我的，多的十幾我的在世界各地，每一年年初或者年末開一個會，這個會上就討論今年什麼，都比較虛。組織形式很是鬆散，由於你們可能有一個共同的目標，客戶的期待也特別大，因此就是沒日沒夜的去工做。

手機軟件：挑戰和其餘的不同，就是多了一個兼容性。由於手機系統當時咱們有一個參數，就是說你一個軟件發出來以後，你有多少個客戶，升級以後，它要回廠，回到服務站去解決問題。

具體指標我記不清，每次都會檢查，就是若是回到服務站的用戶多了，這個軟件就賠錢了。咱們原來作移動的APP、SDK也面臨一樣挑戰。

創業公司：生存挑戰，咱們找各類流程，找一個能適應咱們文化的，最關鍵的其實想找一個能幫助咱們生存下去的流程。

其實創業的話，就會以爲每月有一天特別難受，那就是每月給員工發工資的時候。幾百人怎麼去賺到這個錢，而後去給你們發工資。

那這個生存挑戰怎麼解決呢？可能就是四個字，「降本增效」，但這個比較虛了，都知道降本增效，可是實際怎麼作啊？我給你們送一句話：「降本增效，就用Worktile」

咱們用Worktile比較早，在2014年左右就開始用，早期的付費用戶，以爲挺好用的，以後又在敏捷大會看了新版本新界面，感受功能更增強大了。

2-SaaS需求管理，有何輕重緩急之分？

創業公司的需求來自 項目經理、研發、客戶 等方方面面，也會常常面臨各類各樣的bug。

就bug的輕重緩急而言，我總結了三種類型的bug：

嚴重bug： 須要團隊馬上去執行，去解決；

功能性bug： 須要團隊進行排期，可能會花幾周的時間去迭代修復的；

性能bug： 這是最難解決的，舉例來講，當咱們在設計的時候，系統一上線就能支持百萬用戶甚至億級用戶的自由伸縮，每每是不現實的。因此，在SaaS需求管理上須要去平衡不一樣功能的需求程度。

3-關於SaaS迭代開發，應注意什麼？

創業公司在服務端上線週期基本上是一個月，上線有兩個注意事項：

一個是回退方案， 即作到要求的方案均可以回退，遇到問題時能夠及時作到回退。

另外一個是兼容性問題， 一個產品面對不一樣的用戶存在這不一樣的兼容性問題，這時咱們須要作開關，若是產品上線可能形成某方面的損失，能夠選擇作降級開關來處理，保證部分功能實現。

移動端的上線須要注意發版問題，當作工具雲時，在很短的週期內出了一版，可是沒有測到嚴重的bug，隨即上線後續更新的版本，這就會在用戶體驗上大打折扣。

4-SaaS 雲服務的自動測試如何作？

若是如今作互聯網服務愈來愈的是避不開移動端，除非用微信 H5，不然怎麼測應用的在百萬及甚至幾百萬用戶的壓力下，你應用的響應，若是作測試知道這個是特別花錢的，由於你實際模擬一個用戶，這個一臺機器基本上是六萬，一臺機器模擬六萬個客戶，這是咱們的常規測試，若是模擬百萬用戶實時鏈接，要求二十臺機器，十臺是60萬，二十臺機器，但這個對創業公司服務器的成本仍是有的。

因此咱們怎麼作呢？ 阿里雲是如今也支持了，早期是10%，如今已經按量付費，去使用服務器資源，計費週期是到秒的，因此咱們真正去作移動端壓力測試的時候，建議你們搞這麼一套系統，這個還花的咱們一段時間，咱們整個有一套腳本，這個腳本從運行就啓動一個阿里雲，是有API，申請ECS，好比跑一個百萬的，能夠把服務器申請出來，咱們把全部的模板部署上，部署以後先作一個簡單驗證，整個環境通了，這樣就能夠去真正模擬，由於通常的模擬場景是百萬用戶，同時先登服務器，建一個百萬的TCP鏈接，以後模擬一些場景，有的是發消息，有的是客服業務，有的送花有的點贊這些場景模擬完以後，要把測試結果報告，這套有了，這個測試就完了。

可是提醒一下，你能夠自動釋放服務器，但通常咱們作這個操做的時候，咱們整個測試結果出來以後，咱們看一下，若是說不達到期待，調一下腳本，甚至去改一下服務再測一下。若是沒問題，後邊就有一個腳本能自動釋放，因此整個其實能夠全自動的，並且當時我算了一下，若是你是使用，好比按天，不到三天，費用確定是比包月便宜，即便拿到一個比較高的折扣，你們作移動端自動測試，尤爲是這種要作併發的話，我建議就用這種按量，這個是給咱們省了很多錢。

5-部署和運維的敏捷保障

作雲服務，作SaaS的有一個，基於租戶的灰度發佈。

1.AB測試

AB測試是一種用於提高產品轉化率、優化獲客的方法。當咱們想測試哪一個註冊頁面轉化率高時，咱們就能夠上線兩個版本的頁面，經過一週、一月的註冊數據監測比例來衡量哪一個頁面效果好。在作雲服務，SaaS時，就是基於租戶的驗證，一樣能夠適用這種方法。

2.先後端灰度

全部的前端根據cookie中的租戶id，轉發到不一樣版本的後端服務。若是進來以後，cookie解決這個租戶ID，就能夠寫個腳本，根據當前給的配置對應的版本打造對應的服務，這是一個經常使用的功能。

3.移動端灰度

移動端登陸後，從路由服務器請求訪問地址。以作移動端的經驗來講，某一個用戶想登到指定的版本如何來作？咱們能夠作DNS解析，就是手機端不是先去試圖訪問服務，而是先去訪問咱們作的解析入口，當前是哪一個租戶，用戶ID是多少，移動端什麼版本，應該訪問哪一個後臺版本，而後整個服務會打造相應的後臺版本。

若是公司有海外客戶，就能夠經過DNS解析到海外的配置，移動端的路由能夠根據不一樣用戶的區域作不一樣的配置，連接到不一樣的服務和版本。

6-學費/教訓

說說學費，從如今看，不論是流程，如今要保證最重要的四個方面：

1-核心要保持穩定，

即自身系統的上線流程不能影響到客戶的業務流程，能夠採用錯峯上線、降級開關等措施;

不論是作即時通信，仍是作客服，若是這個系統出問題，都會影響它的業務。

2- 善於提煉客戶需求

產品功能須要知足大多數客戶的需求; 若是你客戶比較多的話，跟銷售打交道，容易被忽悠，銷售說「你把這個作了就給錢了」或者「若是你把這個作了就好了」。我說哪一個重要，銷售都說重要。

因此這裏面有個技巧，你得須要真正對這個產品有理解，對這個業務理解了，就是用戶要的只是他如今想要的，可是若是能把不一樣的需求，提高到通用的需求，裏面加一些開關，能知足大多數的需求，這個是很重要的。

3-成本控制

能夠從架構設計出發，儘可能用成熟的組件，設計一個低成本的架構; 若是大家作雲服務，一開始不以爲，可是若是忽然運維給你一個七位數的賬單，一個月。你就認識到，你的架構須要改了，可是若是你看到這個賬單的時候，可能有點晚了

4-注重用戶的體驗

在移動端，須要多注意產品的兼容性問題。通常用戶不會由於體驗問題會跟你斷約，前面這些事情都是說有可能不給你作，後面的體驗作好能給他服務的更好，體驗就是剛纔說過，可能主要就是注意一下移動端的兼容性，雖然換手機頻率高，可是兼容性問題仍是比較大的。

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。