敏捷宣言诞生至今已20多年，在众多挑战瀑布的方法中，它完美的完成了这次反叛，成为主流的方式。敏捷最早作为软件行业的开发方式，现在逐渐渗透到其他行业。
随着敏捷方法流行，越来越多的概念，方法论，实践被加了进来，“敏捷”开始变得臃肿，很多和敏捷八杆子打不着的方法也号称“敏捷”。人们开始在各种概念中迷失，敏捷的本质被逐渐掩盖。
敏捷首要解决的问题是小团队开发，两个披萨可以喂饱的团队（6～12个人），如下图敏捷的核心实践，都是针对小团队的一系列活动：
我认为整个敏捷开发活动最重要的是BDD和TDD两个实践，再辅以过程透明化，快速反馈与持续改进。
为什么这两个实践如此重要，整个软件开发活动中我们要解决的三个核心问题是：
如何确保充分理解了业务需求
如果确保技术上能实现该需求
如何确保开发出来的功能满足业务需求
BDD通过与业务达成一致的实例化需求，来确保我们理解了业务需求，如果我们不能写出验收用例，证明我们还没理解业务需求。验收测试用例用来衡量我们是否真正理解业务需求。
同时我们把验收用例自动化，通过自动化验收测试，来确保我们开发出来的功能是满足业务需求的。
TDD通过自动化测试，来确保我们技术上是可行的，如果不能写出自动化测试，就无法确保在当前技术框架下可以完成该功能开发。
这两个实践使我们的开发活动工程化，只有通过工程化，才能确保我们的需求透明化，开发透明化，验收透明化，才能得到快速反馈，最后才能根据反馈持续改进。
关于规模化敏捷，人类历史上是不缺乏大规模的组织活动（金字塔，巴拿马运河，登陆月球，原子弹等等等），敏捷是通过首要解决小团队问题，然后把大规模团队划分为小团队，来达到规模化效果。但如果不先解决小团队问题，规模化敏捷就会流于形式。举个例子，规模化敏捷的核心问题就是团队间协作，版本火车中投入最大，耗时最长就是整个版本开发活动，多个团队要在估算的时间完成某功能联调活动，如果团队不具备TDD能力，那么团队的任务估算无法保证，导致该功能无法按时联调，团队间产生等待，连锁反应到迭代末团队继续追赶任务，无法投入到下迭代需求分析活动中，影响一直持续到后续迭代。
最后关于敏捷价值观，在眼花缭乱的各种方法中，以及在我们教练辅导中，是否还秉承着Kent Beck提到最核心的敏捷价值观：勇气，沟通，反馈，简单。