不久前和同事交流的时候看到这样一段话，“在经历敏捷软件开发方法在中国传播和发展的过程中，我们深切地感到，缺少对软件开发日常基础时间、尤其是与编程紧密相关的核心技术实践的指导，敏捷注定流于形式。缺少完备的软件设计、开发和质量保障相关实践，盲目强调快速迭代、接纳需求变化，项目只会陷入质量迅速腐化、Bug百出、交付失控的悲惨境地。对于这种只得其形、尽失其神、缺乏核心能力、空谈快速响应变化的敏捷，业内将其调侃为中国田园式敏捷”。为什么会出现这样的问题呢?因为大家在学习敏捷开发的时候只是做到了形式上的模仿而忽略了对于本质的理解。那么，今天我们就说说敏捷开发方法的核心目标是什么，掌握了其神，我们在项目管理中就可以聚焦于敏捷的实质，达到事半功倍的效果。

目标1.更快更早的向客户交付价值

我们先来看看传统的瀑布开发模式有什么问题。传统的瀑布开发模式软件会经历需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试等阶段才能发布，这一过程少则几个月半年，大型项目周期长达1年甚至更长，软件的价值在全部做好之后一次性交付。现在VUCA时代(商业和外部环境充满了易变性，不确定性，复杂性，模糊性)等到产品或者项目正式发布的时候，商业环境或者用户的使用场景已经发生了很大的变化，产品或者项目的功能已经不能满足当时的需求，软件交付的价值大打折扣。

不同于传统的瀑布开发模式，敏捷研发模式以迭代的方式持续进行，每个迭代持续收集用户真实的需求以及上个迭代的反馈信息，持续的向客户或者市场交付可以完整运行的产品，持续的向客户交付价值。

价值又来自于什么? 应该来自真实的业务痛点以及客户实际的需求或者问题。不管是敏捷还是瀑布或者其它的软件开发方法，其产生的价值取决于要解决的问题的价值，微信之所以成为伟大的产品，因为解决了人与人沟通，人与人连接，分享信息的问题，百度和今日头条解决了信息爆炸时代的信息检索，获取问题，一切脱离用户业务价值的软件研发活动，都是耍流氓。

目标2.更灵活的响应客户和市场变化

在瀑布开发模式的需求分析阶段，产品设计人员调研需求，设计产品功能这些设计决策活动都是基于假设或者信息并不是很完备的情况下做出的，这就意味着距离后续的技术实现、真实的用户需求或者市场前景会有一定的差距，这种差距会导致后续技术实现、投放市场时会有很多非预期的问题出现。在敏捷开发中，决策是以持续增量的方式做出的。在每个迭代发布后都会收集团队内部、客户、市场或者竞争对手等反馈信息，应用这些信息做出更正确的决策，在下一个迭代中实现，从而可以更灵活的响应变化。

综上，敏捷的核心在于提高一个组织更早交付价值，更灵活响应变化的能力，敏捷的一切实践活动都应该围绕着这两个目标来执行。我们再看一个比较形象的例子，有不少朋友都喜欢看美剧，比如很多年前流行的《越狱》，18年的《权利的游戏》，大家会发现美剧在制作发行的时候有一个特点，是一集一集的构思剧本，拍摄，发行这样的制作流程，之后收集观众的反馈意见，根据大家的投票来决定后续的剧情发展，这其实就是和敏捷的思想是一样的，尽早尽快交付价值，收回成本，根据反馈信息优化后续产品，这样才能制作出受大家欢迎的产品。

那对于一个产品或者项目而言，是否应该采用敏捷研发的方式呢？笔者认为，要根据具体的商业和竞争环境，项目特点来分析，不能一概而论。比如互联网产品，竞争非常激烈，晚几个月出来就没机会了，同时技术发展，用户需求变化很快，就非常适合敏捷。对于一些传统行业，软件相对比较稳定，比较大型的项目(需要顶层设计，自顶而下分解后再集成)，产品的一体化程度比较高比如汽车这样的产品就不太适合持续交付价值，就没必要采用敏捷研发的模式。决策者一定要回归到软件的价值和本质上来思考，不能盲目跟风。

下面推荐一款适合各大团队使用的敏捷开发工具CORNERSTONE，它是一款基于智能化框架，能为企业打造专属管理体系的项目管理与协作平台，支持包含研发、缺陷、运营、销售等多场景项目管理。并且提供文件共享、wiki知识库、多功能报表、仪表视图、汇报等多种协同辅助功能，集成了DevOps、CMDB等多种配套工具。能够帮助企业科学量化团队表现，实时把控项目进展，全方位提升管理效能。

敏捷不是银弹，如果一个组织使用瀑布的方式做不好项目，换成敏捷或者其它方法一定也不行，相反，如果瀑布方式做的很好，换成敏捷只是水道渠成的事情，因为软件研发本质的方法是一样的，道理是相通的。这点拿金庸小说里武功高手打个比方，一个人内功足够强，他再学什么招式，都是一个相对简单的过程，欧阳锋逆转经脉，一样可以练成九阴真经，内功不够，使用什么招式都是花架子，行走江湖被人吊打。最后祝各位读者注重敏捷的神而忘记形，勤加练习内功，早日练成自己的独门绝技。