【IT168 评论】敏捷一词对于我们来讲已经不再陌生，在业界已经成为一种软件开发活动的推荐模式。那为什么要敏捷?
这个答案很多，每个开发者心中都有一个自己答案，其实答案本身并不重要，重要是思考的过程。这个问题也没有一个标准答案，就像每个软件开发男都有一个自己心中的女神，女神可能是不一样的，女神是否相同并不重要。
言归正传，个人观点如下。回答敏捷是什么?为什么要敏捷?回答“为什么要敏捷”的前提是回答“敏捷是什么”，因此首要任务是要先回答第一个问题，从敏捷技术的观点看，核心是敏捷价值观、敏捷价值观外层为敏捷管理，比如XP或者Scrum;最外层为敏捷技术实践，比如CI、TDD和结对编程等技术，从这个结构看最里层是一种敏捷文化、中间层为软件开发过程管理方法，最外层为具体技术实践，因此敏捷运行核心要素是通过软件开发过程管理方法连接内层敏捷价值观和外层敏捷开发技术实践，对外呈现出一种开发模式和方法。
其次回答第二个问题，首先要解决敏捷不可替换价值在哪里?如果说敏捷是交付有价值的软件产品，那么非敏捷方式难道就不能交付有价值的软件产品?这个推论站不住脚，我们同样也可以使用非敏捷方法交付有价值的软件产品，现在仍然有大量的软件产品按照非敏捷的方式进行开发，同样也在交付价值。在我看来，一个字可以回答“为什么要敏捷”，这个字在于“变”，我们需求的变化。
三种场景需要敏捷开发
在我看来，需求的变化有以下三种场景：
场景一，需求从用户环节到开发环节，这个漫长的需求链条在传递过程中出现了关键信息丢失，导致软件开发产品交付后，与用户需求严重不一致，导致软件重大改动、甚至重新设计;
场景二，用户对于需求的描述定义不准确，导致软件开发产品开发出现偏差，软件产品交付后，需要软件进行重大改动、甚至重新设计;
场景三，需求本身已经有了变化和位移，移动互联网发展非常快，需求本身可能每天都在变化，即使你搞清楚了之前的需求，等你软件产品交付后，该需求已经不成立或者有了重大变化和位移，也会导致软件重大改动、甚至重新设计;
需求变化这么快，需求有可能存在偏差，怎么办?解决方法，可以看看电影功夫中的片段，快，足够的快，快得很抓住子弹。本着“天下功夫，无坚不破，唯快不破”的原则，提升我们软件开发的速度，适应这种变化。
两种途径提高开发速度
怎么能够提升我们软件开发的速度，敏捷方法提供了2个解决途径:
第一 提升人件，通过敏捷团队运作，激发出每一队员的最大潜能，以最大合力完成软件产品开发。就拿敏捷中Scrum来说，Scrum的原始含义，就是橄榄球比赛对抗，要让团队最大力量集中起来，集中一点，取得突破。如何能够激发出每个人的最大潜能，让自己当老板，让自己成为软件产品的老板，软件产品就是我自己，通过自组织团队，让开发人员真正的当家作主，成为软件开发的主人，以此激发队员的最大潜能;同时敏捷文化鼓励队员之间的技术交流和分享，在这种技术交流和分享过程中提升开发人员的自身水平和能力，达到个体战斗力的最大化。
第二 软件开发过程提升，软件开发过程包括需求分析、系统设计、编码、测试、交付、部署、上线这些环节，要做到快速，就必须从多方面入手。
首先，需要把大需求拆分为小需求、从一次完成大而全软件系统交付转换为每次提供一个核心和关键功能最小软件系统快速交付，及时获取用户反馈，这样即使在需求环节出现偏差，也可以减低对于软件产品开发影响，减小需求偏离度，提升软件产品准确命中用户需求要点的能力;
其次，需要提升整个软件开发弹性，引入代码走查、鼓励重构、结对编码和编码风格调整这些举措，让软件编码具有弹性，可以让软件对于后续变化和需求快速响应;
再者，由于需求经常变化，随时都会对于软件进行改动，为了保证软件产品具备快速交付能力，必须通过持续构建来解决系统经常代码改动对于软件产品交付能力的影响，分散产品发布带来的风险;通过自动测试来进行回归测试、集成测试以及系统测试，通过机器测试来换取测试压缩，解决人力测试无法满足测试路径快速覆盖的场景，随时具备软件产品交付能力。
综上所述，敏捷的核心要素在于快，通过人件和软件开发融合发力，实现软件开发过程“快”，以快来取得“准”，以“准”来破“变”，实现软件产品价值成功交付。
