求教一个用敏捷管理项目的问题

[执着地梦想]

现在负责一个项目，运作方法是：编写当前版本的整个文档（需求文档，产品文档，原型），交付技术，技术做详细设计，先做基础通用开发，结构设计，数据库设计，通用功能开发，然后分模块开发，测试，上线。完成一个版本后，进行下一版本，每个版本阶段两至三个月。
这种方式被称瀑布式开发，思路是整体设计分步实施。
如果用敏捷的思路该怎样规划项目的按排。
我看到一些资料介绍，敏捷的文档不会写很长，称每个文档只有一二十页，我现在的文档写了很长，整个版本，上百页。敏捷 是不是从滑板车到汽车的设计思想，在项目的规划中，是不是先只设计一个功能，如系统的结构设计，写一二十页，交给技术实现，完成后，再进行数据库设计，再开发，再设计通用功能，如权限管理，再开发，依次类推，逐个功能编写，逐个功能实现，是不是这样呢？但这种工作方法，进行到后边后可能要回过头来改前边的东西。而且这种思路不是从滑板车到汽车，这是先生产车轮，发动机，座椅，然后拼在一起。
如果是从滑板车到汽车的思路，整个系统刚开始是简化的，但整个业务流是通畅的。相当一开始就推出各个功能模块，但各个模块是简化的，数据库可能只有几个字段，后续再来添加。
是哪一种方法呢，求大神指正。

[ckc]

敏捷的核心应该是通过及时交付原型进行实际应用，通过用户的及时反馈来快速调整开发工作，在情况变化较快时，在客户对真正所需要的软件不能确定这样一些场合可以提高工作效率，提高产品质量，提高客户对产品的认可。 敏捷轻文档是因为文档生成效率较低，通过可以运行的系统来沟通开发和客户效率更高一些。 轻文档不是目的，这只是经验。所以不要生搬硬套。 一些必要的文档仍然是不可缺少的。根据项目的复杂程度，上百页的文档也是可能的。

[Johnyin]

决定使用某种方法之前，得先弄清楚它的特点，优势在哪，适用在什么条件下。 如果你负责的这个项目，客户需求是比较明确的，系统范围是确定的，就按瀑布式一步步走，没什么不好。至于文档页数多少，由系统规模决定，敏捷开发也是需要写清楚每个story的。过程文档可进行适当裁剪，抓重要的、必须的，无论敏捷还是瀑布。 敏捷的思想是通过充分的沟通交流来达到组员对要实现的系统理解是一致的、清晰的，故而可以省掉很多过程文档。但同时也局限了团队的规模。 瀑布式是强调每一步的产出能充分支持下一步的工作，通过产出来传递、记载客户需求直到系统上线，故而对过程产出比较重视。但它也有弊端，对于需求不那么明确、稳定的事，范围容易扩散的项目，管理起来会很痛苦。

[伏其]

感觉是为了敏捷而敏捷。敏捷是一种思想，不是一种方法。生搬硬套反而会得不偿失。