原则和优点

如果组织无法从敏捷方法中获得任何优点，则不存在使用它们的理由。通过列出敏捷原则可以最清楚地讨论其优点，如下所示：

快速、连续的交付

通过快速、连续的有用软件交付来获得客户满意度。这对您的组织是否重要？您的公司是否为希望开始用某个应用程序的 Beta 版本来吸引客户的新公司？您的应用程序是否将通过取代手动工作来节省内部开支？如果是，您可能会从敏捷开发中获得好处。

频繁的交付

可以按照数周而不是数月的间隔频繁地交付可工作的软件。如果您的应用程序是 Web 应用程序，您可能希望频繁推出更新以添加新功能，或者在获得客户的反馈时改进该应用程序。您不必担心繁重的版本控制任务，或者维护文件以跟踪哪个客户端具有哪个版本。如果版本发布涉及到客户端的更改或工作，您可能不希望频繁地做出更新。此外，频繁的迭代也许是个好主意，因为您知道自己可以在数周而不是数月内实现和发布更改。

工作软件

主要的进度度量标准是工作软件。已编写的文档和幻灯片演示并不足以满足大多数业务需求——您需要相关的工作软件。如果您从事的是咨询业，也许文档和幻灯片就足够了，但是部署工作软件最终是大多数组织的目标。

适应

在敏捷开发方法中，即使是后期的需求更改也是受欢迎的。很长时期以来，软件专业人员竭尽全力地避免或减少做出后期更改。然而，由于业务环境可能快速变化，软件需求也应当如此。

亲密无间，日常协作

业务人员和软件开发人员应该每天就解决方案交换意见并展开协作。后期需求更改可能来自于业务人员，并且开发人员应该实现那些需求。如果流程允许需求变更，则日常协作是必需的。对于实现接口或规范的应用程序，需求应该与指定的权威机构发布的规范文档相同。对该文档的更改不只是大事，这种更改根本就不应该出现。

积极主动、熟练人员

项目是围绕积极主动、熟练的受信任个人而构建的。（这确实应该是任何组织的基础。）无疑可以编写另一个专栏来讨论为什么某些人积极主动，而其他人则不是。您是否拥有用于激励和培训没有动力和不熟练的工作人员的资源，或者您是否需要确定已经充满动力并且高度熟练的可雇用人员？

自组织的团队

自组织的团队在大多数软件开发工作中还不是现实。他们需要大量的开发和管理方面的经验。自组织的团队将决定他们可以在某个迭代中实现需求的哪个部分，并将决定由谁负责该实现。团队成员的角色基于他们的兴趣和知识，而不是基于管理层的任命。组织涣散的团队将仅接受少量需求，并且产出成果也不多。为了正确地工作，团队必须了解他们在做什么，并且管理层必须信任他们。

应该参照其他团队而不是参照不明确的所需工作量估计来对自组织的团队进行评估。您的组织是否拥有熟练人员？作为团队成员或经理，您是否对完成的任何工作感到担心？

此时，您可能怀疑敏捷原则或自组织的团队在您的组织中是否有效.这无疑会导致下一个重要问题。

您的组织是否为敏捷流程做好了准备？

在具有某些特征的组织中，适应敏捷方法要更为容易。最初由 Cohen 等人指出的那些特征包括：

协商文化。开放和诚实的讨论在任何组织中都非常重要，但是如果您计划采用敏捷方法，则组织的各个部门必须良好沟通并且能够在必要时做出妥协。
组织中的工作的人员之间的信任。如果管理层不信任开发人员，或者开发人员不信任销售人员，您就麻烦了。
规模较小、能力级别较高的团队只需使用少量不必应付额外官僚作风的非常优秀的开发人员即可完成大量的工作。
促进团队成员之间快速沟通的环境。业务需求需要在眼下而不是在下周得到满足。您的组织文化需要是快速响应的文化，而不是在过程中一筹莫展的文化。
小型项目团队规模（少于 20 或 30 人）。随着规模的增长，面对面沟通将变得更加困难。

几年前，我曾经在一家公司工作，并在那里应用 IBM Rational® Unified Process (RUP®) 的简化版本。该流程的特征相当敏捷，虽然我们没有将其称之为敏捷。我谈到了迭代，如何使用它们，以及为什么它们非常好。由于某种原因，人们没有真正响应。后来一位项目经理解释说，因为需求不清楚，人们将“迭代”解释为反复不断地做同一件事情。他们以前的经验导致他们听不进我所说的内容。我认识到，无论您准备得多么充分，值得了解的是实现流程的人员，以及有历史经验的人员。

暂时还没有任何评论。