对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有20多年的历史。正如社交媒体圈子所说的那样，敏捷的声势与流行程度正在逐年见长。但敏捷是不是真的如坊间传闻的那样，是一个可以解决所有项目困境的万能药？
当然不是！但敏捷的确是一种比较好的项目管理方法。敏捷为项目负责人及其团队提供了一些独特的优势。
我们之前将敏捷方法与传统的瀑布流方法进行了比较。敏捷这种软件开发领域的项目管理办法，在过去数年有着强劲的发展势头。它解决了产品需求与开发等方面的不确定性。与之相较的瀑布流方法则试图将项目生命周期的各阶段，即启动、计划、执行和收尾等，按照严格的结构顺序进行组织。
要确切定义何为敏捷非常困难。不同的人可能会给出不同的答案。敏捷这个大范畴内包含下面几个体系，如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。
敏捷将项目规划变成了一个贯穿整个项目生命周期的迭代过程。“fail-fast”这个术语体现了对迭代的渴望，即通过先将开发出的不完美的产品提供给客户使用，以收集客户的反馈。
客户的反馈至关重要。传统的项目管理方法要求项目需求在项目开始之前就要收集并确定好。但敏捷方法则不同，敏捷更加实用和高效，要求产品负责人和关键利益相关者在产品开发过程中，参与构建和测试。
这样做能够大大节省时间。为什么我们需要花上三个月的时间收集需求，再花上四个月的时间开发产品，到最后才发现开发的产品并不是客户真正想要的？为什么我们不能够开发一部分之后，展示给客户，将反馈整合到产品的开发中，然后不断重复这个过程并在更短的时间内构建客户想要的产品？简而言之，这就是敏捷的目标。
当我们无法确定产品的需求是什么时，最好使用敏捷方法。从收集用户故事开始就让产品负责人和Scrum团队参与进来能够让我们更高效地利用时间。用户故事是产品负责人希望开发的功能和特征的简要描述。
然后，根据这些软件功能，产品负责人和Scrum团队创建一个名为Product Backlog的待办事项列表。建立Product Backlog后，Scrum团队就会创建Sprint Backlog。客户所需的产品功能将会被安排在不同的Sprint中完成。因此，Sprint中是下一个版本中的功能，这么做的目的是为了每次都开发和部署产品的一小部分功能。
产品负责人和Scrum团队将召开每日站会来review开发进度。这种方法有助于解决产品或需求中的不确定问题。所以整个产品开发流程就是：开发部分功能—测试—收集反馈并继续开发—直至产品负责人对最终产品满意为止。
什么情况下敏捷不是最佳选择？敏捷并不总是最好的方法，例如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时，我们最好采用瀑布式开发方法。
数据中心的构建就是一个很好的例子。需求和任务开发顺序都很明确，无需做太多的规划。因此，如果按照前文所述的“部分开发-反馈-继续开发”这一流程进行显然是不切实际的。
现在，我们已经清楚了解了敏捷的定义，适用条件及在什么情况下最好使用传统的开发方法。下面，让我们了解一下在什么情况下最好使用敏捷。具体情况可能比较多，仅在下文中列举几类主要情况：
产品需求不确定时
这种情况下，敏捷可以使项目更快启动，并让产品负责人参与到开发过程中。用敏捷的方式，我们就不必在不确定客户是否会满意的情况下花六个月的时间记录产品需求。产品负责人可以在开发新产品功能时，根据他或她的反馈作为开发过程的一部分，以最快的速度将功能呈现出来，从而确保产品可以更快交付。
敏捷是软件开发项目的最佳选择
因为软件开发过程本身就允许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其他功能。Sprint则允许开发团队单独测试和部署这些功能，从而确保开发效率。
协作的团队可从敏捷方法中受益（每日站会）
敏捷方法的关键是每天的站立会议。会议上，团队可以讨论当前的开发进度、遇到的问题和来自产品负责人的反馈。如果有人能够负责召开这些会议并将会议结果更新到敏捷看板上就好了。因为协作的团队成员可以随时访问和更新故事板，这将有助于团队协作的顺利开展。
这一点可以通过Worktile的迭代故事板可以做到，在每日站会的时候迭代负责人可以拖动需求看板来改变需求状态及时更新需求进度。
积极参与的产品负责人