每个项目经理都听说过梦魇般的编程项目：项目历时长达预期时间的两倍、严重超出成本预算，又远远看不到结果。幸好，可以使用敏捷编程来解决这些问题。
公司需要想办法降低开发成本、提高软件可靠性、缩短开发时间，并且确保应用软件真正有助于用户，而不是有碍于用户。这四个方面对任何人来说都是难以实现的，但敏捷编程技术能够在许多应用编程场景做到这一点。敏捷编程可通过减少开发人员在设计及开发应用软件中所犯的错误来降低开发成本。另外，它还能消除最高昂的一种开发成本：失败的应用软件。
不过，即便应用软件开发完成、安装到服务器上后，提高可靠性所需的成本仍会抵消应用软件带来的潜在好处。只有精心设计的应用软件，才有望获得大多数公司力争实现的99.999%可靠性。敏捷编程能够完成这项任务，因为可以减少每个模块可能出现的开发错误数量，还能通过不断测试来迅速找出错误。
许多公司期望任何开发项目都能迅速获得投资回报。然而，如果公司等待开发人员完成整个应用软件，大多数项目就会被搁置多年。而敏捷编程技术不是等待整个应用软件完成，而是立即使用应用软件的至少一部分，这意味着用户可以马上从应用软件中受益。
一、敏捷编程有何不同？
敏捷编程把一个应用软件开发项目分成了诸多很小的模块化部分。每个部分在很短时间内逐个解决，然后添加到整个应用软件上，最后提供完整的功能。部署了不完全的应用软件后，人们可以用它来完成某种工作，即使软件不具备从长远来看应当具备的各种功能。
每个部分的迭代过程持续一到四周。因而，用户可以立即知道应用软件的某个部分何时出了问题。这样，就可以立即解决问题，而不是在一大堆错误百出或者“不是用户所需”的代码上实现了各种其他功能之后再解决问题。
每个迭代过程本身就像一个小型项目。作为敏捷项目经理，要像往常那样监管规划、需求、设计、编码、测试和文档编制等各个阶段，只不过这是针对应用软件的某项功能。譬如说，如果正在开发一种特殊的文字处理软件，有个迭代过程可能是针对拼写检查程序的。拼写检查程序添加到文字处理软件上，它影响的只是整个软件的一个方面。开发人员开发处理拼写的迭代过程之前，用户就可以使用该文字处理软件，没有这项功能也没关系。他们只是没法检查拼写的内容罢了。
二、是否需要做大量额外工作？
有些人误认为，敏捷编程技术需要做大量的额外工作。不过事实上，它减少了工作量，还大大加快了投资回报的实现，这是因为每个组件的周转时间缩短了，可以更迅速地投入使用。
事实上，由于开发人员能对这种软件迅速做出反应，项目经理往往使用敏捷编程技术来挽救陷入困境的项目。譬如说，敏捷编程的创始人Kent Beck曾在1986年使用该技术挽救了克莱斯勒综合薪资系统（3C）项目。
三、除了迭代工作方式，敏捷编程还有何不同？
敏捷编程方法的基础是沟通。这种方法强调面对面的沟通，书面文档作为讨论要点。换句话说，不是许多人独立负责开发项目的各个部分，而是大家联合起来，作为一个团队来开发某个部分。
不像其他编程方法，敏捷编程依靠的是大不相同的成员组成的团队，这些人分组工作。团队成员包括：项目经理、设计人员、开发人员、测试人员、客户、文档编制人员以及需要使用这部分软件的其他任何人。因为相关各方能够协同工作，所以通常有可能在极短时间内完成开发，几乎不需要什么改写。
然而，敏捷编程方面要考虑的最重要因素就是，开发过程涉及每个人。客户（用户）从一开始就参与项目，这意味着开发团队能比较准确地了解用户与应用软件之间如何互动以及执行某项任务所需要的步骤。
四、企业文化会不会发生变化？
敏捷编程所需的环境确实有别于通常的那种企业环境。譬如说，团队的所有成员必须或多或少信任其他成员。任何人都不能拒绝向团队成员提供信息、资源或者数据。
除了信任外，团队成员必须愿意妥协。应用软件的一个部分可能需要某些功能；而有些功能虽好，却没有必要。有时，为了在合理的时间内开发完成某部分，团队必须确定弃用没有必要的功能，留给将来的迭代过程去实现。
团队做出的一些决策也许不受整个公司的欢迎，“你不可能讨好每一个人”这句老话适用于此。因为团队中包括来自公司各部门的代表，公司必须信任团队这么做是出于好意，目的在于接受开发团队交付的那部分应用软件。不然，项目会很快陷入一片混乱。当然，这不是说公司不得不接受错误百出或者无法完成任务的应用软件。之所以分成小部分来部署应用软件，就是为了更早发现及补救软件错误及使用问题，从而减少补救成本。
最后一点就是，提供促进团队成员之间沟通的环境。实现这个目标需要为团队成员提供特定的工作场所。成员们应当保持同样长的工作时间，以便其他成员需要沟通时能找得到人。
五、何时避免使用敏捷编程技术？
应用软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。
譬如说，一家公司需要开发无法分成诸多小部分的大型应用软件，要20余名开发人员才能完成。例如，为一家大医院开发心脏监测应用软件，就不希望只开发出监测心脏的那部分软件，在还没有开发出病人心脏有问题后发出警报的其他部分时就部署上去。这种情况下，必须开发出整个应用软件、整体测试后才可以部署，否则后果会很严重。这种场合下，敏捷编程技术算不上是良好的解决办法，因为一旦涉及了许多人，系统马上会崩溃。
需要分布式开发的应用软件也不是非常适合使用敏捷编程技术。如果有些开发人员在英国、有些在美国，团队成员沟通起来不够迅速。分布式团队很难得到敏捷方法带来的所有好处。系统很快会陷入泥沼，你会发现大量时间用在了为团队的每个成员提供最新信息上。
敏捷编程技术还很难应用于每个部分一开始就要用的关键任务型应用软件。因为敏捷编程技术最适合小的迭代过程，那样整个应用软件不必立即开发出来。这种方法要求公司部署不完全的应用软件，以便征求整个公司的意见。目的在于，迅速补救任何实际缺陷及使用问题，而不是开发出一个完整的应用软件，等项目结束后才能测试。
有些公司本身也不适合使用敏捷编程技术，因为采用了集中的命令式管理方式，这遏制了敏捷编程发挥作用所需的有创意的方法。
六、只有一种敏捷编程方法吗？
敏捷编程包括好多方法，都可以用来实现目标。到底使用哪种方法，取决于想开发的应用软件类型、想要满足的客户以及公司内部的环境。下面是几种比较常见的敏捷编程方法：
◆极限编程（XP）
这种方法强调的是适应性，而不是可预测性。它最适合这种场合: 公司并不确切知道自己需要什么样的最终产品。这种方法最先由Kent Beck采用。
◆Scrum
这种方法强调的是重新开始迭代过程，而不是企图补救问题。它最适合这种场合: 公司在使用新工具，以及应用软件在开发过程中几乎肯定会变化。1993年，Jeff Sutherland在Easel Corporation最先使用了Scrum方法。
◆自适应软件开发（ASD）
这种方法强调的是速度和灵活性。它最适合这种场合: 公司需要应用软件能够迅速见效，还能随客户使用需求的增长而灵活变化。这种方法的发明者是Jim Highsmith。
◆动态系统开发方法（DSDM）
这种方法最初来源于强调用户参与的快速应用软件开发（RAD）技术。它最适合于在开发人员不是非常了解环境的情况。1990年，DSDM联合会在英国发明了这种方法，旨在综合编程最佳实践方面的经验。
◆功能驱动开发（FDD）
这种方法强调的是可预测性以及遵守开发最佳实践。它最适合以下场合: 开发团队必须开发具有特定功能及可读性高于正常水平的应用软件。1997年，Jeff De Luca最早发明了这种方法，旨在满足当时一家新加坡大银行的需求。