这是《落叶》文集里第 187 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
昨天因为很多同学想知道什么是敏捷，所以简单说了说，今天有些同学就在问，为什么一定要用敏捷，瀑布不能用吗？我觉得在面对敏捷的时候，能对为什么要用它而产生疑问的同学很不错，至少他们不会盲目跟风，人云亦云。
【你问】
我们为什么一定要引入敏捷呢？
【我答】
我先从亲身经历说起，我之前所在的公司，做的是企业级的网络会议系统，也就是一种SaaS（Software as a Service）服务。从面向的客户群体来说，长期以来都没有对新功能的交付速度有很高的要求，一直都是要求服务稳定为主。
但突然有一天，老大说，我们要准备转敏捷了，随后很短的时间内，敏捷培训、项目转型等等就蜂拥而至，当时的确有些让我们措手不及，在相当长的一段时间里，很多人其实都是有些不理解的，当然，也包括那时候的我在内。
不过在跳出当时所处的那个环境之后，再回头去看，其实也明白了一些东西，现在写出来，有着不同经验的人，应该都能从中看到一些自己想了解的东西吧。
引入敏捷的初衷：
早些年，我们的产品的确占有很大的份额优势，大概占整个欧美在线会议市场的 60% 吧。后来几年，原来一些专攻轻量级在线会议系统的公司中，开始出现几家做的比较优秀的，也是因为很多中小型公司的在线会议需求逐渐涌现，其中具有代表性的应该就是 Ctrix，整个团队也就四五十人，功能更新速度非常迅速，对于用户反馈的响应时间也是非常的短，所以我们的在线会议市场的份额就被不断地蚕食。
而我们当时的主版本从开始研发，到全球上线部署，从 Release...BTS...SP1.. SP7... SP12... GA... 最快也需要六个月到一年的时间，等我们若干个大功能上线了，别人新鲜热辣的功能都早已上线半年多了。更别说现在这种移动互联网时代的产品更新速度了，六个月到一年的时间，有时候，一款产品从生到死也不过这么长吧。
虽说我们以产品的质量和服务的稳定为重中之重，不过看看别人家的质量，也没有差到哪去，服务也挺稳定的，虽然没达到四个9，也有三个9。而且别人家的团队小而精，人力成本相对小很多，产出比就远远把我们甩开了好几个街区。
所以，市场决定了我们必须不断地改进现有功能和快速上线更新，这样才能在保持现有市场份额的同时，继续提高市场占有率。而不是一味地吃着质量第一，稳定第一的老本，而选择性地忽略掉以速度制胜这一关键性的因素。
引入敏捷的期望：
1、加快产品新功能的上线速度，能够跟上 OS 和 Browser 越来越快的迭代速度，能够快速及时地响应客户的反馈，解决 Customer Ticket，从而增加产品的竞争力，提高市场占有率；
2、大大减少了产品需求和最终实现之间的偏差率，降低后期返工所增加的成本和减少项目延期的风险。在此之前，就出现过耗费了几百个人日做出来的新功能，PM 说跟他预期的出入太大，必须在下个大版本里推翻重来，甚至于会一而再再而三的重来；
3、提升团队自组织、自管理的能力和技术水平，让各个团队始终都处于一种相对工作量饱和，并且积极向上的工作状态；
4、加强 PM、EM、DEV、QA 和运维团队、技术支持团队的合作和沟通，提升从设计、开发、测试到上线的流程效率，缩短了新功能上线的周期；
5、通过敏捷提高各个团队的人力资源使用效率，减少因为任务分配不均导致的资源闲置状况；
6、提升用户满意度也是期望之一，随着生活节奏的加速，用户对于问题的提出到解决，所能等待的时间也在逐步缩短，但同时又不喜欢频繁的无规律的收到升级通知，这对于版本发布的速度和节奏就有了更高的要求；
最后还想强调一点，敏捷研发模式的引入一定是基于现有流程存在问题的基础上的，不能为了敏捷而敏捷，要就具体问题分析，如果只有引入敏捷才能解决，那再引入，否则，最佳办法还是就事论事，就问题解决问题。
《测试路上你问我答》里的 Q&A 45，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
