敏捷开发转型 7 个月,4 小时的活儿 24 分钟搞定

阅读数:6 2020 年 4 月 23 日 17:39

敏捷开发转型7个月,4小时的活儿24分钟搞定

这几年我在 IBM 做敏捷教练和咨询顾问时,我经常会思考 3 个问题:

  • 程序员的核心能力是什么?
  • 什么决定团队整体效率和交付质量?
  • 为什么华为、腾讯这样的大厂,这两年都在做敏捷转型?

当时我发现大多数公司团队成员,这里面不乏一些大厂的程序员,平时会刷题、懂算法、做架构、写代码,但对于理解需求、拆分任务、编写测试、高质量的代码实现——这些基本功,反倒不重视。

为什么有人产出低、有人产出高?为什么有 10x 程序员?我觉得效率低的核心原因就四句话:观念落后、固守陈规、埋头蛮干、不找方法,这是典型的螺丝钉思维。

有竞争力的开发者是什么样子的?

我最早接触敏捷,是源于一位做开发的朋友。他就属于那种效率极高的,大家一个礼拜的任务他 2-3 天就能做完,代码质量高 bug 少。最主要的是,他除了写代码以外,有足够多的时间研究新技术,指导其他同事,在团队中口碑极好,后来还研究上了管理,听说这家伙后来做了首席架构师,还兼任团队 Leader。

他有个习惯,每次写代码之前都会仔细想一想需求,想好后先写测试用例代码,再动手写代码。一旦写代码就特别快,一气呵成。

那时我偷偷问他,“你写代码之前还要写测试,多麻烦啊,怎么还能写那么快那么好?”他眨巴着眼睛,一脸坏笑:“代码写得快靠得是思考快,而不是敲字敲得快,构思好了再写不就是记录自己想说的话吗?再者,我先写测试后写代码,磨刀不误砍柴功,好多问题在前面都解决了。”

我再看他写的代码,简洁优雅,顿时羡慕得不得了。他告诉我,“这就是测试驱动开发,敏捷的核心技术实践之一。”他改变了我对程序员的认知,也改变了我对这项工作的认知,原来厉害的程序员不只是撸代码啊。

我一直热衷于探索研发管理的效率、效益和精髓。带着疑惑,加之当时公司也确有敏捷方面的需求,我从此开始研究和实践敏捷开发。刚接触的时候我觉得理念很好,但有些理想化,那时我并没有从内心接纳敏捷。

随着过程推进,我逐步感受到了敏捷带来的好处,尤其在团队管理方面,敏捷为我省去了大量的时间。

我自己在深入进行敏捷实践的同时,接触了很多国内的研发团队,这些团队的规模不等。他们的共同特点是很努力,但也存在很多问题。比如:

  • 初创团队,没有任何成熟的管理实践,想到哪里做到哪里,研发管理相当混乱;
  • 有的团队已经经历了前期的混乱,想着要正规一些,就倾全公司之力引入 CMMI,导入瀑布流程,导致整个公司流程过重,交付速度受限制,三个月甚至半年才上一个版本,业务部门相当不满意,项目团队成员也怨声载道;
  • 有的团队听说现在流行的方式是敏捷,于是拿书来看,自己琢磨,炮制了一套敏捷流程,结果根本不适合自己团队的业务模式。

同时,程序员们普遍有一些困惑:他们很关心现在的研发管理趋势,当公司引入敏捷后,自己却不明白工作跟以前相比有何不同,也不清楚自己在整个开发过程中的角色和定位,个人的价值没有得到充分展现。

如果你想成为技术 Leader,敏捷作为一种变革,带来挑战的同时也会带来新机会,不仅要懂,还要比别人领先一步。

一些一线和中层管理者也会担忧:工业革命的时候,机器在很多岗位上取代了人,现在敏捷来了,强调团队要自组织,我的岗位会不会也被取代了呢?敏捷来了之后,是不是管理方式上也会有新的变化,到底应该怎么改变自身的管理风格才能更好地适应它?

作为敏捷咨询师,我给上百家公司做过分享和敏捷教练,目睹了各种各样公司在推进敏捷开发过程的疑难杂症,我一直想把自己的经验总结出来,帮助敏捷团队和个人真正解决实践中的痛点,于是我和极客时间团队决定打磨一个把敏捷讲透的课程。

现在市面上有很多关于敏捷的书,会讲一些基础知识和理论,但是敏捷毕竟有很强的实践性,只了解理论是不够的。以我个人的经历来讲,想要真正理解并接纳敏捷,你需要真实的案例来辅助你对它的理解。

本文转载自技术琐话公众号。

原文链接: https://mp.weixin.qq.com/s/_H0fr6n8LT6LBelM9ThdDw

评论

发布