我经历的--敏捷开发

    关心敏捷很久，今天看了某牛人的帖子 http://www.iteye.com/topic/254179?page=1
    突然发现，原来我也一直在敏捷嘛。

    记得去年（2007）跳槽到Ah公司，就接手一个棘手的项目。因为项目前期投入不够，工期一拖再拖，已经引起客户的不满。
    公司决定派我跟项目的主要开发者小zhu一起到客户那里做现成开发。一到现场，跟客户沟通以后就进入紧张的开发过程，拿着需求文档，一条条的开发，完成一个需求，就交付客户使用，收集意见，然后再改，再交付客户，收集意见......如此迭代，到达客户最终满意。
    经历了3个星期每天早8点，半夜12点后，客户终于开始满意。在我接手项目的一个多月以后，项目验收会召开，接下去好几期的客户培训。2个多月以后慢慢结束项目开发。开始接手公司另外一个项目的开发任务。


    第二个所谓的;敏捷;是在去年9月份左右(应该算1.5个项目)，6月份因为公司要转后台系统架构，准备上J2EE。公司需要做java的人才，我也有意转java开发。
    经过2个月学习，8月份开发ZH项目的前期开发准备工作，技术部经理的指导下，在一个来自亚信强大外援支持一下，把系统一点点搭建起来，好像在8月底ZH项目顺利签约，9月初，我和例外一个做VC++的同事小song，我和前期做工程的先去，小song后来到，开赴现场。
    服务器上架，开发搭建，VC部分的加入，投入紧张的开发工作，进过努力，终于在十一前，完成基本数据流的运转、入库，业务数据的同步。十一以后，因为上海项目的启动，开赴上海，又是服务器的上架、装系统、开发系统搭建，小song的加入。
    功能的完成，交付客户。
    客户需求的提出，协商，确认；编码，测试，交付客户；收集意见，然后再改，再交付客户，收集意见..........客户OK。
    客户提出新的需求，协商，确认；编码，测试，交付客户；收集意见，然后再改，再交付客户，收集意见.........客户OK。
    如此不停的迭代，又是早8点、半夜12点，在过年前几个礼拜终于基本完成客户需求。
    中间在上海过了一个圣诞节，平安夜去自我放假了一个晚上，逛了商业外滩。外滩很美、就是气氛不对。2个大男人平安夜逛大上海，又是2个穷人。

    今年(2008)6月份中旬，过了年以后一直都在准备的上海HSJ的项目终于签约，项目的庞大和重要性，公司几乎所有的开发能力都开赴上海做现场开发。有了java项目经验的积累，我重新设计了系统架构，引入了spring/hibernate，系统进行模块化开发，我有了2个同事跟我一起做，根据2个人不同特点：一个做核心数据的流转层开发，一个做业务逻辑层开发。因为6月底因为个人原因要离开Ah公司，反倒落了个清闲，但是并不是说对自己的工作不负责任，只是不想做太多东西，等我离开了，影响了项目，更多的起了一个监督者、帮忙者的作用。中间还跟技术部经理da peng，因为是否引入消息bean中间件，意见相左，最后我模仿消息bean的机制自己写了个消息bean。其实我很想完成整个项目的开发，毕竟项目前期我投入了几乎全部的精力在上面，还自己写了一个类spring的东西，虽然后来没用上。听说上个月(9月份)的时候，项目已经顺利验收，但稳定性不是很行，我估计是没有引入消息中间件有很大原因。

   
    每次敏捷以后，技术提高很快，身心极度疲惫，原因有三：工期紧压力大，跟客户打交道累，生活条件艰苦。 ;
    敏捷的效果是老板最喜欢看见的，开发效率极高，在非常短的时间内交付，大大节约了生产成本。
    但对于员工来说，压力非常大，感觉有点变态（其实本人还是比较喜欢这种开发模式），
    但是从长远来说还是弊大于利,问题有四：
    一、软件产品质量（代码优美度，BUG率，用户体验效果）上，因为为了敏捷，大打折扣。质量是产品生存之道，软件也不能例外。
    二、文档缺陷，为了赶工期往往文档就省掉。大大增加了后期的代码的维护难道，如果一旦模块原有开发人员离职，将会是一场灾难。
    三、滥用人力，员工经常处于这种高压力下面，会很疲惫。随着工作时间、和年龄的增长，会厌倦工作，最后离职，造成人才流失。公司的技术无法得到沉淀，不利于公司长远长远发展。
    四、还没想到 :-)

对你的问题的回答：
1敏捷并不是不要质量。敏捷要求测试先行，使用TDD的方式开发。采用持续集成等方法做到尽可能的自动化测试。说真的，现在国内很多公司还处于找几个人手工应用测试的地步，繁琐且效率低下。时间一紧就更不能保证质量了。特别是测试人员长时间反复枯燥地操作，更是让效率降低。所以这不是敏捷的错误。
2敏捷并不是不要文档。即使是最极端的XP，也不是说所有的文档都不要。要消灭的只是那些纯粹为了验收好看凑数的文档。很多公司都是项目完了才补。这些文档能有多大用处鬼才知道。敏捷希望用测试代替文档，测试用例就是最好的文档。
3敏捷拒绝加班的，加班不是敏捷的错。这纯粹是国内违法加班的结果。不得不说，在国内，无论什么情况下，加班都很难避免。谁叫中国人多加上法律不严呢。

1、小公司没有专门的测试人员，只能交叉测试，尽力避免BUG的出现。对于用户的体验，在那种情况下面，有点力不从心。
2、没有引入Junit,半路出家做java，个人力推单元测试，公司不重视没办法。一般都是写个main函数简单测试一下。测试用例。。。。。最多只是功能测试用例。
3、加班--一个不能不说的问题。出差在外为了能早点回家，拼命的想把事情干完，老板也不允许你浪费几百块的住宿费。加班出自自愿，也是被迫。
或许，我经历的敏捷，更加接近 XP. 

多么类似的开发模式啊。
最好的方式就是找一个好的PM，带领团队。

这个也叫敏捷？！

这叫敏捷?简直一个小作坊式的开发

哥

你的经历中，没有单元测试，何来TDD和持续集成？没有单元测试，如何有胆量修改代码？？

楼主使用迭代的开发方式，这对需求不明确或者变化的项目来说是最合适的，至于产品质量跟这种开发方式没有直接关系吧？一般压力大，时间紧的情况不是公司逼的就是自己逼出来的。

单元测试?写个main函数就过了，小公司哪里来的单元测试，完整的单元测试-是我一直的梦想。
客户满意是我唯一追求的目标

产品质量可以有很多理解，BUG、后续的维护成本、代码美观，代码注释的完整性、文档的健全等等。。

出差在外，总想快点完成项目，早点回来。压力是自己给自己的，公司就是看上这点。