演讲实录丨真正提升软件团队能力的方法，唯有XP极限编程规模化

本文内容选自我在「中国DevOps社区2019年会」上分享的《敏捷中国十八年目睹之怪现状》实录。

前文提要：CMM被政府补贴成了骗钱工具，完全没有建设行业能力。

18年来，行业里有很多的方法来来去去，真正可以抓软件开发的基本功、真正可以提升软件团队的能力的方法，我觉得就只有极限编程。CMM提出的这些核心能力，只有极限编程真正提供了。

你看有哪一个方法告诉你做需求管理的时候，你要把需求的格式写成什么样子，你要用什么样的纸卡片来记录一个需求？没有，对吧。一件事应该怎么做，你在书上看到一个说法，和你真正在工作上能做这件事，是相差很大的。

再比如项目管理，极限编程会告诉你迭代怎么去管，根据什么来看项目的进度。当然项目管理这一部分，我认为Scrum也是很好的，非常有效地告诉大家项目管理的方法。

再说配置管理。到底什么是配置管理？其实配置管理落到根本上就是持续集成。有持续集成，你就有有效的配置管理；没有有效的持续集成，就是没有配置管理，就是这么简单的事情。没有持续集成，你可以说在纸面上有很多配置管理的流程，但真到了需要软件的时候你怎么办？你只能依赖一个配置管理员来手工打包。越是你着急需要打包软件的时候，这个人就越出错、越是打不出包来。好不容易打出来的包一测有问题，然后大家一起加班。所以我说配置管理很简单，你有持续集成、每天可以有一个候选版本通过持续集成打出来，你就有配置管理；出不来，你就没有配置管理。

那为了让持续集成有效，最后的最后一切都会落到重构和单元测试上面。是不是拥有高覆盖率的、可靠的、运行快速的单元测试，这是一个决定性的分水岭。而高覆盖率的、可靠的、运行快速的单元测试集，得到这个东西最有效的办法，就是测试驱动开发，就是你必须先写测试、再写实现，你才可能得到这么一个有效的测试集。有很多人跟我讲，我们先赶紧写完了实现，回头再去补单元测试。“写完实现再去补单元测试”，这个鬼故事，我每年都听十几次，你们谁见它真正发生的？我们经常听到这个对话：

领导：单元测试很重要，我们要写单元测试。

开发：好好好，等我改完这个版本我就补单元测试。

改完了这个版本就有空了吗？有空了还有下一个版本呢。你在写代码的时候根本没有考虑怎么单元测试，为什么你认为写完实现代码以后就可以补上测试了？你补不上。你会对着一大堆草率堆上去的代码长叹一口气，因为你一开始写代码的时候就没考虑代码的可测试性。

这件事情我觉得非常有趣：软件工程的教科书里面都写着，单元测试是软件开发的重要环节。所有人都认同单元测试的价值，但是谁也不做。然后到了实践里面，大家说我写完这个版本我就补单元测试，然后这个版本完了之后没有补，然后下一个版本来了之后又说，我写完这个版本就补单元测试，下一个版本做完也没有补。这种现象使我对于人类作为一个整体的学习能力非常担忧，因为大家没有从历史中学习的能力：补单元测试这个事情是从来没有发生过的，所以未来它也不会发生，这才是合理的。你根本就不应该相信“我做完这个版本补单元测试”这种话。

所以一切的一切最后都会归结到有没有有效的单元测试集。得到有效的单元测试集最直接的办法，叫做测试驱动开发。我翻译《重构》第二版的时候跟另一个译者林从羽开玩笑说，你告诉任何一个敏捷实施当中遇到的问题，我都可以告诉你这个问题是因为没有做好TDD。

（未完待续）