争辩一下:敏捷开发不是XP

其实敏捷开发也是最近几年比较火的一个概念,和开源一样,火归火,在中国就是水土不服。要说原因,恐怕60%以上都会说,程序员素质达不到XP的标准,其实每每看到这里我都很奇怪。我也试图去跟别人沟通过敏捷的思想,但一说敏捷开发,一般对方都会说,着是个好东西,但是程序员素质参差不齐,怎么搞什么结对编程啊。

成都创新互联公司2013年至今,是专业互联网技术服务公司,拥有项目成都网站制作、网站设计网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元武江做网站,已为上家服务,为武江各地企业和个人服务,联系电话:028-86922220

敏捷,是敏捷,极限编程,是极限编程。敏捷不一定要极限编程,极限编程也不一定就是敏捷的(也可能是迟钝的)。

在这篇文章里面,首先我打算分清楚这两个概念,然后谈谈我的非极限编程敏捷实践。

正如刚才所说的,敏捷是一套软件开发的理念和方法,并非特指某种编码方式(XP),也不要求必须采取什么开发方式。其实在我看来,包括迭代在内,也不是铁板一块,非如此不敏捷的。

敏捷开发的原则,理念,相信大多数人都能背出个N条出来,极限编程自然是敏捷思想的一个很好的贯彻,但如果条件不许可,比如说一堆应届毕业生,或者没有你看得顺眼的结伴对象,又何必去强求呢?
但,谁说不能搞极限编程就无法实践敏捷了?

我记得我刚接触极限编程的时候,觉得真是个好东西啊,要这么开发效率该多高啊,工资该涨个N倍吧,想着想着就一大堆哈喇子。想着以后要掌了权就要大刀阔斧,来人,给咱俩上XP。

但越干到后面越觉得不是那么回事,你看得上眼的人,看不上你,你看不上的人,怎么结对?找个人来结对编程,比找个GF更难,何况现在GF都还没着落。

在这么多年的开发中,老实说也有过可以实践XP的机会。那是一个潜质很好的小弟,虽然我们还是有很多分歧,在OOD上还有很大的距离,但从OOP上的差距已经不远了。可惜的是,公司可没有打算让你去XP,每天你除了编程,还要负责去跟别的部门吵架,抢资源,最后,还有几个后进的同学要你带呢。XP的事情最后还是不了了之。

这么多年下来,我越来越觉得,XP更像是一个美丽的女神,可远观而不可亵玩也。虽然一直有着没有XP过的遗憾,但这些年我却一直保持着敏捷的实践。我教我的小弟们,先用代码和注释来确定自己的工作,比如说:

 
 
 
  1. public 给什么 干什么( 要什么 )  
  2. {  
  3.   //TODO 第一步你打算怎么干  
  4.   //TODO 第二步你打算怎么干  
  5.   //...  

交给我审核后再去完形填空。

最后交叉代码审核,所有看不明白的代码全部发还重写,如果说看明白了,又说不清所以然的重打四十。

由于一直实践着敏捷开发,所以实际上这么些年都没写什么文档,交叉的代码审核很好的保证了代码文档化的贯彻。而预先的代码模板则确保了先设计后编码,保证了思路的条理清晰。

这比那些格式文档少了很多废话又最大限度内降低了工作量。

但敏捷开发并不是说完全的抛弃文档,我也设计过很多废话很多的文档,尤其是对于脑子经常短路的小弟,有时候文档、规范和流程能够自动的提醒他:你想哪里去了。

但我永远没有在问题出现前就设计文档,每次我的小弟工作出现了问题,我就给发明个文档来保证他不再犯同样的错误:

有一次漏掉了关键的需求,设计了需求确认表。

有一次忘了定时检查服务器,设计了服务器检查表,定期检查,签字负责。

有一次忘了把项目结束报告发给上头,结果害得我们奖金没按时给,发明了项目跟踪表,告诉他公司的官僚部门需要你做些什么,一个个确认。
…………
……

诸如此类,不一列举。

在问题出现前就加以杜防范,避免出现问题当然是好的,但可能出现的问题成千上万,你能都想到?又能都防住么?亡羊补牢,犹未晚矣。

文档和规范是手段,是避免出现问题的方法,如果确认问题不会再出现,就可以撤掉这些影响程序员心情的东西。

所以我发明的那些文档一般半年到一年就会逐渐废止,因为那些东西通过长时间的重复,已经成为他的习惯,这时候文档就变成了一种强制性的负担。。。

分享题目:争辩一下:敏捷开发不是XP
网页网址:http://www.gawzjz.com/qtweb2/news6/14456.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联