敏捷开发，极限编程 VS Scrum 的区别

1. 《敏捷遇上uml》培训，主要从需求分析，以及软件设计2大方面讲解。个人体会，需求是根本，设计以需求为出发点，同时设计上要注意可持续，提高代码的可重用性，少做无用功。
2. 这次培训，感觉主要是改变习惯和思路，即工作任务是整个团队的，不仅仅是某个人的，因此每个环节其实都需要大家的参与与付出，只是侧重点有所不同，但是不代表就不需要你参与。比如：需求分析，可能每个人都会想到一些潜在的需求，集思广益才能在前期把需求搞清楚，这样设计才会有的放矢。
3. 再比如：后期分配任务，每个人做的事情是不一样的，因此每个人遇到的问题也是不一样的。当一个人有问题时，其实是整个团队的问题，并不仅仅是某个人的问题，这时是需要团队协作，一起解决问题的。
4. 个人觉得敏捷其实就是依靠团队的力量，有效沟通，积极解决工作中的一切问题。
敏捷其实就是为了高效快速的响应市场变化。

详解 极限编程 VS Scrum 的区别 - 知乎

https://www.baidu.com/link?url=pRTSw3Fk9VR-1dnbj3H2d3Mtjxekdl9VhsAkaiilGsRn5gNC6zsffJfkEmH_vOQ82ckkupKoYgbZTTQd0OHSv4hCsil1zvCe61erHkQEqju&wd=&eqid=f50b5c6e0005cb9a0000000662884b4b

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

• 程序员的核心能力是什么？

• 什么决定团队整体效率和交付质量？

• 为什么华为、腾讯这样的大厂，这两年都在做敏捷转型？

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

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

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

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

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

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

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

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

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

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

• 初创团队，没有任何成熟的管理实践，想到哪里做到哪里，研发管理相当混乱；

• 有的团队已经经历了前期的混乱，想着要正规一些，就倾全公司之力引入 CMMI，导入瀑布流程，导致整个公司流程过重，交付速度受限制，三个月甚至半年才上一个版本，业务部门相当不满意，项目团队成员也怨声载道；

• 有的团队听说现在流行的方式是敏捷，于是拿书来看，自己琢磨，炮制了一套敏捷流程，结果根本不适合自己团队的业务模式。

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