- 在项目的周期、金额固定的情况下，是否适用敏捷开发，如果用户的持续提出需求变更，敏捷虽然可以随时应对，但是如何避免项目周期无限延伸呢？如何约束双方的合同范围？
2. 一些项目，有监理方，他们按照国家相关规范要求文档的话，要求提供详细的需求规格，概设详设等文档。特别是一些国企、政府项目。用户故事只是记录不是文档，那什么才是提交用户的文档？
3. 敏捷故事与用例、界面原型、数据规范之间是什么关系?“用户输入用户名密码登陆系统”这个用户故事，与“用户名只能是3-20位的英文字符和数字”这样的约束，如何进行统一？
4. 敏捷包括敏捷项目管理、敏捷需求、敏捷开发，这些是否要同步进行才能开始敏捷之旅？如一个团队以往连Ant 和Junit都没用过，如何开始尝试敏捷呢？如果一个开发经理+1个需求+3个开发+1测试 这样的小型团队希望转型成为一个敏捷团队，需要付出多少成本（时间、条件、金钱）？
敏捷的一些基本实践需要用户的基本理解与参与。所以不是很适合你说的情况。不过国外还是有很多实践者尝试解决固定项目中实践敏捷。
敏捷不是魔术，不可能把你的头疼一下解决。特别是多数的敏捷实践如果没有xp类似的技术实践辅助的话，迟早会出问题的。
敏捷的一个好处是类似制导导弹，通过不断的交付/反馈/修正来避免瀑布模式中的后期才发现需求变更或理解有误而造成的高昂修正成本。但是类似scrum的过程本身并不能保证产品/代码的质量。所以最好是scrum过程加xp实践。
问这些问题都是没意义的。你只需要问几个很简单的问题：
你有什么痛苦？
是什么造成了这些痛苦？
你打算做什么来改变现状？
什么在阻碍你做这些改变？
你怎么克服这些障碍？
把你自己力所能及的改变做起来，让自己变得更好了再去跟更多的人一起继续探讨这几个问题。没有万灵药。