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

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

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敏捷部落格

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

文章轉載請註明出