对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有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的迭代故事板可以做到，在每日站会的时候迭代负责人可以拖动需求看板来改变需求状态及时更新需求进度。
积极参与的产品负责人
产品负责人的实时反馈是敏捷成功的关键。这样不仅可以取代繁琐的需求文档，还能确保清晰的传达产品负责人的需求。产品负责人参与并为开发团队提供持续的反馈，能使团队更快地开发出正确的产品。产品负责人应该参加每天站会，并表达自己的期望、喜好和不满。这样能确保开发团队开发出产品负责人想要的产品。
团队工作与协作——积极主动的团队成员
社会责任是敏捷方法的关键驱动因素。敏捷希望创建一个能在一定程度上实现自我管理的团队环境。敏捷教练希望创建一个积极并表现出主动性的团队。如果团队成员没能赶上进度或积极参与，那么敏捷教练希望其他团队成员能够互相帮助、鼓励和激励。敏捷教练将以身作则，奠定团队中相互鼓励和问责的协作基调。
从失败中学习的意愿
快速试错更快速地从失败中学习。原型设计和反馈是敏捷的重要工具。传统的开发方式试图在项目启动前描述所有的需求，这么做会浪费大量时间，尤其是在开发新产品时。所以一旦有了想法就应该立刻进行开发，即使当前的产品并非产品负责人想要的。这样做的目的是要通过不断的反馈来调整产品方向并继续开发。
管理层支持敏捷框架并具备团队赋权的企业文化
敏捷可以为企业带来文化和期望层面的转变，因为它鼓励团队赋权，让团队负责做出决策并承担相应的风险。与之相反的是，在传统的开发团队中，项目经理需要提供明确的方向，而在敏捷开发中，敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由，仅提供能让团队快速成长的指导和方向，而不是控制团队的每一步行动。
拥抱敏捷使人兴奋。因为它让项目负责人多了一种项目管理方法，来解决项目进度中的各类问题。但与其他方法一样，敏捷的应用也存在限制，也有其不适合的任务。总而言之，敏捷为项目经理提供了更多的选择，让他们有可能更好地管理项目。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
