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

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

敏捷的有双人编程；传统的没有。

敏捷的可能一边理解需求，一遍写代码，叫快速实现原型；传统的从概要设计到详细设计再编码。

其他都差不多，敏捷的那些原则都适用于传统的。

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

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

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

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

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

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

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

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

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

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

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

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