首先什么是敏捷开发？
敏捷开发不仅仅是快速编程和迭代式需求变更。他有很多的实践。
比如沟通损耗尽可能低的小团队。
比如面向故事，测试驱动开发。
比如头脑风暴。
比如多人编程提高质量。
比如自解释的代码。
等等等等
在大学的时候，因为在某家还可以的公司实习，显得很狂妄，答辩的时候，我对答辩老师说，虽然传统上说敏捷并不适合大型项目，但是确实有些大型公司在使用并且成功了。
经过8年的工作，我想收回那句话。
敏捷并不适合所有团队，所有项目。
敏捷思想的真实核心不是工程管理，而是欲望。
其实这些实践中不难发现，都是在刺激编程人员创造力和成就感。这些方法都是基于"精英"程序员的做法，就是，那些以编程为乐趣，废寝忘食的人，对于这些人，别说996，忙到2-3点，睡两三个小时，继续工作的都乐此不疲。
现实情况是，这样的人，事实上很少，绝大部分程序员只是编程当成一个工作，老板把项目当成谋利工具，把敏捷当成减少成本的方式。在这样的团队里搞敏捷，味道已经不对了，资方抠，劳方精，是不可能真正完成上面的实践的。
不是说敏捷不好，只是合适的方法，需要合适的平台，很多地方把敏捷说的那么高效，那是因为大神的队友也都是大神，他们思维活跃，不受束缚，富有创造力，这也就不难理解为什么敏捷里会有增加成本的双人编程的情况了。在大部分公司里，用代码的规范替代了双人编程的思维发散与了解。用绩效来替代了迭代。用模块分工替代了头脑风暴。用测试团队替代了测试驱动。确实不太对味。
在国内，老板有老板的苦衷，员工有员工的想法，如果不是一群创业爱好者，尽可能还是走瀑布，走原型吧，没有付出的老板和没有责任心的员工不适合这种高度自由的方式。
