作者:dylan,腾讯无线研发部副总监,加入腾讯前在北电公司工作,曾参与制定通讯测试国际规范,十多年测试行业经验。

 

上月初腾讯和华为联合组织了首届质量日活动,分别在腾讯和华为主场展开了关于敏捷研发质量的技术交流。笔者有幸作为分享嘉宾之一,回顾通信和移动互联网两个行业的敏捷研发理念差异,也结合自身经历做了一番思考。越琢磨越觉得,槽点很多,不吐不快,在此斗胆拍砖,欢迎一同吐槽!

 

从传统软件业到移动互联网- 质量标准的弱化

 

传统大型软件公司,开发节奏慢周期长,QA和测试环节受重视程度高,测试结论有权威性,越在后期发现的BUG让开发人员如临大敌。

 

转型来到移动互联网部门,咱开始学习敏捷研发理论了,接受起来蛮顺利,随着参与项目的增多,越来越感受到自己的职业价值观不断受到挤压,各种混乱事件让测试人员及团队挺纠结,

 

质量标准很难成为严格遵守的权威

 

  • 开发自测不足!-----新功能都开发不过来,自测随便意思一下就好了
  • 迭代发现的一堆BUG不改!----产品还是过渡期,说不定集成测试前BUG就消失了
  • BUG不需要改!----我刚和产品沟通过了,需求变更一下就好了!
  • BUG无效?---- 我代码就是这么实现的嘛,这么处理也没什么不好
  • BUG挂起太多!----你看看市场竞争这么激烈,每个BUG都深入判断我们哪有时间?
  • 发布产品已知BUG不少!---- 迭代发布产品有些遗留BUG很正常,慢慢优化嘛

 

 

整个就是测试团队的纠缠血泪史。这几年我们也采用了旁敲侧击的方法提升研发质量,比如帮忙开发便利的自测工具,合作分析代码覆盖率,冒充用户上论坛投诉,拿竞品对手的结果来刺激团队等等,但始终是治标不治本。

 

回头再看看,所有掩盖在敏捷研发过程中的漏洞,日积月累,最终还是会由整个业务团队来承担苦果。所以时常在想,敏捷研发理论是否被神化了,是否常被错误理解而让不职业的现象层出不穷?

 

敏捷不是新的研发理论,只是项目管理的一种形式

 

传统研发模式和敏捷模式到底有什么要素是不同的?或者说,传统软件和互联网软件有什么不同?

 

  • 是迭代发布的周期不同?某些互联网产品的版本发布周期一点都不短。入口级的移动APP动辄上百人的团队,规模比多数PC软件团队还大
  • 是有云和没云的不同?很多行业的后台(云架构)比一般互联网公司复杂多了
  • 是收费和免费导致的不同?传统行业也有很多免费软件。互联网的有些免费软件比传统软件质量要求更高
  • 是对产品迭代发布的质量要求不同?
  • 是对文档的要求不同?

等等…….

 

最后发现,没有一个要素能真正把互联网和其他软件领域区别开来,所以我们只能这么看:

 

瀑布研发和敏捷研发没有本质不同,更别说谁好谁坏了,只是因为行业竞争的不同,看起来交

付节奏不一样而已。节奏和软件研发的传统精髓没有关系

 

今天竞争足够激烈(利润够大),华为必须快速占领某国市场了,它可以立马快速的研发和交付

明天手机QQ成最大IM平台了,它可以一年提交一个新版本,比传统软件业的质量环节更多更严。

 

 

研发团队根据行业(用户)需求和生存情况来决定敏捷节奏(如上图的四种生存情况),但是团队的内在素质能力不应该有什么差异。传统软件行业素养高的开发,换到互联网团队,同样素养高。



 

批判常见的几个敏捷误区

 

既然如此,我们来依次对公司里流行的关于敏捷的伪论断进行剥皮:

 

1.新人培训从敏捷研发开始

 

刚毕业的学生进入公司要怎么培养?本人建议2-3年的职场新人不要学习任何敏捷流程的理论:

  • 测试岗位的就好好的把一个功能设计出N种场景,使用各种工具反复测试找敏锐感
  • 开发岗位的不是要尽快实现一堆功能,而是先充分理解架构,然后对提交的每一行代码负责
  • 产品岗位的多体验产品多接触用户,头几年最好脱离QQ的关系链,锻炼发布独立产品的能力

总之,入行新人要学四个字-职业操守,刻在心里,打好基本功,未来不管在什么项目都会受用。

 

 

2.沟通比文档更重要

 

这句话看起来有道理,如果你是几个人的小团队,如果人员稳定,功能模块比较聚焦,生命周期也不太长,也没客户找你要什么手册,确实不需要写什么文档。

 

但是如果你是这样的团队,文档可能真的比沟通更重要

 

1.          团队人数数十人甚至上百

2.          项目生命力长,每个版本都有新功能,模块越来越多,越来越复杂

3.          异地团队,合作研发

4.          有外包,合作方团队协同工作

5.          团队职业化水平高低不齐

6.          团队不太稳定,或业务归属部门不太稳定

 

 

没有文档的恶果,可以参看以下的事件:

 

  • 某产品经理忘了半年前的某个功能的具体逻辑,寻求测试同学的帮助
  • 某开发参加高职级晋升,手上没有一个像样的软件架构图,拿着测试MM梳理的逻辑架构图去评审
  •  一个严重BUG的坑在N个项目组被踩了N次,修复每个BUG后的注释只有几个字。
  •  跨地域的团队,或者前后台的团队之间,发生BUG时互相争执半天,讨论谁该负责修复BUG,彼此不熟悉对方的内部逻辑
  • 至于没有参考文档导致测试投入浪费的事就太常见了

 

公司业务调整,跨部门和跨地域的业务交接不太愉快,交接效率低

 

以上6个要素,符合的越多,文档必要性就越大,尤其是以精品为唯一导向的大公司,首先要有对文档的基本认识。无数软件行业的先辈都不是傻子,文档上偷懒谁都会。

 

这个行业也许不需要利用率太低,可读性差,格式复杂死板,更新太频繁的文档,比如:

 

 

但是这个行业的团队需要图形化,模块化,可视化程度高,逻辑详细完整准确,容易传播的文档:如产品逻辑+异常逻辑图,软件架构设计图,经典BUG根因分析,体验/竞品体验分析

 

公司可以考虑把可视化编辑工具集成到WEB端,直接在网页上编辑和查阅文档。

 

 

 

 

我们甚至可以利用创新的输入工具,提高文本录入的效率。如我们的APP自研反馈工具利用语音识别接口,录入BUG的问题描述

 

 

3 边重构,边生活

 

窃以为这句话只在刀架在脖子上才有效。实在不得已而为之(例如面临生死存亡之类的危机)。没想清楚长期架构,最好不要急着开工。磨刀不误砍柴工是真理。

 

以前公司的开发,30-40%的时间花在概念设计和架构设计,30%在细节设计,10%coding, 20-30%在代码自测。CODING本身只占很少一点时间。技术总监这样教育新人:你不是coder,你是designercoder是比较低级的工作,软件设计才是高端活。

 

任何时候的思考,对于架构的投入怎么充分都不为过。微信发布那么多版本,这两年重构可能几乎没有。这需要有人尽早思考清楚未来做朋友圈,做开放接口,做插件化等等,开发知道了未来要演进的形态,在一开始就有所规划,预留接口。否则,今天决定要做SNS,重构一次,明天要做插件化,再重构一次,后天作开放平台和公共帐号,再重构…..对公司来说就是个噩梦了。

 

 

如果团队没有架构大牛,则需要充分的头脑风暴,每个迭代不能只想近期要做什么,面向未来思考和归纳。警惕以下案例:

  • 有的新版本代码变更率超过60%,质量风险该有多大?
  • 拿近期运营活动噱头作为本版本的核心开发功能,本末倒置,运营本应是对核心能力宣传包装,而不是改变核心能力方向。

 

4.迭代版本的BUG多一点是正常的

 

首先,每个交付到测试团队的产品,必须是可测的,自测过的。不可测的版本就不叫交付!

 

对于可测内容追求在一段时间周期内,尽可能高质量的发布,是修炼职业操守的目标,更是精品团队的目标。

 

每一个挂起的有效BUG都需要确认:为什么改不了?什么时候改?对发布影响如何?

 

(当然,因android平台的碎片化会带来大量难以重现的机型相关问题,我们可以通过其它技术手段处理)

 

如果因市场形势必须要尽快发布,至少遵守一个底线:严重BUG必须整改而且优先整改。所谓严重就是可能让用户抛弃你的问题:速度慢,卖点明显不如对手,卖点无法正常使用,不稳定,可能给用户带来额外损失(手机系统,安全,账号,费用等等)。这样的发布还不如不发。

 

 

每个版本建议总结一下:严重BUG以及用户投诉大的问题,根源是什么,改进措施是什么,归档分享。

 

对于迭代测试发现的一堆问题都攒到最后,期望有天能自动消失的项目团队,我都不想点评了。每一个莫名放过缺陷的产品都可能成为一个折翼的天使

 

精品研发团队,应该对眼里的软件错误有洁癖,就算修复不了,我也记录下来错在哪里。

 

 

对于敏捷研发的忽悠观点,就批判这么多。精品观,本人的理解首先要回归职业的原点。

每个角色坚守职业操守,会让团队成为老虎,让我们在精品路上走得更远。