敏捷开发中的项目报价

最近公司准备开始敏捷了.....我一直在这个论坛看大家的观点和思想，获益良多！

敏捷有个思想就是“即使到了项目后期，也欢迎改变需求”。我想知道大家在持续的需求变化中，特别是开发后期了，如果客户的需求比较难以短时间解决，大家怎样处理？要求延期？延期的话，报价怎么办？大家在开发前的报价中是否考虑后期需求变化的风险（前期如果需求变化多的话通过加班还能解决 -__-）？

我公司的项目一般是一个project，客户确定完成期限，然后报价。

请大家指导一下！谢谢！

往高了报，不要往低了报，哈哈
你敏不敏捷，用户都会改变需求，只不过敏捷可以帮你降低成本和风险

成本和风险到底怎样降低的呢？我觉得后期如果客户需求还在变得话，成本和风险反而会大幅提高！
请大虾们解惑！谢谢！

敏捷要的是尽可能快的交付系统，以让用户可以知道自己需要什么。客户改来改去就是没有找到自己真正需要的需求。理论上一个好的敏捷项目越到后边，提出改进的需求都是更加符合客户需要的真正需求。一定要记住，只要有新需求，那么就会有新成本。敏捷是要通过多次迭代、尽快交付等方法尽可能的减少非合理需求产生的成本。
客户每天胡思乱想，反复折腾。一方面是不能很好体验当前成果，不知道自己真正的需求。还有就是需求控制做得不好，来个人就说要某某，改天他的领导又说不要。说白了就是没有一个合理的需求提出、审核机制。
一个项目，首先客户提出一些需求。然后分析这些需求，把最重要的需求先完成。客户根据完成的情况，可以了解到之前的需求是否正确。然后根据看到的产品，提出新的需求。这样反复迭代，就可以得到用户真正需求的产品。
比传统的瀑布方法来，不用到整个项目最后才能看到哪些需求不对，造成大量返工。
而且现在很多人说需求变了造成大量赶工。很多时候都是解耦不好和代码混乱造成的。比如要修改一个分数计算功能，但是这个功能的代码在整个系统里复制得到处都是，你改起来当然叫苦连天。
其实这种开发方法对解耦、模块化、复用的要求相当高。如果你连最基本的分层开发、业务代码只写一次不乱复制都做不到的话，只能越敏捷越乱。开发中单元测试、持续构建都需要跟上。不能这么做的话还是老老实实的瀑布吧。说真的很多人连瀑布也不能遵守。
当组件复用达到一定程度的时候，你可以很容易用调整调用的组件顺序等方法来达到快速完成需求。比如SOA的BPEL、ESB，都是建立在高度模块化的组件的基础上的。用户需求来了，你只需要拖拽组件，确定组件的执行流程，生成一个Service服务。然后建个Action调用就是了。
不过合同方面比较麻烦。部分敏捷达人提出了分模块付费的办法。一个雇佣团队的基础价，只要团队在工作就支付。一个是模块价格。只要完成一个模块，就支付一个模块的价格。如果用户提出增加新模块，那么当然要支付新的费用。

项目的范围管理在哪里？
敏捷不是说让客户无休止（时间，功能等等）。
项目报价时就应该有个明确的范围说明