在敏捷中存在的6个问题，你不知道几个？

每个项目经理都听说过梦魇般的编程项目：项目历时长达预期时间的两倍、严重超出成本预算，又远远看不到结果。幸好，可以使用敏捷编程来解决这些问题。

公司需要想办法降低开发成本、提高软件可靠性、缩短开发时间，并且确保应用软件真正有助于用户，而不是有碍于用户。

这四个方面对任何人来说都是难以实现的，但敏捷编程技术能够在许多应用编程场景做到这一点。

敏捷编程可通过减少开发人员在设计及开发应用软件中所犯的错误来降低开发成本。另外，它还能消除最高昂的一种开发成本：失败的应用软件。

不过，即便应用软件开发完成、安装到服务器上后，提高可靠性所需的成本仍会抵消应用软件带来的潜在好处。只有精心设计的应用软件，才有望获得大多数公司力争实现的99.999%可靠性。

敏捷编程能够完成这项任务，因为可以减少每个模块可能出现的开发错误数量，还能通过不断测试来迅速找出错误。

许多公司期望任何开发项目都能迅速获得投资回报。然而，如果公司等待开发人员完成整个应用软件，大多数项目就会被搁置多年。而敏捷编程技术不是等待整个应用软件完成，而是立即使用应用软件的至少一部分，这意味着用户可以马上从应用软件中受益。

敏捷编程把一个应用软件开发项目分成了诸多很小的模块化部分。每个部分在很短时间内逐个解决，然后添加到整个应用软件上，最后提供完整的功能。

部署了不完全的应用软件后，人们可以用它来完成某种工作，即使软件不具备从长远来看应当具备的各种功能。

每个部分的迭代过程持续一到四周。因而，用户可以立即知道应用软件的某个部分何时出了问题。

这样，就可以立即解决问题，而不是在一大堆错误百出或者“不是用户所需”的代码上实现了各种其他功能之后再解决问题。

每个迭代过程本身就像一个小型项目。作为敏捷项目经理，要像往常那样监管规划、需求、设计、编码、测试和文档编制等各个阶段，只不过这是针对应用软件的某项功能。

有些人误认为，敏捷编程技术需要做大量的额外工作。不过事实上，它减少了工作量，还大大加快了投资回报的实现，这是因为每个组件的周转时间缩短了，可以更迅速地投入使用。

敏捷编程方法的基础是沟通。

这种方法强调面对面的沟通，书面文档作为讨论要点。

换句话说，不是许多人独立负责开发项目的各个部分，而是大家联合起来，作为一个团队来开发某个部分。

不像其他编程方法，敏捷编程依靠的是大不相同的成员组成的团队，这些人分组工作。团队成员包括：项目经理、设计人员、开发人员、测试人员、客户、文档编制人员以及需要使用这部分软件的其他任何人。因为相关各方能够协同工作，所以通常有可能在极短时间内完成开发，几乎不需要什么改写。

敏捷编程所需的环境确实有别于通常的那种企业环境。

譬如说，团队的所有成员必须或多或少信任其他成员。任何人都不能拒绝向团队成员提供信息、资源或者数据。

除了信任外，团队成员必须愿意妥协。

应用软件的一个部分可能需要某些功能;而有些功能虽好，却没有必要。有时，为了在合理的时间内开发完成某部分，团队必须确定弃用没有必要的功能，留给将来的迭代过程去实现。

团队做出的一些决策也许不受整个公司的欢迎，“你不可能讨好每一个人”这句老话适用于此。因为团队中包括来自公司各部门的代表，公司必须信任团队这么做是出于好意，目的在于接受开发团队交付的那部分应用软件。不然，项目会很快陷入一片混乱。当然，这不是说公司不得不接受错误百出或者无法完成任务的应用软件。

之所以分成小部分来部署应用软件，就是为了更早发现及补救软件错误及使用问题，从而减少补救成本。

应用软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。

需要分布式开发的应用软件也不是非常适合使用敏捷编程技术。如果有些开发人员在英国、有些在美国，团队成员沟通起来不够迅速。分布式团队很难得到敏捷方法带来的所有好处。系统很快会陷入泥沼，你会发现大量时间用在了为团队的每个成员提供最新信息上。

敏捷编程技术还很难应用于每个部分一开始就要用的关键任务型应用软件。因为敏捷编程技术最适合小的迭代过程，那样整个应用软件不必立即开发出来。这种方法要求公司部署不完全的应用软件，以便征求整个公司的意见。目的在于，迅速补救任何实际缺陷及使用问题，而不是开发出一个完整的应用软件，等项目结束后才能测试。

有些公司本身也不适合使用敏捷编程技术，因为采用了集中的命令式管理方式，这遏制了敏捷编程发挥作用所需的有创意的方法。