敏捷和传统的编程方式相比，有什么缺点？

今天有人问道一个问题： 敏捷和传统的编程方式相比，有什么缺点呢？
大伙来回答一下

评论

21 楼 tuti 2015-06-18  

敏捷和传统的编程方式相比，在概念模型上较为复杂而不容易被人理解。

20 楼 pdckxd 2014-03-01  

我就职于一家知名外企，一个cloud项目里敏捷开发被滥用，开发人员完全是在赶进度而不以质量为重点，我作为测试人员发现问题汇报给开发人员，R&D 不削一顾常常以by design, come from opensource code为由推诿，真是为项目担心

19 楼 hyys2008 2008-12-12  

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

我看着就想笑，你通篇谈信誉，说诚信，瞎讲素质，可是就你这点素质也配谈这些，笑掉大牙，我看你性欲应该很强，去做鸭得了。

就你这种素质，一开口就骂人，老子实在是看不过去了。像你这样的人做开发直接是玷污了软件开发的圣洁。

跟何况就你这点点能力，哎，一看你就是没读过书，更是从没写过代码的。

hyhongyong小兄弟不要跟这种烂人计较。

18 楼 welllove53 2008-12-11  

不好意思，我做的不是对日外包。是对美国
1.确实敏捷方式前几（2）个迭代很累，后面就好了，准时上下班，就是开会时要早点
2：俺们做的项目确实是完整的，不过有的是一个大产品中的一个子项目
3：虽然没做过对日，但我一直不屑于做，可能是因为对日项目的名声不好吧

17 楼 抛出异常的爱 2008-12-11  

引用

1.如果你作过大项目你说说:是cmmi3更需要加班,还是敏捷更需要加班?
加班，没有项目不要加班，只是加班多少，完全取决于客户对这个项目（产品）的时间要的是否紧急
2.大项目都是估出一个 人/月 数才定的价格吧.敏捷如果用定时间合同的话.....谁还敏捷啊.生产率提的越高收入越少???
跟你说吧，我做过的项目就以每个迭代的所需要的人天来签合同的，至于提到“生产率提的越高收入越少”的问题，那你没到这个境界，有办法去解决这个问题的，这里不说了。

3.传统分式,每人负责一个模块...素质要求就低了?
我也说过这个有点牵强

4.每天交流比每周一次交流更需要沟通能力了?
我什么时候说过这句话？ 交流有交流的规则，多交流肯定是好的

我早就说过了.
敏捷最大的缺点在于...根本没人相信.....不肯试一试.
敏捷在国内确实没人相信 ，这也是国内项目敏捷暴露的缺点，不过不是敏捷的缺点，是客户和vendor的缺点

我自己平时使用了一些敏捷的实践,
没在有敏捷的团队中工作过
但在很多号称很牛的软件项目中呆过

1.关于加班,比如我到过一个项目组,是作为救火队过去的.
他们天天加班,每天睡眠8小时都不能保证.
一出bug就有想死的冲动
不改客户不干 ,改.又可能会出Bug1,bug2,bug3.....
还只能一个人改别人搭不上手,
多个人一起不睡等着他...以防bug出在自己头上.

2.软件价格人/月数成为大家的通用价格单位
上百个程序员只会用ctrl-c ctrl-v
跑起来后点来点去测bug.....
只是由于日本方是按人头给钱的....

4.我是对这句话不是对你

引用

敏捷要求结对，这是对dev沟通能力的一个考验

在对日外包你要是想了解一个问题.与设计者之间至少有三个人....改个bug至少要三周时间.

16 楼 welllove53 2008-12-11  

抛出异常的爱 写道

welllove53 写道

抛出异常的爱 写道

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

笑喷了.

笑什么？你以敏捷的方式给国内客户做过项目吗？（就是那种政府，电信，某些不良企业），没做过就不要来说。

除了每人负责一个模块有点牵强，其他哪有不对。

1.如果你作过大项目你说说:是cmmi3更需要加班,还是敏捷更需要加班?
2.大项目都是估出一个 人/月 数才定的价格吧.敏捷如果用定时间合同的话.....谁还敏捷啊.生产率提的越高收入越少???
3.传统分式,每人负责一个模块...素质要求就低了?
4.每天交流比每周一次交流更需要沟通能力了?

我早就说过了.
敏捷最大的缺点在于...根本没人相信.....不肯试一试.

敏捷是指在开发过程中迅速的改变尝试好的经验,如果效果不到预期就放弃回到老路上.
而不是在一开始计划好了向一个方向实施.
XP是这一理念下生出来的实践的集合:不是非要用.用了也不一定就是敏捷.

态度不对怎么也敏捷不起来的.

我以敏捷的方式给国内国外客户都做过项目，区别就在这。
国外客户引导你以敏捷方式开发，不管从商务上，还是开发上。
国内客户只管到时间要货，平常关注的很少，需要很多的我们的引导，但是碰到强势客户就苦了，因为TA基本不听你的。

抛出异常的爱 写道

1.如果你作过大项目你说说:是cmmi3更需要加班,还是敏捷更需要加班?

加班，没有项目不要加班，只是加班多少，完全取决于客户对这个项目（产品）的时间要的是否紧急

抛出异常的爱 写道

2.大项目都是估出一个 人/月 数才定的价格吧.敏捷如果用定时间合同的话.....谁还敏捷啊.生产率提的越高收入越少???

跟你说吧，我做过的项目就以每个迭代的所需要的人天来签合同的，至于提到“生产率提的越高收入越少”的问题，那你没到这个境界，有办法去解决这个问题的，这里不说了。

抛出异常的爱 写道

3.传统分式,每人负责一个模块...素质要求就低了?

我也说过这个有点牵强

抛出异常的爱 写道

4.每天交流比每周一次交流更需要沟通能力了?

我什么时候说过这句话？ 交流有交流的规则，多交流肯定是好的

抛出异常的爱 写道

[

我早就说过了.
敏捷最大的缺点在于...根本没人相信.....不肯试一试.

敏捷在国内客户确实很少人相信 ，这也是国内项目敏捷暴露的缺点，不过不是敏捷的缺点，是客户和vendor的缺点

15 楼 抛出异常的爱 2008-12-11  

welllove53 写道

抛出异常的爱 写道

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

笑喷了.

笑什么？你以敏捷的方式给国内客户做过项目吗？（就是那种政府，电信，某些不良企业），没做过就不要来说。

除了每人负责一个模块有点牵强，其他哪有不对。

1.如果你作过大项目你说说:是cmmi3更需要加班,还是敏捷更需要加班?
2.大项目都是估出一个 人/月 数才定的价格吧.敏捷如果用定时间合同的话.....谁还敏捷啊.生产率提的越高收入越少???
3.传统分式,每人负责一个模块...素质要求就低了?
4.每天交流比每周一次交流更需要沟通能力了?

我早就说过了.
敏捷最大的缺点在于...根本没人相信.....不肯试一试.

敏捷是指在开发过程中迅速的改变尝试好的经验,如果效果不到预期就放弃回到老路上.
而不是在一开始计划好了向一个方向实施.
XP是这一理念下生出来的实践的集合:不是非要用.用了也不一定就是敏捷.

态度不对怎么也敏捷不起来的.

14 楼 ag_sherry 2008-12-11  

不懂敏捷、但是我支持楼主的态度！bs藐视一切的家伙！

13 楼 welllove53 2008-12-11  

抛出异常的爱 写道

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

笑喷了.

笑什么？你以敏捷的方式给国内客户做过项目吗？（就是那种政府，电信，某些不良企业），没做过就不要来说。

除了每人负责一个模块有点牵强，其他哪有不对。

12 楼 welllove53 2008-12-11  

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

顶你！
深有同感。
这些经验都是以项目的代价发现的，说服客户使用人天合同方式是一个比较麻烦的问题

其实敏捷的结对 我不赞同，不管从效率，政治方面讲，（当然指的是95%的那些项目），都不划算。
其实项目强调的是沟通，每个team都要找一个好的沟通模式。

11 楼 tuti 2008-12-11  

对一个快饿死的人，告诉他要饮食均衡有意思吗

10 楼 抛出异常的爱 2008-12-11  

liano 写道

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

笑喷了.

9 楼 liano 2008-12-11  

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

8 楼 liano 2008-12-11  

我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。
敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。

2.敏捷对人员的素质要求比较高
传统的分工基本上是每人负责一个模块，敏捷要求代码共有。
敏捷要求结对，这是对dev沟通能力的一个考验
敏捷要求TDD，对开发人员能力要求比较高

当然，高标准严要求才能出来好的软件。

7 楼 ball_cao 2008-12-10  

敏捷的最大问题是门槛高
很多团队跨不进去

6 楼 抛出异常的爱 2008-12-10  

liano 写道

hyhongyong 写道

LZ对敏捷的编程方式理解有多少？
理解到的话就不应该有这个问题了。

我既然提出这个问题，就是想对其有更深层次的理解。
你这个人如果不想回答这个问题，就别他妈乱发贴，有意思吗？！

共产好么?
好!
那共产有什么缺点?
你的回答就是了       你不信就没好处

5 楼 hkliya 2008-12-10  

liano 写道

hyhongyong 写道

LZ对敏捷的编程方式理解有多少？
理解到的话就不应该有这个问题了。

我既然提出这个问题，就是想对其有更深层次的理解。
你这个人如果不想回答这个问题，就别他妈乱发贴，有意思吗？！

LZ语气有点重了。。。
BS  hyhongyong，尽说废话！！！

4 楼 liano 2008-12-10  

hyhongyong 写道

LZ对敏捷的编程方式理解有多少？
理解到的话就不应该有这个问题了。

我既然提出这个问题，就是想对其有更深层次的理解。
你这个人如果不想回答这个问题，就别他妈乱发贴，有意思吗？！

3 楼 魔力猫咪 2008-12-09  

敏捷其实目前最大的问题在于商业模式。开发本身问题不是很多。主要是如何和客户签订合同、如何计算工作量等等。
敏捷在开发的时候因为需求还很模糊，所以如软件规模、开发周期等东西无法确定。而我们传统的商业合同在这些地方都是非常关键的，因为规模、周期是要决定价格的。而敏捷开发在这方面无法在一开始就确定。确定了也就不是敏捷的了。
我觉得敏捷开发其实是提供一种服务而不是一个商品。但是在客户特别是国内客户看来，如果这是服务合同，那么开发者可能会消极怠工而拖长工期以获得更多收益而更希望签订一个规定时间规定具体产品的合同。

2 楼 hyhongyong 2008-12-09  

LZ对敏捷的编程方式理解有多少？
理解到的话就不应该有这个问题了。