从QA到EP

发表于:2014-02-26来源:豆瓣作者:@行知-追寻技术之美点击数: 标签:qa
两三年以前,和友人谈到 QA(软件质量保证) 这个行业,还有 QA 这个团队的未来,就有了一丝忧虑。而现在,终于有机会实践一下自己之前的想法,在这里分享给大家。 从我有限的从业经验到现在,经历了很多次软件开发模式的变化,这些变化,或因为跟风,或

  注:作者:高磊,豌豆实验室技术总监。本文发表于《程序员》杂志 2013 年 8 月刊。

  两三年以前,和友人谈到 QA(软件质量保证) 这个行业,还有 QA 这个团队的未来,就有了一丝忧虑。而现在,终于有机会实践一下自己之前的想法,在这里分享给大家。

  从我有限的从业经验到现在,经历了很多次软件开发模式的变化,这些变化,或因为跟风,或因为有切实的问题要解决,总之始终处于各种不同的尝试的路上。QA 团队从最早的强调流程,到后来强调开发技术,搞自动化测试,再后来又开始做敏捷和持续集成,这条发展的路上,对自己的要求不断变高的同时,也伴随着一个组织和团队发展的魔咒。

  组织发展魔咒

  这个发展的魔咒更像是一个循环,可能开始于任何一个环节。

  例如,公司负责技术的高层,没来由的认为,测试和质量保证并不重要。这个判断会慢慢渗透到技术团队的各个角落,导致测试工程师,乃至测试团队的其他角色,例如SQA,未来发展的空间会被压缩,而压缩发展空间的结果就是留不住人、招不到人。一方面相关工作的经验技能要求越来越高,一方面可见的天花板又摆在那里。于是整个 QA 团队都成了别人眼中的 「低技术」团队,不论真的低技术还是别人以为的低技术,这种印象都很要命,为了摆脱这种印象,大家需要做点东西来证明自己,于是各种自动化测试框架、平台、系统,纷纷出现,殊不知此时,QA 团队和整个公司的价值已经慢慢的不一致了,自己关起门跟自己玩,成了普遍现象之后,在公司高层看来,他会觉得自己的 「QA 团队并不重要」的判断被证明了,因为没有任何明确的证据表明,QA 团队与公司愿景和计划之间的直接联系。

  可怕么?在很多软件研发组织中,这是现实存在的循环。

  说起来我们的实践,确实打破了这个循环,说起来好笑,我们解救 QA 团队的方式,就是彻底取消这个团队。但是反过来讲,只有杀死「QA 团队」,才能真正的解放「QA 工程师们」,真正解放整个软件研发过程。

  一些基本的价值观

  这个事情,就要从一些最基本的价值观说起。

  比如,人总要对自己做的事负责。当然做了漂亮的事情,谁都希望头上有光环,但是做了丑事,也要能忍受得了羞辱。之为 「吃自己的狗食」,而老式的软件开发分段流程,等于鼓励上游做的错事,下游来擦屁股,于是上游颐指气使,下游低三下四,这种颐指气使和低三下四还能传导,于是的于是,最下游的一个环节,就是公认的受气包了。暂不说效率和质量,从最基本的做事方法的角度,似乎也有些欠妥。我们这一条怎么落地呢,就是改组研发团队,建立 Owner 制度。一个项目的 Owner,就像一个项目的 CEO,大事小情都要关注,从产品到开发,从测试到运维,总之一个项目的成败,都需要 Owner 来操心,项目外的人,都是他的资源。相应的,项目也变得和平台无关,而与特性有关,每个项目组都会涉及到几个平台的设计、开发工作。

NewImage

  还比如,给质量一个明确的标准。做质量工作或者测试的人,都会有强迫症,总觉得哪里不对劲,还得狠狠的回归一遍,又一遍。可其实大家都知道质量是没有个确定的标准说好还是坏的,那怎么确定质量呢?我们称作 「质量体现在造成实际的影响上」,也就是说,一个严重的问题,如果没造成影响,或很轻微,那就不严重。而一个轻微问题,如果影响面很广,例如有 1000 万用户都看见了,那就不轻微。

  又比如,交付一个完美产品还是建立一个快速召回的机制?我们确实真的想每时每刻都能交付一个完美无暇的产品,但那不可能。特别是在互联网行业,跟传统的电信、医疗、航空航天的产品迭代有天壤之别,一个完美产品用一年做出来,市场可能早就变了天了。但不完美就有质量风险和代价,为了平衡这一点,我们必须建立一个快速召回缺陷产品的机制,甚至能让用户在发现缺陷之前,就用上了新版本。

  有了这几条价值观,我们就大概知道开发过程改进的方向,以及做事情的原则了。那我们做了什么呢?我们组建了 EP 团队。

  EP 是什么

  说到这里,EP 这个词才第一次出现,这个词的内涵之丰富,可能需要仔细说说。

  我最早看到 EP 这个词,是在当时还是 Google EP 团队成员的 James Wittaker 写的那一个有名的 「How Google Test」的系列博客中,内容我就不转述了,很多人都读过。

  EP 是 Engineering Productivity 的缩写,工程生产力的意思,这个团队,就是给整个大技术团队,甚至整个公司提高工作效率的。通俗直白的说,就是一个工具团队。因为工欲善其事、必先利其器,不要小看工具团队,某些程度上来讲,一个产品随着市场的变化可能很快凋亡,而一个好的工程工具,生命力要强得多,比如,开发语言其实就是最基本的工程工具了。那么,对一个公司,或者说交付团队来讲,怎么衡量工程生产力的高低呢?这个衡量方式其实就决定了「EP团队」的工作方向。我们自己定义的工程生产力从低到高的定义是这样的:1)质量,这是最基础的指标,什么都不行,也要保证质量过关,否则一个产品连生存的可能都没有。2)同等质量水平下,追求速度。质量过关了,就要看迭代速度了,你比竞争对手快,你就能活下来。3)同等质量和速度下,工程师的幸福感。如果质量也过关了,速度也快,但是大家过得很苦,天天加班,重复劳动,看不到未来,这也不行。幸福是什么?对我们来说,就是不被反复的简单问题所困扰,该自动的都自动,自动不是说一定快,但是一定省心,这里的幸福就是省心,有精力去关注更多的有意义的事情,而不是每天处理简单重复的问题。4)同等质量和速度,也有幸福感,再看成长。工程师们有没有感受到成长?不断的解决问题或开发产品,感受到的是重复劳动还是成长?其实前三点都做到了,第四点一定是有的。

  EP 做什么

  我们回头说 EP 团队,EP 团队也有自己的人生理想,那就是一个三部曲:替、教、独立。

  第一个是替的阶段,其实就是比较老式的开发过程,我替你测试、替你上线、替你运维。

  这个阶段,完全不符合我们「吃狗食」那一条价值观,按照狗食法则,一个人自己设计开发编码,当然要自己测试,自己写的代码 bug 多要一遍遍回归,这个苦果自己不吃谁来吃?但没办法,大多数程序员在如何测试自己的程序方面没有受过什么训练,为了尽快发布产品,只能替,但这个替的时间要越短越好,尽快进入下一个阶段,教。

原文转自:http://www.wangyuxiong.com/archives/52072

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)