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