【编者按】说起敏捷大家并不陌生，自从国外引进后，一直都很火，很多人都在讨论。无论是项目延期，失败，质量低下等等，你总能听到：“你是不是没有敏捷？”。因此，敏捷就成了包治百病的“灵丹妙药”。于是很多项目组公司开始学习敏捷、采用敏捷。但是遗憾的是很多人尝试过后发现以前的问题并没有被敏捷所解决掉，反而带来了很多新的问题。

在《敏捷，是灵丹妙药还是又一个忽悠？》这篇文章中也曾提到，很多人为了敏捷，文档不要了，计划不要了，测试用例也不要了，认为几个人站在走廊里沟通沟通就把一切都搞定了，因为敏捷了嘛。但是问题并没有因为“敏捷“了而被解决掉，于是乎得出敏捷是个忽悠的结论。

作者Dylan是腾讯无线研发部副总监，拥有十多年测试行业经验。此前dylan在腾讯和华为主场展开了关于敏捷研发质量的技术交流。作为分享嘉宾之一的Mary就回顾通信和移动互联网两个行业的敏捷研发理念差异， 并结合自身经历做了一番思考。下面我们一起来看下：

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

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

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

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

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

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

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

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

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

最后发现，没有一个要素能真正把互联网和其他软件领域区别开来，所以我们只能这么看：瀑布研发和敏捷研发没有本质不同，更别说谁好谁坏了，只是因为行业竞争的不同，看起来交付节奏不一样而已。节奏和软件研发的传统精髓没有关系。

今天竞争足够激烈（利润够大），华为必须快速占领某国市场了，它可以立马快速的研发和交付明天手机QQ成最大IM平台了，它可以一年提交一个新版本，比传统软件业的质量环节更多更严。

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

批判常见的几个敏捷误区 

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

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

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

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

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

2 ．沟通比文档更重要

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

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

团队人数数十人甚至上百
项目生命力长，每个版本都有新功能，模块越来越多，越来越复杂
异地团队，合作研发
有外包，合作方团队协同工作
团队职业化水平高低不齐
团队不太稳定，或业务归属部门不太稳定

没有文档的恶果，可以参看以下的事件：

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

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

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

但是这个行业的团队需要图形化，模块化，可视化程度高，逻辑详细完整准确，容易传播的文档：如产品逻辑+异常逻辑图，软件架构设计图，经典BUG根因分析，体验/竞品体验分析公司可以考虑把可视化编辑工具集成到WEB端，直接在网页上编辑和查阅文档。

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

3． 边重构，边生活

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

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

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

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

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

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

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

对于可测内容追求在一段时间周期内，尽可能高质量的发布，是修炼职业操守的目标，更是精品团队的目标。每一个挂起的有效BUG都需要确认：为什么改不了？什么时候改？对发布影响如何？ （当然，因Android平台的碎片化会带来大量难以重现的机型相关问题，我们可以通过其它技术手段处理）

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

 

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

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

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

 

对于敏捷研发的忽悠观点，就批判这么多。精品观，本人的理解首先要回归职业的原点。每个角色坚守职业操守，会让团队成为老虎 ，让我们在精品路上走得更远。