写点什么

反思:别被敏捷忽悠

  • 2014-02-13
  • 本文字数:2394 字

    阅读完需:约 8 分钟

张鼎 (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 的观点可以给读者朋友一些不同的启示和借鉴。

2014-02-13 01:495379
用户头像

发布了 501 篇内容, 共 273.1 次阅读, 收获喜欢 62 次。

关注

评论

发布
暂无评论
发现更多内容

2022中国物流产业大会暨企业家高峰论坛在杭州举办!

联营汇聚

怎么实现您的个人知识库?

Geek_da0866

四、HikariCP源码分析之初始化分析一

阿白

数据库 源码解析 HikariCP 源代码 连接池

新型LaaS协议Elephant Swap给ePLATO提供可持续溢价空间

BlockChain先知

不要再用if-else!

Jackpop

SQL 改写系列七:谓词移动

OceanBase 数据库

八、HikariCP源码分析之ConcurrentBag一

阿白

数据库 源码解析 HikariCP 源代码 连接池

推荐 7 个学习 Web3 的开源资源

devpoint

blockchain Solidity web3 7月月更

纯css实现:单行文本的打字机动画效果

南极一块修炼千年的大冰块

7月月更

Serverless实战——2分钟,教你用Serverless每天给女朋友自动发土味情话

Serverless Devs

#Serverless

三、HikariCP源码分析之获取连接流程三

阿白

数据库 源码解析 HikariCP 源代码 连接池

十一、HikariCP源码分析之HouseKeeper

阿白

数据库 源码解析 HikariCP 源代码 连接池

二、HikariCP源码分析之获取连接流程二

阿白

数据库 源码解析 HikariCP 源代码 连接池

五、HikariCP源码分析之初始化分析二

阿白

数据库 源码解析 HikariCP 源代码 连接池

数据安全建设

奔向架构师

数据资产 7月月更

互联网基石:TCP/IP四层模型,由浅入深直击原理!

wljslmz

计算机网络 TCP/IP 网络技术 OSI模型 签约计划第三季

经验分享|编写简单易用的在线产品手册小妙招

Baklib

面向大数据存算分离场景的数据湖加速方案

Baidu AICLOUD

数据湖 对象存储 元数据 存算分离 层级namespace

九、HikariCP源码分析之ConcurrentBag二

阿白

数据库 源码解析 HikariCP 源代码 连接池

Apache Doris 1.1 特性揭秘:Flink 实时写入如何兼顾高吞吐和低延时

SelectDB

数据库 flink 数据仓库 Doris 数仓

七、HikariConfig初始化分析

阿白

数据库 源码解析 HikariCP 源代码 连接池

人社部公布“数据库运行管理员”成新职业,OceanBase参与制定职业标准

OceanBase 数据库

一、HikariCP源码分析之获取连接流程一

阿白

数据库 源码解析 HikariCP 源代码 连接池

六、HikariConfig配置解析

阿白

数据库 源码解析 HikariCP 源代码 连接池

MIT TR50榜单公布 《麻省理工科技评论》评价毫末智行是AI自动驾驶界的颠覆势能

科技大数据

智能车

资源集合

贾献华

7月月更

知识库对企业的意义

Baklib

7 行代码搞崩溃 B 站,原因令人唏嘘!

Python猫

leetcode122. Best Time to Buy and Sell Stock II 买卖股票的最佳时机 II(简单)

okokabcd

LeetCode 数据结构与算法 贪心算法

高性能数据访问中间件 OBProxy(三):问题排查和服务运维

OceanBase 数据库

设计消息队列存储消息的MySQL表格

joak

反思:别被敏捷忽悠_DevOps & 平台工程_崔康_InfoQ精选文章