其实敏捷开发也是最近几年比较火的一个概念，和开源一样，火归火，在中国就是水土不服。要说原因，恐怕60%以上都会说，程序员素质达不到XP的标准，其实每每看到这里我都很奇怪。我也试图去跟别人沟通过敏捷的思想，但一说敏捷开发，一般对方都会说，着是个好东西，但是程序员素质参差不齐，怎么搞什么结对编程啊。
敏捷，是敏捷，极限编程，是极限编程。敏捷不一定要极限编程，极限编程也不一定就是敏捷的（也可能是迟钝的）。
在这篇文章里面，首先我打算分清楚这两个概念，然后谈谈我的非极限编程敏捷实践。
正如刚才所说的，敏捷是一套软件开发的理念和方法，并非特指某种编码方式（XP），也不要求必须采取什么开发方式。其实在我看来，包括迭代在内，也不是铁板一块，非如此不敏捷的。
敏捷开发的原则，理念，相信大多数人都能背出个N条出来，极限编程自然是敏捷思想的一个很好的贯彻，但如果条件不许可，比如说一堆应届毕业生，或者没有你看得顺眼的结伴对象，又何必去强求呢？
但，谁说不能搞极限编程就无法实践敏捷了？
我记得我刚接触极限编程的时候，觉得真是个好东西啊，要这么开发效率该多高啊，工资该涨个N倍吧，想着想着就一大堆哈喇子。想着以后要掌了权就要大刀阔斧，来人，给咱俩上XP。
但越干到后面越觉得不是那么回事，你看得上眼的人，看不上你，你看不上的人，怎么结对？找个人来结对编程，比找个GF更难，何况现在GF都还没着落。
在这么多年的开发中，老实说也有过可以实践XP的机会。那是一个潜质很好的小弟，虽然我们还是有很多分歧，在OOD上还有很大的距离，但从OOP上的差距已经不远了。可惜的是，公司可没有打算让你去XP，每天你除了编程，还要负责去跟别的部门吵架，抢资源，最后，还有几个后进的同学要你带呢。XP的事情最后还是不了了之。
这么多年下来，我越来越觉得，XP更像是一个美丽的女神，可远观而不可亵玩也。虽然一直有着没有XP过的遗憾，但这些年我却一直保持着敏捷的实践。我教我的小弟们，先用代码和注释来确定自己的工作，比如说：
- public 给什么 干什么( 要什么 )
- {
- //TODO 第一步你打算怎么干
- //TODO 第二步你打算怎么干
- //...
- }
交给我审核后再去完形填空。
最后交叉代码审核，所有看不明白的代码全部发还重写，如果说看明白了，又说不清所以然的重打四十。
由于一直实践着敏捷开发，所以实际上这么些年都没写什么文档，交叉的代码审核很好的保证了代码文档化的贯彻。而预先的代码模板则确保了先设计后编码，保证了思路的条理清晰。
这比那些格式文档少了很多废话又最大限度内降低了工作量。
但敏捷开发并不是说完全的抛弃文档，我也设计过很多废话很多的文档，尤其是对于脑子经常短路的小弟，有时候文档、规范和流程能够自动的提醒他：你想哪里去了。
但我永远没有在问题出现前就设计文档，每次我的小弟工作出现了问题，我就给发明个文档来保证他不再犯同样的错误：
有一次漏掉了关键的需求，设计了需求确认表。
有一次忘了定时检查服务器，设计了服务器检查表，定期检查，签字负责。
有一次忘了把项目结束报告发给上头，结果害得我们奖金没按时给，发明了项目跟踪表，告诉他公司的官僚部门需要你做些什么，一个个确认。
…………
……
诸如此类，不一列举。
在问题出现前就加以杜防范，避免出现问题当然是好的，但可能出现的问题成千上万，你能都想到？又能都防住么？亡羊补牢，犹未晚矣。
文档和规范是手段，是避免出现问题的方法，如果确认问题不会再出现，就可以撤掉这些影响程序员心情的东西。
所以我发明的那些文档一般半年到一年就会逐渐废止，因为那些东西通过长时间的重复，已经成为他的习惯，这时候文档就变成了一种强制性的负担。。。
【编辑推荐】
