7. Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。

　　也是事实。但是作为对产品有热情的人，Product Owner难道不愿意花时间和精力帮助团队开发出符合需要的产品么？敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。

　　8. 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以小的投入解决实际开发中的所有问题。

　　这可能也是事实。其实在其他方法论风行的时候，也遇到过类似的批评，比如RUP。大家都期望找到一种能够解决所有软件开发痛苦的方法论。作为有经验的敏捷实践者，教练，经理和架构师，对敏捷的宣传应当适度，尽管敏捷确实能够解决很多软件开发中遇到的问题，但是它毕竟不是万灵药。不要使他人有过高的期望。

　　9. 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。

　　这是事实。Chris Tyler提出的建议是，尽早与其他部门沟通，大家的终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈（参见约束理论）。基于这个共同目标，各个部门一起对流程进行修改，会减少相互诟病。

　　10. 当Product Owner开始决定开发的方向，他会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。

　　这并不是一个问题！Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。

　　11. 敏捷实践大多是针对程序员的，很难在组织内平衡工作量。缺乏对团队中的非程序员提供更好的文档以及培训支持。

　　对于这个Chris Tyler既同意也不同意。敏捷团队是全功能的团队。如果业务分析师、Product Owner没有和团队在一起参与开发，那不是真正的敏捷。敏捷教练、经理也应该承担培训团队中除了工程师以外的成员的职责。对某些团队来说，文档会是一个问题，因为客户总是要求开发团队提供文档。其实行为驱动测试BDD是一种既能够提供需求文档又能够照顾到代码实现的好方法。敏捷中也有文档（参见“敏捷的文档”），只不过是文档的形式发生了变化，变成了XUnit测试以及代码。进一步BDD可以成为业务人员和开发人员的桥梁，能够使业务人员更好地理解XUnit测试以及代码（另外其实还有Fit）。对于已经习惯于基于类似于IEEE的那种需求管理方式的Product Owner和公司高层们，对开发文档形式的改变，他们应当保持开放和学习的心态，充分信任团队，而不是给开发团队带来阻碍。

　　后，Chris Taylor总结到，敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。但是我们不能因为这个放弃向理想努力。尽管过去有很多团队导入敏捷失败，我们还是不能全面否定敏捷，毕竟也有很多成功的敏捷团队。正如敏捷项目团队在开发中不断进行反省修正一样，我们也要通过反省来加深对敏捷的理解和认识。