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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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