马晓宇 – 环信联合创始人 / 执行总裁
我们是一个做云服务的创业公司，所以我就云服务创业公司的角度，来谈谈我们是怎么去实践敏捷开发的。确切地说，就是讲讲我们这几年的这些教训 …
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 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。