环信联合创始人: Saas敏捷开发实践!

18a1cc5e65e47244bc0819ad16c8c1ed.jpg


马晓宇 --环信联合创始人/执行总裁

 

我们是一个做云服务的创业公司,所以我就云服务创业公司的角度,来谈谈我们是怎么去实践敏捷开发的。确切地说,就是讲讲我们这几年的这些教训...

1-创业公司敏捷开发流程有哪些?

 

屏幕快照 2019-06-14 下午2.57.08.png

 

日本企业:我的第一份工作,我发现它这个文化,或者它这个流程设计的是和他们的特点非常相关,如果大家接触过日本,就会知道他们有一个特点,两个字—“变态”。

为什么这么说呢?这可能是褒义,因为他们对文档,对质量,对流程,对测试要求就是两个字:变态。所以他们的整个流程就是非常变态。

大家如果写过概要设计、说明书这些的,你可能写程序花最多一周,但是写文档至少两三个月才能通过。但是这个好处是说保证随便的一个普通工程师,刚大学毕业,他进到这个企业,进到这个组织,他就能产出同样质量的一个软件,所以这个是很多公司其实做不到的。核心团队人员离职了,尤其创业公司,有时候面临挑战就会比较大。但是在这种变态流程里,它其实不缺人,因为每一个人都是螺丝钉。

电信软件:发现又不一样,我们一般做系统,出问题重启,但是电信它的要求是,希望这个系统一年不重启...

开源社区:一般一年开一次会,整个一个团队大概七八个人,多的十几个人在世界各地,每年年初或者年底开一个会,这个会上就讨论今年什么,都比较虚。组织形式非常松散,因为大家可能有一个共同的目标,客户的期待也特别大,所以就是没日没夜的去工作。

手机软件:挑战和其他的不一样,就是多了一个兼容性。因为手机系统当时我们有一个参数,就是说你一个软件发出来之后,你有多少个客户,升级之后,它要回厂,回到服务站去解决问题。

具体指标我记不清,每次都会检查,就是如果回到服务站的用户多了,这个软件就赔钱了。我们原来做移动的APP、SDK也面临同样挑战。

创业公司:生存挑战,我们找各种流程,找一个能适应我们文化的,最关键的其实想找一个能帮助我们生存下去的流程。

其实创业的话,就会觉得每个月有一天特别难受,那就是每个月给员工发工资的时候。几百人怎么去赚到这个钱,然后去给大家发工资。

那这个生存挑战怎么解决呢?可能就是四个字,“降本增效”,但这个比较虚了,都知道降本增效,但是实际怎么做啊?我给大家送一句话:“降本增效,就用Worktile”

我们用Worktile比较早,在2014年左右就开始用,早期的付费用户,觉得挺好用的,之后又在敏捷大会看了新版本新界面,感觉功能更加强大了。

 

屏幕快照 2019-06-14 下午3.07.20.png

 

2-SaaS需求管理,有何轻重缓急之分?

 

屏幕快照 2019-06-14 下午3.13.24.png

 

创业公司的需求来自 项目经理、研发、客户 等方方面面,也会经常面临各种各样的bug。

就bug的轻重缓急而言,我总结了三种类型的bug:

严重bug: 需要团队立刻去执行,去解决;

功能性bug: 需要团队进行排期,可能会花几周的时间去迭代修复的;

性能bug: 这是最难解决的,举例来说,当我们在设计的时候,系统一上线就能支持百万用户甚至亿级用户的自由伸缩,往往是不现实的。所以,在SaaS需求管理上需要去平衡不同功能的需求程度。

3-关于SaaS迭代开发,应注意什么?

 

屏幕快照 2019-06-14 下午4.04.15.png

 

创业公司在服务端上线周期基本上是一个月,上线有两个注意事项:

一个是回退方案, 即做到要求的方案都可以回退,遇到问题时可以及时做到回退。

另一个是兼容性问题, 一个产品面对不同的用户存在这不同的兼容性问题,这时我们需要做开关,如果产品上线可能造成某方面的损失,可以选择做降级开关来处理,保证部分功能实现。

移动端的上线需要注意发版问题,当做工具云时,在很短的周期内出了一版,但是没有测到严重的bug,随即上线后续更新的版本,这就会在用户体验上大打折扣。

4-SaaS 云服务的自动测试如何做?

 

屏幕快照 2019-06-17 下午2.35.42.png

 

如果现在做互联网服务越来越的是避不开移动端,除非用微信 H5,否则怎么测应用的在百万及甚至几百万用户的压力下,你应用的响应,如果做测试知道这个是特别花钱的,因为你实际模拟一个用户,这个一台机器基本上是六万,一台机器模拟六万个客户,这是我们的常规测试,如果模拟百万用户实时连接,要求二十台机器,十台是60万,二十台机器,但这个对创业公司服务器的成本还是有的。

所以我们怎么做呢? 阿里云是现在也支持了,早期是10%,现在已经按量付费,去使用服务器资源,计费周期是到秒的,所以我们真正去做移动端压力测试的时候,建议大家搞这么一套系统,这个还花的我们一段时间,我们整个有一套脚本,这个脚本从运行就启动一个阿里云,是有API,申请ECS,比如跑一个百万的,可以把服务器申请出来,我们把所有的模板部署上,部署之后先做一个简单验证,整个环境通了,这样就可以去真正模拟,因为一般的模拟场景是百万用户,同时先登服务器,建一个百万的TCP连接,之后模拟一些场景,有的是发消息,有的是客服业务,有的送花有的点赞这些场景模拟完之后,要把测试结果报告,这套有了,这个测试就完了。

但是提醒一下,你可以自动释放服务器,但一般我们做这个操作的时候,我们整个测试结果出来之后,我们看一下,如果说不达到期待,调一下脚本,甚至去改一下服务再测一下。如果没问题,后边就有一个脚本能自动释放,所以整个其实可以全自动的,而且当时我算了一下,如果你是使用,比如按天,不到三天,费用肯定是比包月便宜,即使拿到一个比较高的折扣,大家做移动端自动测试,尤其是这种要做并发的话,我建议就用这种按量,这个是给我们省了不少钱。

5-部署和运维的敏捷保障

 

屏幕快照 2019-06-17 下午2.43.50.png

 

做云服务,做SaaS的有一个,基于租户的灰度发布。

 

屏幕快照 2019-06-17 下午2.45.52.png

 

1.AB测试

AB测试是一种用于提升产品转化率、优化获客的方法。当我们想测试哪个注册页面转化率高时,我们就可以上线两个版本的页面,通过一周、一月的注册数据监测比例来衡量哪个页面效果好。在做云服务,SaaS时,就是基于租户的验证,同样可以适用这种方法。

2.前后端灰度

所有的前端根据cookie中的租户id,转发到不同版本的后端服务。如果进来之后,cookie解决这个租户ID,就可以写个脚本,根据当前给的配置对应的版本打造对应的服务,这是一个常用的功能。

3.移动端灰度

移动端登录后,从路由服务器请求访问地址。以做移动端的经验来说,某一个用户想登到指定的版本如何来做?我们可以做DNS解析,就是手机端不是先去试图访问服务,而是先去访问我们做的解析入口,当前是哪个租户,用户ID是多少,移动端什么版本,应该访问哪个后台版本,然后整个服务会打造相应的后台版本。

如果公司有海外客户,就可以通过DNS解析到海外的配置,移动端的路由可以根据不同用户的区域做不同的配置,链接到不同的服务和版本。

6-学费/教训

 

屏幕快照 2019-06-17 下午3.12.34.png

 

说说学费,从现在看,不管是流程,现在要保证最重要的四个方面:

1-核心要保持稳定

即自身系统的上线流程不能影响到客户的业务流程,可以采用错峰上线、降级开关等措施;

不管是做即时通讯,还是做客服,如果这个系统出问题,都会影响它的业务。

2- 善于提炼客户需求

产品功能需要满足大多数客户的需求; 如果你客户比较多的话,跟销售打交道,容易被忽悠,销售说“你把这个做了就给钱了”或者“如果你把这个做了就行了”。我说哪个重要,销售都说重要。

所以这里面有个技巧,你得需要真正对这个产品有理解,对这个业务理解了,就是用户要的只是他现在想要的,但是如果能把不同的需求,提升到通用的需求,里面加一些开关,能满足大多数的需求,这个是很重要的。

3-成本控制

可以从架构设计出发,尽量用成熟的组件,设计一个低成本的架构; 如果你们做云服务,一开始不觉得,但是如果突然运维给你一个七位数的帐单,一个月。你就认识到,你的架构需要改了,但是如果你看到这个帐单的时候,可能有点晚了

4-注重用户的体验

在移动端,需要多注意产品的兼容性问题。一般用户不会因为体验问题会跟你断约,前面这些事情都是说有可能不给你做,后面的体验做好能给他服务的更好,体验就是刚才说过,可能主要就是注意一下移动端的兼容性,虽然换手机频率高,但是兼容性问题还是比较大的。

 

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

posted @ 2019-06-20 10:28 Worktile 阅读(...) 评论(...) 编辑 收藏