我经历的--敏捷开发

    关心敏捷很久，今天看了某牛人的帖子 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率，用户体验效果）上，因为为了敏捷，大打折扣。质量是产品生存之道，软件也不能例外。
    二、文档缺陷，为了赶工期往往文档就省掉。大大增加了后期的代码的维护难道，如果一旦模块原有开发人员离职，将会是一场灾难。
    三、滥用人力，员工经常处于这种高压力下面，会很疲惫。随着工作时间、和年龄的增长，会厌倦工作，最后离职，造成人才流失。公司的技术无法得到沉淀，不利于公司长远长远发展。
    四、还没想到 :-)

评论

11 楼 kaverjody 2009-01-20  

funny, how can you call this Agile??

第一，产品质量：
请参考scrum里面描述的Done Definition。

第二，文档缺陷：
working software over comprehensive documentation。敏捷宣言第一条，你认为你自己是敏捷？

第三，加班：
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
敏捷原则中的一条，你认为你自己是敏捷？

10 楼 iamredeye 2009-01-09  

可以说是迭代，但是不是敏捷还值得商榷

9 楼 jasph77 2009-01-07  

luck_donkey 写道

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

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

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

8 楼 jasph77 2009-01-07  

sg552 写道

jasph77 写道

魔力猫咪 写道

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

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

哥

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

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

7 楼 luck_donkey 2008-12-12  

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

6 楼 sg552 2008-12-12  

jasph77 写道

魔力猫咪 写道

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

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

哥

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

5 楼 fxwdl 2008-12-12  

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

4 楼 glacier3 2008-12-05  

这个也叫敏捷？！

3 楼 pekkle 2008-10-29  

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

2 楼 jasph77 2008-10-29  

魔力猫咪 写道

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

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

1 楼 魔力猫咪 2008-10-29  

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