与“敏捷”相关的实践太多了，我曾经沉迷于各种敏捷实践，不加思索就奉为宝典。后来我才发现，很多东西并不现实，再后来我觉得，对敏捷，抓住它的核心价值才是最关键的。
我的结论是：
敏捷过程要解决的核心问题是解决“客户需求会在开发过程中产生变化”这样一个问题
1.首先，
这是一个项目过程问题；而不是设计、开发、文档和测试方面的问题。也就是敏捷过程的核心价值在于项目风险控制，而不是设计、开发、文档和测试。
2.敏捷之所以可以解决这样一个问题，是因为它的iterative特性。
分迭代实现产品，每个迭代可以较快地完成并及时让客户看到，客户随后再决定后续的产品应该怎么做。这样你就可以保证："doing the right thing"，产品能够符合客户需要，客户关系得到维持。
如果不使用迭代，而是等到开发完成才反馈，那这个反馈就太晚了，后果你懂的。
你可能会问为什么不用一次原型法，它也可以提供形象的反馈啊。我的看法是对原型的投入很难控制，做的太差，反馈效果不好；做的太好，时间浪费过多。而迭代法相当于演进原型法，原型即产品，不会浪费。
3.不过，迭代法在项目管理上有一定的代价：对整个项目的估算的准确性会很差。敏捷开发中，
只有最近几个迭代的需求才比较精确，所以你只能对最近几个迭代有比较准确的估算，整个项目（或第一个可发布版本）的工期和交付日期都会很难预估，管理层对此未必会满意。所以，要玩敏捷，就需要所有利益相关者都愿意接受这样一个事实：每个迭代可以做到精细控制，做到很好的可视性，但最后的上线时间可能会有较大的误差；利益相关者还需要把迭代的完成当作一种成功，把过程和结果都当作绩效评价指标。
4.对上面说的这种问题不可一厢情愿地视为小问题，你最好要搞清楚管理层的风格才行事，否则就应该想办法变通。
首先可以先问下自己，在这个项目里“客户需求会在开发过程中产生变化”这种问题是否真的存在？比如说“用新框架将本系统重写一遍”这种项目并不需要迭代模式。
其次，可以再问一下，“项目能否拆分成多期，每一期完成后即可交付运营？” 如果答案是肯定的，就可以对当下这一期的工期进行细致估算，交付时的进度表现就会比较好看；虽然整个大项目的结束日期仍然未明，但既然时时有东西上到生产环境产生经济效益，管理层就不会管那么多了。
5.另一个问题是，如果迭代只是为了提供反馈，那为什么每个迭代开发完成后还要测试，而不能等到准确交付时再一起测呢？ 我认为这主要是为了让测试可以在开发过程中就参与进来，不必等到所有开发完成才进入，这样可以跟开发人员并行工作，实现节省时间的目的（当然也可以起到及早发现bug、及早修复的作用）。但我还认为，
每个迭代都做测试并不能帮助我们解决核心问题，开发人员的自测，已经可以使系统足够健康，应对客户的检视了；如果测试的人力资源紧张，等到交付前再让他们对整个系统进行测试其实也是可以的。
总之，我认为，敏捷过程针对的
核心问题是“需求会在开发过程中变化”，应对这个问题的
策略是及早给用户提供反馈，具体的
手段则是迭代式开发。你会说迭代并不是敏捷的专利，没错，本文的标题应该改成“基于迭代的各种软件生命周期要解决的核心问题有且只有一个”
最后，说一下为什么我认为敏捷的核心价值只体现在“拥抱变化”上，而跟“设计、开发、文档和测试”没多大关系。
因为我觉得敏捷开发在“设计、开发、文档和测试”方面的实践要么意义不够巨大，要么普适性很弱，要么根本就是宅男说梦。比如说User Story，它一定就比需求规格说明书好用么？再比如“按最简单的方案来实现 + 频繁重构”，认为简单的代码即使设计不够柔性，改起来也会很容易，这太一厢情愿了。至于“结对编程”、“测试驱动开发”、“一套可作为检验重构正确性的Test Suite”云云，都太强人所难了，这些想必很多人都有体会，就不一一细说了。