关于敏捷我有几个疑问

搞了一段时间敏捷，发现了其中的一些好处，不过因为毕竟实践敏捷比较少，有几个疑问列下面，欢迎讨论：
1，很多人都在讨论说敏捷的成功与使用与否都跟老板有很大关系，那为什么老板会不使用敏捷，是不是敏捷有很多缺点让老板望而却步？为什么国内好多公司都不用敏捷？老板对实现敏捷成功与否究竟有多大影响？
2，什么样性质的公司适合用敏捷，什么样的公司不适合敏捷？为什么好多国内企业都不用敏捷？难道是不适合？
3，针对一个没有实践过敏捷的公司，我该如何推进各项工作慢慢的让公司转向敏捷？
4，敏捷与CMMI，ISO之间是否有冲突，因为敏捷不强调文档的重要性，而且敏捷无法被中断，但是公司的很多实际情况就是往往开发过程中需要中断开发，去搞专利申请，补写设计文档。。。等紧急但无法计划的工作
5，如果公司需求人员对需求了解的不是很全面，客户又不能参与到敏捷团队中来，backlog的产生和分解该如何进行？其实很多公司面临的问题就是需求还不是很明确，已经需要开始开发软件了，敏捷的第一个sprint计划该如何做？
6，敏捷的测试具体怎么做？（问题有点大，呵呵）敏捷强调沟通，所以开发与测试人员为同一个敏捷团队，在需求确定初期，第一个sprint，没有任何可工作的产品的时候，测试人员做什么？TDD应该是开发人员做Test case，测试人员如果这时候也做test case，是不是跟TDD的工作重复了？
7，公司目前没有测试人员，实施敏捷如果没有专职测试人员会不会失败？有人提出领导重视质量才会用敏捷，那究竟是敏捷提升了质量，还是测试人员提高了产品质量？测试人员在敏捷实施过程中的重要性有多高？
8，实施人员和客户不定期，不确定性的会提出很多产品bug（有部分是客户的需求变化）），而且要求修改bug的时间很短，因为往往用户看不到产品，给不出新的需求，看到产品后又急于达到自己现有的想法，如果使用敏捷开发，怎么中断开发员的开发而去做这些紧要，而有可能一下子很多的产品bug？

9，公司为了考虑开发成本，进来了很多实习生，有经验的开发人员不多，这种团队是不是不能使用敏捷？或者说使用敏捷后会不会比不使用好一些？

还有很多疑问，对敏捷体会不深，望赐教！

敏捷说到底是以人为本。但是很多开发人员，很多老板都不能认识到这个问题。

谢谢回复，感觉国内实践敏捷的公司很少，我想应该是有一定的原因的

10万的一个活......让敏捷的公司来作100万不止

我们公司以前开发的时候，常常是这样的节奏：一年做两三个大的项目。项目开始了，天天加班，甚至于周末加班；项目结束了，所有人闲着没事做。项目刚开始时事做需求的忙，天天开会，各种文档；之后是开发忙，以为懂了业务，匆忙写程序，遍写遍发现对业务的理解有问题，遍不断的大改代码；再之后，是测试忙，天天测试，不断测试，开发跟着修bug；终于熬到所有bug都差不多了，熬夜上线。之后，少量人修bug，大部分人才闲下来，等待下一个项目的到来。

采用敏捷后，节奏是这样：迭代开始（两周一个迭代），大家一起讨论需求，一起拆分任务，一起估算任务时间；之后每天开发领任务，每天开发完了，交给QA测试；QA准备测试案例，每天测试已经开发完成的任务；业务分析人员除了解答需求之外，准备下轮迭代的需求；迭代结束时，小规模上线。如此周而复始，没有大项目，都是小迭代。不试图一次性实现所有需求，而是一小块一小块的实现。从此之后，基本上没有加班了，不会一个月忙死，一个月闲死。人人天天都在不紧不慢的工作。

敏捷，要求人们用最快速的方法，在短时间内完成最重要最紧迫的功能的开发测试发布，缩短周期，以避免大项目带来的不可预知的风险。让所有的人匀速地活动起来，通过一段时间磨合后，团队形成稳定的输出，使得后续的开发更加可控。

敏捷的真谛就是在于人，大家一条心做事，大家有事当面说，大家时刻保持沟通。

如果楼主遇到过我上面提出的问题，想要改观，建议你尝试一下。

1，核心是权利的问题。国外也有很多公司敏捷很成功，但是很快就恢复了老样子。为什么呢？因为团队都自管理了，那么领导管谁去。中层和中层靠上，又没到最高层这部分，和下面团队对项目管理权利的争夺，造成敏捷被放弃。因为毕竟在争权这方面原来的管理者更有优势。
2，新兴公司、人际关系比较单纯、领导肯放权的公司敏捷容易成功。人际关系越复杂，权利争夺激烈的公司不容易成功。
3，建议看看《布道之道》这本书。
4，冲突是肯定的。解决的办法是根据实际情况进行各种裁剪和妥协。敏捷并非无法中断，只要有足够理由，中断也没关系。
5，看看《领域驱动设计》。
6，强调单元测试、持续构建。开发集中在白盒，测试集中在黑盒。有了需求自然就可以指定对应的测试用例。
7，是否需要专门的测试，要看具体的项目。如果是给程序员自己用的产品，那么程序员就是最好的测试人员。只要吃狗食就可以测试出绝大多数BUG。但是一些专业应用软件，就需要专门的测试人员了，因为程序员本身并不是非常熟悉具体业务。敏捷和测试人员是否提高质量，要看其使用是否得法。是否是挂羊头卖狗肉。
8，确保迭代周期的基本稳定。除非是及其严重的BUG和动摇现有需求体系的需求，不建议中断迭代改BUG或者插入新需求。要保证持续的产出而不是混乱的尖峰性产出。提出的BUG和需求一般会作为下次迭代的一部分需求处理。
9，可以使用敏捷。没有什么不可以的。而且因为是白纸，所以更容易接受敏捷思想。会比非敏捷情况要好，但是敏捷更容易被当作项目失败的替罪羊。敏捷不能让菜鸟一下变高手，只能说实施好了，菜鸟也可以把自己的水平充分发挥。

都是敏捷高手，谢谢回复，感觉思想通透了很多

如果都在争权夺利，搞内耗，老实说，用什么软件工程方法都不会搞得太好。这个不是软件工程的问题，是领导艺术的问题。如果敏捷确实能改善软件质量，提高开发效率，那么随着市场竞争，我相信会有越来越多的企业采用这种方式。

团队自管理了，那是好事，从更高层的角度看，可以节省一些领导的人力呀。要知道领导的人力可是成本很高的。团队自管理了，领导可以把他们的精力花在其它事情上了，不可能没事做，如果没事做，我只能说那是更高层的领导的管理能力不足了。

敏捷本身就是可裁剪的，如果老板或同事不支持，不用管他们，你可以自己偷偷的进行一些低成本的敏捷实践啊，比如TDD、重构什么的
如果完全不用敏捷的话，不用说，肯定是一堆杂乱重复的过程代码，或者是过度设计的代码。
你觉天整天生活在这样的代码中有意义么？

最常见的是不要文档.....