马晓宇 -- 环信联合创始人 / 执行总裁
我们是一个做云服务的创业公司, 所以我就云服务创业公司的角度, 来谈谈我们是怎么去实践敏捷开发的. 确切地说, 就是讲讲我们这几年的这些教训...
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 - 注重用户的体验
在移动端, 需要多注意产品的兼容性问题. 一般用户不会因为体验问题会跟你断约, 前面这些事情都是说有可能不给你做, 后面的体验做好能给他服务的更好, 体验就是刚才说过, 可能主要就是注意一下移动端的兼容性, 虽然换手机频率高, 但是兼容性问题还是比较大的.
来源: https://www.cnblogs.com/worktile/p/11057173.html