BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

反思:别被敏捷忽悠

| 作者 崔康 关注 1 他的粉丝 发布于 2014年2月14日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

很同意!运用敏捷能否成功,和团队的素质关系太大了。 by Jason Lee

很同意!运用敏捷能否成功,和团队的素质关系太大了。

先把瀑布做好,再来谈敏捷 by mei xuesong

很赞成这篇文章的观点!一看就是从实际情况总结出来的。赞一个。个人觉得先把瀑布做好,再来谈敏捷。

先把瀑布做好,再来谈敏捷 by mei xuesong

很赞成这篇文章的观点!一看就是从实际情况总结出来的。赞一个。个人觉得先把瀑布做好,再来谈敏捷。

人不行,啥都不行 by Wong Peter

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

敏捷里有那条是告诉你上述行为正确的!!??

“沟通比文档更重要”是说不要写文档了吗?

瀑布和敏捷也许从步骤上来说没有不同:都有需求,设计,编码,测试,部署等。但思想上是截然不同的。瀑布认为前期就能捕获所有需求,而敏捷恰恰相反。所以从本质上说这是两种完全不同的开发方法。

传统研发模式和敏捷模式到底有什么要素是不同的?是思考方式。

敏捷没有理解到位 by 刘 松

应该是敏捷没有理解到位,实施的有问题,敏捷恰恰强调的是品质。敏捷的种种实践,比如结对编程,测试驱动,持续集成等,无一不是为了提升品质。实施敏捷的目的不是为了短时间交付更多的东西,我觉得实施的人应该理解敏捷的文化才对。

关于软件工程 by 葛 益宁

呵呵,软件工程的目标是成功地获得产品或完成项目。
我觉得不应该从用什么工程方法去做产品或项目开始,而是以考虑产品或项目采用什么工程方法更合适、更合理为起点。
再补充一点,各种软件工程方法都是有道理的,但会有不同的适合场景。

对敏捷的理解和实施都太离谱了吧 by Kuai Dean

都无力吐槽了,就像有人指着拖鞋说:别忽悠,这手机哪能打电话啊?!
我觉得只要看过市面上任何一本讲敏捷的书都不至于产生这样的误解。

同意,没有万能仙丹 by 龚 如曦

没有一种开发方法是包打天下的灵丹妙药,每个方法都有自身的适用的场景和范围,都需要根据团队的实际项目来做选择和裁剪。

一声叹息 by 刘 松

没有敏捷的个体思维和集体认同,单单只是套概念真是太可悲了。
IT企业里这种环境又十分普遍,没准跟大环境和文化都有关系,从个体说,跟个人的发展经历也相关吧。
作者这篇文章可以算是缺失敏捷意识形态的环境困惑,应该代表了一批人的想法。
我觉得吧,要么跳出以往的经历和环境去看看想想,探索突破口,要么就给它冠名成有某某公司特色的敏捷吧。
传统大型IT公司和开拓型创业公司的人,就是处于两个世界啊。要一个世界的人理解另一个世界的工作生活状态,采用它们的方式,不走出去不行。

另外,楼上还有个ID是刘松,握个手。

补充一下,类比现在的社会大环境,如果每个人坚守诚实、正直、守信、担当这几点,那么前朝和今朝提的几荣几耻、几个代表、什么梦,那都不是事

看到这篇文章的内容无力吐槽了 by qiang yang

里面有些内容对于初步实施敏捷的团队还是很有警醒意义的,不过这些大多是对敏捷理解不够导致的,国内环境下确实会出现这些问题;
瀑布更多的泯灭人的本性,而敏捷给予团队成员更多的尊重和要求,如果团队成员用敏捷作为偷懒和不作为的借口就太可悲了...

任何开发都是有限资源下的工作 by li min feng

在有限时间(进度要求),成本有限,开发人员素质有限的情况下,敏捷应用到位不容易啊!

这种文章价值在哪? by zhang ideasea

......

Re: 任何开发都是有限资源下的工作 by Chen Rain

确实,在资源有限的情况下,什么理论都要打折扣

Re: 人不行,啥都不行 by lin derek

这个答复是比较中肯的,原文作者对敏捷的理解有偏差

最讨厌动不动就裁剪和选择 by jiang jianbo

原版的都没有理解到位,怎么可能有能力选择和裁剪?面对一辆车,如果工程师连车的结构都不理解,你会放心把车交给他改装?软件开发流程也一样,但是很多人就敢不理解就动手干。这个才是失败的根源!

作者说的这个是腾讯的问题,不是敏捷的问题 by jiang jianbo

就我的实践经验来说,敏捷的团队活力明显高于瀑布团队,沟通工作量明显大于其他团队。因此团队有精力做很多以前做不到的事情,比如文档的完整性,功能的开发速度等。但是团队负责人的素质直接影响到敏捷的实施效果。要充分利用SCM和QA的介入力量,从第三方对文档和知识积累提出要求,实施会更顺利。

文章作者提出的问题,明显就是团队负责人对配置管理、测试方面不懂或不重视导致的。根本就是腾讯自己的问题。

Re: 一声叹息 by jiang jianbo

只要是挂上 XX 特色的 YYYY 这种句子,从中国的实践来看,多半就和原版的YYYY就没关系了。敏捷也是如此,只要你决定开始自己公司特色的敏捷,多半就不敏捷了

Re: 一声叹息 by 刘 松

“作者说的这个是腾讯的问题,不是敏捷的问题”
你说的对。

似乎作者长期以来从事测试领域,又长期在“大企业”,有这样的想法就不难理解了。

敏捷团队中各角色(产品、开发、测试等)的职责相比传统团队不太一样了。

敏捷推崇对成员的尊重和激励,一个良好的敏捷团队,每个人都有很强的责任心和主动性,也掌握了必要的沟通能力,各角色间的交流更频繁。
早期接触敏捷的时候,有一种思路,是把传统流程的”以管理为中心“,改回到”以开发为中心“。随着敏捷各流派的壮大和演进,这个思路已经模糊了,其它实践也丰满起来。
但同时,敏捷中对开发人员的代码质量有更高的要求。因为敏捷激发的责任感,必然会使开发人员重视质量,且有TDD这类实践。从职责上看,似乎开发部门要接管测试部门的一部分工作,比如facebook那种结构。
敏捷下各角色之间的职责,尤其是开发和测试,可能需要重新定位了。
比如文档不足的问题,支持jiang jianbo“要充分利用SCM和QA的介入力量,从第三方对文档和知识积累提出要求,实施会更顺利。"


在一个延续了传统的管理思维,延续了传统的组织结构的大公司下,像文章作者提到的,开发部门拿敏捷的某项实践作为借口拒绝修改bug,测试部门不得不借助其它手段施压,两个部门是两个利益集团,互相推诿,何谈敏捷。
jiang jianbo说的”团队负责人的素质直接影响到敏捷的实施效果“,十分同意。团队负责人对产品的核心价值、关键功能和设计、实施路线图有没有明确的思路,有没有传达到每一位团队成员,有没有得到团队成员的认同、领会,并最终作为日常工作遵循的原则?有没有打破部门间壁垒,增强沟通,促进理解?这些相当关键。
如果没有这些,就像作者描述的那样,开发团队打自己的小算盘,每天都有看不到头的开发工作,遇事能推就推,bug能不改就改,反正只要测试发现不了就成。测试团队也打自己的小算盘,埋头查bug,不考虑它背后真正的产品价值,对开发部门能压就压,不然出了问题就赖到我们测试头上了。开发和测试就是一对冤家,矛盾突出,他们各自对自己部门制定惩罚措施,管好自己,各扫门前雪。其实,敏捷也不能完全消除开发和测试间的意见冲突,不过对产品目标和原则有共同认知,在互相尊重理解的前提下,积极的沟通解决,而不是传统意义上的建立防御壁垒。

作者说,”越来越感受到自己的职业价值观不断受到挤压,各种混乱事件让测试人员及团队挺纠结。“
我推测还有个原因是,在一些实施传统流程的大企业里,测试部门还承担了一部分管理评估的工作,比如统计代码行数、评估千行代码bug率等,有些是跟传统管理方式的背景有关的。当敏捷到来时,这些东西的价值被否定、无视了,对于长年在这个环境里成长的人,冲击肯定很大。

作者写道:


第三,dylan认为不要“边重构,边生活”:

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

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



真是两个世界。

这是传统理念的写照,预先精密规划设计,把软件开发当成体力劳动,扑人进去,明确分工,工业化生产,上支下派,铁打的营盘流水的兵。
而敏捷对开发人员的要求比较高,精英式,小团队,智力型,平面化,重交流,多迭代。

作者说,”开发知道了未来要演进的形态,在一开始就有所规划,预留接口。“
从而引出预留接口的必要性,我十分认同前半部分,在产品规划期,就要考虑未来演进的形态,但不认同预留接口这个实施手段。
要考虑现阶段架构是否适应将来的演进,要评估出将来调整的入口点、成本和难度,结合业务发展的价值和可能性,要从架构上有所权衡,但并不表示一定要预留结口。这个十分考验技术负责人的功力。
保持最小可用不仅是产品形态上,多数时候在代码的可维护性和可扩展性上,也比预留了一堆目前用不上,或者业务明晰后发现预留接口有偏差的代码更好。


如果你的产品即便能尽早发布、迭代发布,但没有客户给你频繁细致的使用和反馈,或句话说,如果你们做的是签约客户,你们和客户都准备产品验收时再看东西。那么采用敏捷的好处就打了一个大折扣。

是不是真的能走到敏捷这条路上,需要看看产品的形态,市场的形态,客户的形态,公司高层的意识形态,公司文化制度和组织结构格局,团队成员的组成状况等等。
对于一直面对传统客户,做着传统行业,用着传统思维,管着一群传统员工的公司而言,有没有必要转型,怎么转型,不是开发部门打个敏捷的旗号就能摆平了的,这种九死一生的事,不从公司高层出发,打出个更响亮的旗号,比如互联网思维啥的,基本没戏

”人不行,啥都不行“,是这理。意识形态是最难改变的,所以,即便想伤筋动骨玩一票,还是九死一生。也许,像多数人面对大环境一样,改变不了就适应它,认命是明智的选择。
对于有想法的人,尽自己努力去改变环境,哪怕得到的效果微不足道,也是值得尊敬的。多一些这样的人,才能让我们看到希望,看到更好的未来。
不过,前提是你明确知道自己是正确的,明确知道前方有多坎坷,明确知道自己的路子对。

不作死就不会死。

可是,不作死就等死。

木办法。

Re: 一声叹息 by 郭 雪品

原作者发现了很多的问题,但是最终却是归咎于敏捷。原作者的很多观点,看上去也是很多人对敏捷的典型的误解。

两位刘松的回复,甚至可以合到这篇新闻的原文里,使它更完整。

Re: 一声叹息 by 熊 节

我觉得嘛,你还去讲“误解”这个点,是没有什么意思的。这个东西经常被误解,基本上InfoQ中文站讲敏捷的文章,讲一篇误解一篇。自己有问题总不肯承认,总要归咎到某个东西上,这是人之常情,有什么特别值得去讲的呢?有意思的是在于,他怎么不归咎到别的什么东西上,偏偏要归咎到敏捷上。他怎么不反思CMM也不反思精益创业呢?你沿着这个思路,回头去看各种各样的反思敏捷啦裁剪敏捷啦什么什么的,大概能做出一个敏捷中国史来。

含泪同情:误入歧途的孩子 by 闫 大卫

先翻开书好好看看12条敏捷原则,然后再进行反思吧。我们(不是你们或者他们)的最高目标是通过尽早和持续地交付有价值的软件来满足客户。莫非这是炒作?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

21 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT