反思：别被敏捷忽悠

张鼎 (dylan) 目前担任腾讯无线研发部副总监，加入腾讯前在北电公司工作，曾参与制定通讯测试国际规范，十多年测试行业经验。他最近撰文以“别被敏捷忽悠——关于敏捷研发的跨界反思”为题谈到了对于敏捷研发的一些看法，结合自己的经验对“敏捷研发理论是否被神化了”这个问题进行了深入的分析。

dylan 认为随着 IT 热潮从传统软件业转移到移动互联网领域，质量标准正在被弱化。

传统大型软件公司，开发节奏慢周期长，QA 和测试环节受重视程度高，测试结论有权威性，越在后期发现的 Bug 让开发人员如临大敌。转型来到移动互联网部门，咱开始学习敏捷研发理论了，接受起来蛮顺利，随着参与项目的增多，越来越感受到自己的职业价值观不断受到挤压，各种混乱事件让测试人员及团队挺纠结。

质量标准很难成为严格遵守的权威，表现在以下几个方面：

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

据 dylan 所说，其领导的团队采用了旁敲侧击的方法提升研发质量，比如帮忙开发便利的自测工具、合作分析代码覆盖率、冒充用户上论坛投诉、拿竞争对手的结果来刺激团队等等，但始终是治标不治本。

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

他认为，瀑布研发和敏捷研发没有本质不同，理由如下：

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

结论就是，没有一个要素能真正把互联网和其他软件领域区别开来，所以 dylan 认为：

瀑布研发和敏捷研发没有本质不同，，更别说谁好谁坏了，只是因为行业竞争的不同，看起来交付节奏不一样而已。节奏和软件研发的传统精髓没有关系。

除此之外，dylan 还批判了常见的几个敏捷误区。刚毕业的学生进入公司要怎么培养？dylan 建议 2-3 年的职场新人不要学习任何敏捷流程的理论：

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

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

另一个误区，dylan 认为是“沟通比文档更重要”：

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

但是如果你是以下情况的团队，dylan 认为文档可能真的比沟通更重要：

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

dylan 特意列举了几种缺乏文档的糟糕情况：

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

第三，dylan 认为不要“边重构，边生活”：

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

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

最后，dylan 强调，不要存在“迭代版本的 BUG 多一点是正常的”的误区：

每个交付到测试团队的产品，必须是可测的，自测过的。不可测的版本就不叫交付。对于可测内容追求在一段时间周期内，尽可能高质量的发布，是修炼职业操守的目标，更是精品团队的目标。每一个挂起的有效 Bug 都需要确认：为什么改不了？什么时候改？对发布影响如何？

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

随着敏捷开发在 IT 行业的深入推广，敏捷的优点不再被业界无限放大，而更多的社区声音开始讨论敏捷的正反两方面，dylan 的观点可以给读者朋友一些不同的启示和借鉴。