您当前的位置: 首先声明一下，我对敏捷开发了解的并不深刻，但我仍然持有很多怀疑。这个行业从不缺乏创意和神话，以前面向对象、UML等概念刚面世时，也都吹嘘得包治百病。Java提出Write once, run anywhere的口号又曾经打动过多少程序员的心！可如今呢？SUN被卖了，Java基本退出PC桌面应用，只在企业和Web应用领域有优势。远的不说，Web 2.0前两年也吹得很响吧，其实作用有限，现在成熟的应用又有多少呢？
不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？
先说需求分析，靠Backlog或者User story能够代替严谨的需求规格说明书行吗？
1. 如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；
2. 至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。
3. 需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？
再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？
详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。
测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。
骂了半天敏捷，再说说单元测试。
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
——————————————————
对诸位网友意见的回复：
首先呢，各位的意见我都认真看了（包括“一蓑烟雨任平生”删掉的那篇），没有听不进去的问题，只不过我比较懒，没有一一回复。
第二，我并没有全盘否定敏捷开发的意思，只不过对周围很多神话般吹嘘敏捷的人比较反感，在这里发泄发泄。
第三，我谈论以上话题的时候，是本着“什么样的技术和方式能够更好地满足用户的需求”这个视角考虑问题的，不是就技术谈技术，也不是从项目管理的方法论角度谈论问题，也没有考虑个人职业规划，或者考虑老板、同事、上下级之类的协作关系等问题。所以角度不同，看法自然不同。
第四，各位不要乱猜，本人三十有七，属于老枪/老鸟，不是新兵蛋子。大公司、小公司都干过，外企没进过。出国也呆过，后来又海龟过。创业失败又打工过，打工几年又创业过。程序员干过，项目经理干过，高工干过，现在是社会闲杂。自己注册了家美国公司，不过产品还没开始赚钱（20万行代码已经累得我一身病），所以现在不算什么老板，偶尔做点项目挣个十万八万补贴家用。总之，向我这把年纪还自己写代码的人，算是频临灭绝的稀有动物了，你们一定要爱惜，呵呵！
3 楼
抛出异常的爱
2010-04-30
楼主没作过项目么？
那种怎么看都不像能完成的项目？
你要用什么来得到你所需要的资源？计划？还是对着老板哭穷？
没有变化一切好说。
有了变化什么样的变态事都可能会作。像淹死之前抓个草一样
好吧我不想像上面那样再来一次。
一是加强管理
二是提高工作效率。
三把风险下降到可以忍耐的范围内`12345
那种怎么看都不像能完成的项目？
你要用什么来得到你所需要的资源？计划？还是对着老板哭穷？
没有变化一切好说。
有了变化什么样的变态事都可能会作。像淹死之前抓个草一样
好吧我不想像上面那样再来一次。
一是加强管理
二是提高工作效率。
三把风险下降到可以忍耐的范围内`12345
4 楼
抛出异常的爱
2010-05-01
ittio 写道
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
平均每百行6个bug的软件开发行业来说还是有一定必要的
（如果你认为代码BUG率比1%还低那就没什么必要了）
如果覆盖不能说明测试程度，还有什么能够用数字来描述测试程序么？
像世博会一样用10万人一起用来测试么
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
估计你自己很少用吧，这都是虚的。这东西推广起来比结对开发还难。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
给你经常拷贝的代码起个起个编号，另设计模式不止23种，业务中相似的模式大约有200多种，被再次抽象了之后才变成23种，如果背会了23种设计模式之后建议去看看实践中适用场景。再来谈使用模式来设计代码
PS：当将军不知道每天你的部队能吃多少粮能走多少路，一小时能打完多少子弹，在炮火中前进多少米还能战斗，光学点孙子兵法是没用的。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
作过的项目中没见过面向领域，连面向oo的都非常少OO在小范围内实现还能见个二三，大了跟本没见过
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
对于j2ee不到一万用户量来说，需要怎么样高效率才能满足呢？
PS：现在集群成本如此之低世所罕见，人的劳动时间不值钱么？没台服务器贵？
你举的一与二都是集群解决不了的问题。就像一万节电池也无法产生特斯拉闪电一样。
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
现在正在技术准备的公司有好几家。不光互联网，还有企业开发。J·EE很快就要加入这个行列了
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
至现在我也是这么认为的，除了flash以外没那个语言可以方便开发界面呢
5 楼
fight_bird
2010-05-01
0和1是对和错吗？不过是鬼佬总结出的几套方法论，不是什么不可逾越的教义和天条，实践出真知，真如楼主所说，成吉思汗家的屠夫们没看过孙子兵法，但却可以杀人越货、横扫欧亚一个世纪。
我所主管的项目中，不会让PM去吹什么RUP，但有分工明确、严格的任务跟踪卡；也没有什么形而上学的双人编程，但有CTO牵头、拥有一票否决权的设计质量小组，几百万人民币的项目不少了，过千万的也有，磕磕碰碰是不少，但从未因为开发管理的原因导致大问题。
套用功夫熊猫里的一句话：No secret, secret is nothing,...Use your noodle.
我所主管的项目中，不会让PM去吹什么RUP，但有分工明确、严格的任务跟踪卡；也没有什么形而上学的双人编程，但有CTO牵头、拥有一票否决权的设计质量小组，几百万人民币的项目不少了，过千万的也有，磕磕碰碰是不少，但从未因为开发管理的原因导致大问题。
套用功夫熊猫里的一句话：No secret, secret is nothing,...Use your noodle.
6 楼
gigix
2010-05-01
其实呢，有些道理说起来很简单…
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
7 楼
抛出异常的爱
2010-05-01
gigix 写道
其实呢，有些道理说起来很简单…
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
这本身就是个问题？
在很多企业中问这个就是较劲
8 楼
一蓑烟雨任平生
2010-05-01
昨天我把写的回复删掉了，因为我觉得LZ估计是听不进去什么，唯一的办法是单位里面有个明白人能敲打他一下。
9 楼
flashing
2010-05-01
lz文风很fq啊，俺很稀饭，哈哈。
基本比较赞同，不过对燃尽图这方面我觉得不是给领导看的，这能体现出很多东西来，比如你的团队的真实的生产力（用于项目时间评估等地方），比如团队的执行力（素质不高的人到处都有，不能完全依赖于自觉性）。
另外对开会这个事情lz好像很烦，其实都是为了沟通，会议不扯皮就好了。
基本比较赞同，不过对燃尽图这方面我觉得不是给领导看的，这能体现出很多东西来，比如你的团队的真实的生产力（用于项目时间评估等地方），比如团队的执行力（素质不高的人到处都有，不能完全依赖于自觉性）。
另外对开会这个事情lz好像很烦，其实都是为了沟通，会议不扯皮就好了。
ittio 写道
首先声明一下，我对敏捷开发了解的并不深刻，但我仍然持有很多怀疑。这个行业从不缺乏创意和神话，以前面向对象、UML等概念刚面世时，也都吹嘘得包治百病。Java提出Write once, run anywhere的口号又曾经打动过多少程序员的心！可如今呢？SUN被卖了，Java基本退出PC桌面应用，只在企业和Web应用领域有优势。远的不说，Web 2.0前两年也吹得很响吧，其实作用有限，现在成熟的应用又有多少呢？
不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？
先说需求分析，靠Backlog或者User story能够代替严谨的需求规格说明书行吗？
1. 如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；
2. 至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。
3. 需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？
再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？
详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。
测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。
骂了半天敏捷，再说说单元测试。
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？
先说需求分析，靠Backlog或者User story能够代替严谨的需求规格说明书行吗？
1. 如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；
2. 至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。
3. 需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？
再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？
详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。
测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。
骂了半天敏捷，再说说单元测试。
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
10 楼
flashing
2010-05-01
其实说白了就是屁股决定脑袋，不过我觉得年轻人有想法总是好的。
gigix 写道
其实呢，有些道理说起来很简单…
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
如果你不能改变世界，那就努力适应它吧
比如说，要是某件事让你觉得不爽但很多人包括你的老板喜欢它，你最好谦虚点去问问明白，到底这件事的好处在哪儿。
这样做的好处在于，当你被强迫做这件事的时候，你可以不那么难受。
当然你也可以继续较劲，跟整个世界拧把着过活，反正自己难受嘛
毕竟，说到底，你难受不难受，除了你自己，有谁会在乎呢？
11 楼
flashing
2010-05-01
更仔细的看了看，我觉得lz很多地方的想法还是有问题的，有几个例子举得很不恰当，比如google那个吧，首先这个事情真假我不太清楚，但是就算是真的我觉得也是个很合理的事情。如果google开始创业的时候就用的汇编写爬虫，我估计google恐怕也很难成功。换句话说你先成功了，然后才有资本做这么niubility的事情；twitter也是一样，如果没有成功，他们重写ruby的底层也就没有任何意义了。架构师的更重要的层面是要权衡，而不是仅仅是拍脑袋。
12 楼
flashing
2010-05-01
这个是点错了发了这个回复，faint。管理员删掉吧。
13 楼
xianlv
2010-05-01
在概念层次上，有破有立，都可以自成一套说法。
好或者不好，实际感受为上。一个做法，对客户、公司、人员都适合，大家用得舒服，老板也比较满意，这样就行了。不用在乎它是否敏捷的，或者浪费的。
好或者不好，实际感受为上。一个做法，对客户、公司、人员都适合，大家用得舒服，老板也比较满意，这样就行了。不用在乎它是否敏捷的，或者浪费的。
ittio 写道
首先声明一下，我对敏捷开发了解的并不深刻，但我仍然持有很多怀疑。这个行业从不缺乏创意和神话，以前面向对象、UML等概念刚面世时，也都吹嘘得包治百病。Java提出Write once, run anywhere的口号又曾经打动过多少程序员的心！可如今呢？SUN被卖了，Java基本退出PC桌面应用，只在企业和Web应用领域有优势。远的不说，Web 2.0前两年也吹得很响吧，其实作用有限，现在成熟的应用又有多少呢？
不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？
先说需求分析，靠Backlog或者User story能够代替严谨的需求规格说明书行吗？
1. 如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；
2. 至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。
3. 需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？
再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？
详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。
测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。
骂了半天敏捷，再说说单元测试。
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？
先说需求分析，靠Backlog或者User story能够代替严谨的需求规格说明书行吗？
1. 如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；
2. 至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。
3. 需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？
再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？
详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。
测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。
骂了半天敏捷，再说说单元测试。
单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。
就想到这么多，忘了提的以后再补充。
睡了一觉，接着写。
重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。
设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。
面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。
O/R mapping、Ruby on Rails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：
1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。
罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。
反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。
14 楼
gigix
2010-05-01
flashing 写道
其实说白了就是屁股决定脑袋，不过我觉得年轻人有想法总是好的。
一个程序员连命令行有多么重要都还没意识到的时候，有什么想法其实根本就是在浪费时间
我认为年轻人有没有想法不重要，把底子打扎实了再有想法不迟
没下过苦功没挨过板子，成天光看贼吃肉不看贼挨打，这小脑瓜子冒出来的想法，全都是垃圾
15 楼
黑暗浪子
2010-05-02
也许microsoft这么多年推行的图形化操作系统给太多刚入这个行业的小朋友有太多的误导。呵呵
16 楼
sg552
2010-05-02
看到LZ的文章：
每天使用ROR 先写单元测试再写实现的人 笑而不语。。。。。。
Dave, Andy 和 <<Pragmatic>>系列作者 内牛满面。。。
每天使用ROR 先写单元测试再写实现的人 笑而不语。。。。。。
Dave, Andy 和 <<Pragmatic>>系列作者 内牛满面。。。
17 楼
逍遥一狂
2010-05-02
尽信书则不如无书，根据自己公司和项目的实际情况，对软件工程进行适当地剪裁才是真理。
18 楼
carlkkx
2010-05-02
gigix 写道
flashing 写道
其实说白了就是屁股决定脑袋，不过我觉得年轻人有想法总是好的。
一个程序员连命令行有多么重要都还没意识到的时候，有什么想法其实根本就是在浪费时间
我认为年轻人有没有想法不重要，把底子打扎实了再有想法不迟
没下过苦功没挨过板子，成天光看贼吃肉不看贼挨打，这小脑瓜子冒出来的想法，全都是垃圾
一个程序员如果认为人机交互就是命令行的话，那么这个程序员也一定是个自负狭隘的程序员，他不懂得主观价值论，他不懂的认真探索别人的需求。
19 楼
pipilu
2010-05-03
很多反对敏捷的人有个特点：认为提倡采纳敏捷开发方法的人在赶时髦。
把别人思维想的很简单的人，恐怕自己的脑子就很简单，没法再深入想一层，比如楼主。明显没多少项目经验，想法还挺多。
关于单元测试只需覆盖重要功能、复杂逻辑的这个说法，如果团队里有人提出来，我不会反对。但习惯于先写单元测试后，不会在乎特地要区分什么重要什么不重要。因为是很自然的过程了。
还有对云计算的否定。无论是SOA还是云计算，提出这些概念是有特定的应用背景的。我们没接触到足够规模的应用，当然是没法理解的。你没接触到，那就去想想，多读读资料，想想人家为什么要提出这个，而不是简单的去认为别人就是在炒概念，就如同你对敏捷的看法一样，认为别人头脑弱到了去“尽信书”或是“赶时髦”。
把别人思维想的很简单的人，恐怕自己的脑子就很简单，没法再深入想一层，比如楼主。明显没多少项目经验，想法还挺多。
关于单元测试只需覆盖重要功能、复杂逻辑的这个说法，如果团队里有人提出来，我不会反对。但习惯于先写单元测试后，不会在乎特地要区分什么重要什么不重要。因为是很自然的过程了。
还有对云计算的否定。无论是SOA还是云计算，提出这些概念是有特定的应用背景的。我们没接触到足够规模的应用，当然是没法理解的。你没接触到，那就去想想，多读读资料，想想人家为什么要提出这个，而不是简单的去认为别人就是在炒概念，就如同你对敏捷的看法一样，认为别人头脑弱到了去“尽信书”或是“赶时髦”。
20 楼
asd
2010-05-03
做个小网站什么的当然想怎么玩怎么玩，xp不xp最多是加一天班还是加两天班的问题。
谁能举个开发周期超过一年的例子，然后证明一下xp或者这个那个方法提高了生产效率，让你少加班了的？或者让用户少变更需求的？
靠那些什么条条框框图向老板骗开发周期，还不如和客户，商务，产品搞好关系来得有效。
不知道哪里来的统计数据，个人觉得这是一个比较惊人的数据，我看恐怕这个不是原因是结果吧。
就像我遇到过的一个白痴，总是花一两周快速完成一个功能向老板表功，然后花几个月的时间给自己擦屁股。开始老板是高兴了，最后.....客户怒了，几个月时间其实就完成了一个小功能。
谁能举个开发周期超过一年的例子，然后证明一下xp或者这个那个方法提高了生产效率，让你少加班了的？或者让用户少变更需求的？
靠那些什么条条框框图向老板骗开发周期，还不如和客户，商务，产品搞好关系来得有效。
引用
100代码6个bug
不知道哪里来的统计数据，个人觉得这是一个比较惊人的数据，我看恐怕这个不是原因是结果吧。
就像我遇到过的一个白痴，总是花一两周快速完成一个功能向老板表功，然后花几个月的时间给自己擦屁股。开始老板是高兴了，最后.....客户怒了，几个月时间其实就完成了一个小功能。
21 楼
gigix
2010-05-03
asd 写道
谁能举个开发周期超过一年的例子，然后证明一下xp或者这个那个方法提高了生产效率，让你少加班了的？或者让用户少变更需求的？
靠那些什么条条框框图向老板骗开发周期，还不如和客户，商务，产品搞好关系来得有效。
靠那些什么条条框框图向老板骗开发周期，还不如和客户，商务，产品搞好关系来得有效。
其实这个东西，你也没必要叫谁给你证明，别人也没必要给你证明。你要是能做主，你爱用什么方法就用什么方法好了，谁也管不着你。你要是做不了主呢，到了一定的时候你就会被强迫着用这些你看不上的方法，到时候接受不接受其实就只是个你自己难受不难受的问题了。你喜欢让自己过得拧巴，还是谁也管不着你。
22 楼
Solstice
2010-05-03
ittio 写道
2.Google 2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！
你从哪儿听到的这个？居然就相信了？