|
锁定老帖子 主题：敏捷和传统的编程方式相比，有什么缺点？
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-11
最后修改：2008-12-11
liano 写道 我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。 敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。 2.敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共有。 敏捷要求结对，这是对dev沟通能力的一个考验 敏捷要求TDD，对开发人员能力要求比较高 当然，高标准严要求才能出来好的软件。 笑喷了. |
| 返回顶楼 | |
|
发表时间：2008-12-11
对一个快饿死的人，告诉他要饮食均衡有意思吗
|
| 返回顶楼 | |
|
发表时间：2008-12-11
liano 写道 我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。 敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。 2.敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共有。 敏捷要求结对，这是对dev沟通能力的一个考验 敏捷要求TDD，对开发人员能力要求比较高 当然，高标准严要求才能出来好的软件。 顶你！ 深有同感。 这些经验都是以项目的代价发现的，说服客户使用人天合同方式是一个比较麻烦的问题 其实敏捷的结对 我不赞同，不管从效率，政治方面讲，（当然指的是95%的那些项目），都不划算。 其实项目强调的是沟通，每个team都要找一个好的沟通模式。 |
| 返回顶楼 | |
|
发表时间：2008-12-11
抛出异常的爱 写道 liano 写道 我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。 敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。 2.敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共有。 敏捷要求结对，这是对dev沟通能力的一个考验 敏捷要求TDD，对开发人员能力要求比较高 当然，高标准严要求才能出来好的软件。 笑喷了. 笑什么？你以敏捷的方式给国内客户做过项目吗？（就是那种政府，电信，某些不良企业），没做过就不要来说。 除了每人负责一个模块有点牵强，其他哪有不对。 |
| 返回顶楼 | |
|
发表时间：2008-12-11
最后修改：2008-12-11
welllove53 写道 抛出异常的爱 写道 liano 写道 我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。 敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。 2.敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共有。 敏捷要求结对，这是对dev沟通能力的一个考验 敏捷要求TDD，对开发人员能力要求比较高 当然，高标准严要求才能出来好的软件。 笑喷了. 笑什么？你以敏捷的方式给国内客户做过项目吗？（就是那种政府，电信，某些不良企业），没做过就不要来说。 除了每人负责一个模块有点牵强，其他哪有不对。 1.如果你作过大项目你说说:是cmmi3更需要加班,还是敏捷更需要加班? 2.大项目都是估出一个 人/月 数才定的价格吧.敏捷如果用定时间合同的话.....谁还敏捷啊.生产率提的越高收入越少??? 3.传统分式,每人负责一个模块...素质要求就低了? 4.每天交流比每周一次交流更需要沟通能力了? 我早就说过了. 敏捷最大的缺点在于...根本没人相信.....不肯试一试. 敏捷是指在开发过程中迅速的改变尝试好的经验,如果效果不到预期就放弃回到老路上. 而不是在一开始计划好了向一个方向实施. XP是这一理念下生出来的实践的集合:不是非要用.用了也不一定就是敏捷. 态度不对怎么也敏捷不起来的. |
| 返回顶楼 | |
|
发表时间：2008-12-11
最后修改：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的缺点 |
| 返回顶楼 | |
|
发表时间：2008-12-11
最后修改：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至少要三周时间. |
| 返回顶楼 | |
|
发表时间：2008-12-11
不好意思，我做的不是对日外包。是对美国
1.确实敏捷方式前几（2）个迭代很累，后面就好了，准时上下班，就是开会时要早点 2：俺们做的项目确实是完整的，不过有的是一个大产品中的一个子项目 3：虽然没做过对日，但我一直不屑于做，可能是因为对日项目的名声不好吧 |
| 返回顶楼 | |
|
发表时间：2008-12-12
liano 写道 我总结一下，现在来看，敏捷的缺点有一下几方面
1.由于敏捷通常采用scrum的方式开发， 所以scope不确定，因此从business的层面签合同的时候很多必须按照人天来签，这个就有一个前提，就是信任。scrum必须以信任为基础，如果不信任，客户就会怀疑开发团队懒散，做工作不尽力，这样就没办法合作了。 敏捷一般不是定价的合同，而传统项目都是定价的合同，对于定价的合同，客户的风险比较小。而按人天计算的合同，如果出了问题，开发team除了声誉受损，没有别的损失。 2.敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共有。 敏捷要求结对，这是对dev沟通能力的一个考验 敏捷要求TDD，对开发人员能力要求比较高 当然，高标准严要求才能出来好的软件。 我看着就想笑，你通篇谈信誉，说诚信，瞎讲素质，可是就你这点素质也配谈这些，笑掉大牙，我看你性欲应该很强，去做鸭得了。 就你这种素质，一开口就骂人，老子实在是看不过去了。像你这样的人做开发直接是玷污了软件开发的圣洁。 跟何况就你这点点能力，哎，一看你就是没读过书，更是从没写过代码的。 hyhongyong小兄弟不要跟这种烂人计较。 
|
| 返回顶楼 | |
