想要快速的持续交付 何以如此困难?

【51CTO专稿】互联网时代的应用开发讲究快速迭代,就算没有一天发布个三版,怎么说也得两天发一版才好意思出门跟人打招呼。而移动应用发布的周期,一般也在一个月以内。

在开源领域,现在Chrome、Firefox等项目基本都保持六周一个新版本,管他功能实现完了没,先上了再说。几个著名的Linux发行版本,则保持六个月一版的发布周期,但是测试版的周期也都维持在一个月的长度。另外,大部分成熟的开源项目都有Nightly Build,即一天一个新版本。

这里面的区别当然也很容易看出来,互联网应用不用下载,用户上去就能用,改动越频繁、每次的改动越小,则越容易收集反馈,对产品更有利;而像是操作系统这种大块头,下载一个镜像就要几个小时,安装升级再几个小时,肯定不能让用户频繁的折腾。

不过无论是哪种产品,业内当前对“应用交付”这方面已经有了统一的观点,那就是无论你什么时候去看产品开发的最新进展,它都应该是可用的,最好能处在一个可随时上线的状态。

笔者上个月在百度开发者大会上遇到了百度高级架构师路宁(@路宁同学),跟其他几位开发者一起聊了一些敏捷开发和持续交付方面的话题。感觉在互联网行业,敏捷开发理念的进展、持续交付的状态的确比两年前的企业级开发领域要好很多了,但也有很多不尽如人意的无奈。

“一开始接触敏捷开发的开发者,都很不习惯那种每天工作透明化的状态,压力很大。”

“我的团队都是些新手,只有一年经验的或者完全就是毕业生的,上来让他们做预估,基本都是不准。一个功能预估做两天,结果做了一周,经常都是这样。”

“好不容易这个人成长起来了吧,别的企业待遇稍微好点就把人挖走了。而领导也不会太多考虑你的难处,只想用廉价劳动力,就再招新人进来,如此反复……”

这些无奈的声音来自一位从业六年的开发者。王先生现在在一家电子政务方面的企业做产品研发经理,负责整个研发团队的工作与培养。

“有些小孩进来吧,你也不能说他不努力,但总感觉心不甘情不愿的。”王先生讲到自己的工作时,说到自己曾经有段时间每天工作18个小时,吃饭什么的全抛掉,只有2、3个小时用来睡觉。当然,他也表示不打算再这样拼命了。“我们给毕业生的待遇也不算高,而敏捷开发的那种透明,虽然能够让他们快速成长,但确实造成很大的压力。”

敏捷开发的理想状态,是一个团队在项目进行过程中能够不断成长,对项目越来越熟练;每次项目都是一次练兵,而团队的整体能力则会越来越强,在敏捷开发的流程当中也会带来越来越高的生产效率。然而,理想是丰满的,现实是骨干的。对于国内的大多数技术团队而言,不稳定可以说是一种常态。老板希望找廉价的工作力,还要进来就能用,进来的新人无论在能力还是忠诚度方面都不能尽如人意,在这种环境下想要做到准确的预估工时,想要让他们坚持透明化的运作,是非常困难的事情。

最终,还是团队的人员质量决定了持续交付的效率和质量。

一方面是团队的参与者。“现在我招聘的时候,都会非常看中这个程序员的心态是否开放。他如果是那种特别以自我为中心的,听不进别人的意见,也不愿意沟通的,这种我就会比较担心一些。”路宁介绍说他自己带过一些团队,有的人就很不愿意做Pair Swapping,因为不愿意让别人看到自己的工作进度,这样的话就比较难展开。所以,开放的心态是非常重要的。

另一方面,团队的管理者也很重要。路宁表示有的管理者会滥用敏捷开发流程当中的透明性,反而对团队的发展不利。“比如,透明化之前的工作可能有张有弛的,这对于开发者来说是一种常态;但透明之后管理者可能看到,你原来这么快就把这个功能做完了,那我要给你加量,反而使得开发者无法得到充分的喘息。”

对于敏捷开发团队的规模,路宁也提供了一些建议。一般敏捷团队从6、7、8、9个人到20个人都是可以的,不过也有的团队到10个人之后就搞不到一起去了。一般来说,6~12个人的团队来完成持续交付会比较理想。

posted @ 2012-04-20 23:37 O.C 阅读(...) 评论(...) 编辑 收藏