您当前的位置:
我的看法：这个和行业有关，大多数互联网产品是敏捷的宣言所描述的那样（这是由互联网产品的特性决定的），项目很多时候也是这样。
但是我所了解的很多产品，是一组相互关联的概念组成的，比如我之前做CA系统（数字认证），其需求是一组关联非常紧密的概念组成的，在这些概念的基础上，可以细化为具体的需求项，然后衍生出架构，在架构的基础上去进行细节的实现。这个时候，并不是那么容易拆开，一个迭代做几个需求的。
这样情况下，最容易发生的，就是第一个迭代做了需求1234，第二个迭代准备做56789，结果发现5的设计和实现需要把1和2的设计和实现推倒重来（概念冲突、架构上大的改变等）。所以直接在需求上小版本迭代，反而容易引起工作量上的浪费和工期的延误，所以需要先把概念和架构搭建好，作为后面迭代的一个基础。
虽然敏捷里sprint0是针对这个问题的，但是这样来看sprint0变成了最最重要的一个环节。或者演变成：
1、在使用敏捷方法之前，采用传统方法完成需求的分析和评审
2、需求分析完成之后，才有传统方法完成概念设计和架构的设计
3、在此后，可以采取敏捷的方式，多次小版本迭代直至完成
或者
1、使用传统方法完成第一个版本，重点考虑产品的概念完整性和可持续性
2、后续的版本，因为没有概念上根本性的变化，采取敏捷的方式
当然，如果你的需求天然就是关联不大，那采取敏捷是应天顺人，无需争议。
因为刚听完敏捷的培训，所以有这样的体悟，对与不对，每个人有自己的评判。我的看法是，小版本迭代有些场景非常适用，有些场景需要变通一下。但是我觉得站立会议、结对编程、提高测试的重要性都非常好非常实用。