张鼎(dylan)目前担任腾讯无线研发部副总监,加入腾讯前在北电公司工作,曾参与制定通讯测试国际规范,十多年测试行业经验。他最近撰文以“别被敏捷忽悠——关于敏捷研发的跨界反思”为题谈到了对于敏捷研发的一些看法,结合自己的经验对“敏捷研发理论是否被神化了”这个问题进行了深入的分析。
dylan认为随着IT热潮从传统软件业转移到移动互联网领域,质量标准正在被弱化。
传统大型软件公司,开发节奏慢周期长,QA和测试环节受重视程度高,测试结论有权威性,越在后期发现的Bug让开发人员如临大敌。转型来到移动互联网部门,咱开始学习敏捷研发理论了,接受起来蛮顺利,随着参与项目的增多,越来越感受到自己的职业价值观不断受到挤压,各种混乱事件让测试人员及团队挺纠结。
质量标准很难成为严格遵守的权威,表现在以下几个方面:
据dylan所说,其领导的团队采用了旁敲侧击的方法提升研发质量,比如帮忙开发便利的自测工具、合作分析代码覆盖率、冒充用户上论坛投诉、拿竞争对手的结果来刺激团队等等,但始终是治标不治本。
回头再看看,所有掩盖在敏捷研发过程中的漏洞,日积月累,最终还是会由整个业务团队来承担苦果。所以时常在想,敏捷研发理论是否被神化了,是否常被错误理解而让不职业的现象层出不穷?敏捷不是新的研发理论,只是项目管理的一种形式。
他认为,瀑布研发和敏捷研发没有本质不同,理由如下:
结论就是,没有一个要素能真正把互联网和其他软件领域区别开来,所以dylan认为:
瀑布研发和敏捷研发没有本质不同,,更别说谁好谁坏了,只是因为行业竞争的不同,看起来交付节奏不一样而已。节奏和软件研发的传统精髓没有关系。
除此之外,dylan还批判了常见的几个敏捷误区。刚毕业的学生进入公司要怎么培养?dylan建议2-3年的职场新人不要学习任何敏捷流程的理论:
总之,dylan认为,入行新人要学四个字——职业操守,刻在心里,打好基本功,未来不管在什么项目都会受用。
另一个误区,dylan认为是“沟通比文档更重要”:
这句话看起来有道理,如果你是几个人的小团队,如果人员稳定,功能模块比较聚焦,生命周期也不太长,也没客户找你要什么手册,确实不需要写什么文档。
但是如果你是以下情况的团队,dylan认为文档可能真的比沟通更重要:
dylan特意列举了几种缺乏文档的糟糕情况:
第三,dylan认为不要“边重构,边生活”:
以前公司的开发,30-40%的时间花在概念设计和架构设计,30%在细节设计,10%在编码, 20-30%在代码自测。编码本身只占很少一点时间。技术总监这样教育新人:你不是coder,你是designer!coder是比较低级的工作,软件设计才是高端活。
任何时候的思考,对于架构的投入怎么充分都不为过。微信发布那么多版本,这两年重构可能几乎没有。这需要有人尽早思考清楚未来做朋友圈,做开放接口,做插件化等等,开发知道了未来要演进的形态,在一开始就有所规划,预留接口。否则,今天决定要做SNS,重构一次,明天要做插件化,再重构一次,后天作开放平台和公共账号,再重构……对公司来说就是个噩梦了。
最后,dylan强调,不要存在“迭代版本的BUG多一点是正常的”的误区:
每个交付到测试团队的产品,必须是可测的,自测过的。不可测的版本就不叫交付。对于可测内容追求在一段时间周期内,尽可能高质量的发布,是修炼职业操守的目标,更是精品团队的目标。每一个挂起的有效Bug都需要确认:为什么改不了?什么时候改?对发布影响如何?
如果因市场形势必须要尽快发布,至少遵守一个底线:严重Bug必须整改而且优先整改。所谓严重就是可能让用户抛弃你的问题:速度慢,卖点明显不如对手,卖点无法正常使用,不稳定,可能给用户带来额外损失(手机系统,安全,账号,费用等等)。这样的发布还不如不发。
随着敏捷开发在IT行业的深入推广,敏捷的优点不再被业界无限放大,而更多的社区声音开始讨论敏捷的正反两方面,dylan的观点可以给读者朋友一些不同的启示和借鉴。
联系客服