【落叶72】“老兵聊测试”之敏捷引入的初衷

文/秋之川

【目录】

这是《落叶》文集里第 72 片落叶，希望你能喜欢，不为别的，只为这份坚持。

说了好几天敏捷了，为什么这股敏捷风刮得这么长久呢？我们今天就来聊一聊。

背景

我之前所在的公司，做的是企业级的网络会议系统，也就是一种SaaS（Software as a Service）。从面向的客户群体来说，长期以来都没有对新功能的交付速度有很高的要求，一直都是以提供稳定的服务为主。

但突然有一天，老大说，我们要准备转敏捷了，随后很短的时间内，敏捷就蜂拥而至，当时的确有些让我们措手不及，同时在相当长的一段时间里，很多人其实都是有些不理解的，当然，也包括我在内。

不过在跳出当时所处的那个环境之后，再回头去看，其实也明白了一些东西。

引入的初衷：

早些年，我们的产品的确占有很大的份额优势，大概占整个欧美在线会议市场的60%吧。后来几年，原来一些专攻轻量级在线会议系统的公司中，开始出现几家做的比较优秀的，也是因为很多中小型公司的在线会议需求逐渐涌现，其中具有代表性的应该就是 Ctrix，整个团队也就四五十人，功能更新速度非常迅速，对于用户反馈的响应时间也是非常的短。

而我们当时的主版本从开始研发，到全球上线部署，从 Release...BTS...SP1.. SP7... SP12... GA... 最快也需要六个月到一年的时间，等我们若干个大功能上线了，别人家的新鲜热辣的功能都早已上线半年多了。更别说现在这种移动互联网时代的产品更新速度了，六个月到一年的时间，有时候，一款产品从生到死也不过这么长吧。

虽说我们以产品的质量和服务的稳定为重中之重，不过看看别人家的质量也不差呀。而且别人家的团队小而精，人力成本相对小很多，产出比就远远把我们甩开了好几个街区。

所以，市场决定了我们必须不断地改进现有功能和快速上线更新，这样才能在保持现有市场份额的同时，继续提高市场占有率。而不是一味地打着质量第一，稳定第一的旗号，而选择性地忽略掉以速度制胜这一关键性因素。

引入的期望：

1、加快产品新功能的上线速度，能够跟上 OS 和 Browser 越来越快的迭代速度，能够快速及时地响应客户的反馈，从而增加产品的竞争力，提高市场占有份额；

2、大大减少了需求和实现之间的偏差率，降低后期返工所增加的成本和减少项目延期发布的几率。在此之前，就出现过耗费了几百个人日做出来的新功能，PM 说跟他预期的出入太大，有时必须在下个大版本里推翻重来；

3、提升团队自组织、自管理的能力和技术水平，让各个团队始终都处于一种相对饱和，并且积极向上的工作状态；

4、加强 PM、EM、Dev、QA 和运维团队、技术支持团队的合作，提升从设计、开发、测试到上线的流程效率，缩短了新功能上线的周期，提升了用户满意度，并增加了用户的留存率；

5、通过敏捷提高各个团队的人力资源使用效率，减少因为任务分配不均导致的资源闲置现状；

6、提升用户满意度也是期望之一，随着生活节奏的加速，用户对于问题的提出到解决，所能等待的时间也在逐步缩短，但同时又不喜欢频繁的无规律的收到升级通知，这对于版本发布的速度和节奏就有了更高的要求；

作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵

【目录】