对从事项目管理的人员来讲，敏捷已经成为一场席卷全国的风潮。但敏捷并非什么新事物，它已经有20多年的历史。正如社交媒体圈子所说的那样，敏捷的声势与流行程度正在逐年见长。但敏捷是否是真的如坊间传闻的那样，是一个能够解决全部项目困境的万能药？
固然不是！但敏捷的确是一种比较好的项目管理方法。敏捷为项目负责人及其团队提供了一些独特的优点。
咱们以前将敏捷方法与传统的瀑布流方法进行了比较。敏捷这种软件开发领域的项目管理办法，在过去数年有着强劲的发展势头。它解决了产品需求与开发等方面的不肯定性。与之相较的瀑布流方法则试图将项目生命周期的各阶段，即启动、计划、执行和收尾等，按照严格的结构顺序进行组织。markdown
什么是敏捷?
要确切定义何为敏捷很是困难。不一样的人可能会给出不一样的答案。敏捷这个大范畴内包含下面几个体系，如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。
敏捷将项目规划变成了一个贯穿整个项目生命周期的迭代过程。“fail-fast”这个术语体现了对迭代的渴望，即经过先将开发出的不完美的产品提供给客户使用，以收集客户的反馈。
客户的反馈相当重要。传统的项目管理方法要求项目需求在项目开始以前就要收集并肯定好。但敏捷方法则不一样，敏捷更加实用和高效，要求产品负责人和关键利益相关者在产品开发过程当中，参与构建和测试。
这样作可以大大节省时间。为何咱们须要花上三个月的时间收集需求，再花上四个月的时间开发产品，到最后才发现开发的产品并非客户真正想要的？为何咱们不可以开发一部分以后，展现给客户，将反馈整合到产品的开发中，而后不断重复这个过程并在更短的时间内构建客户想要的产品？简而言之，这就是敏捷的目标。框架
使用敏捷的最佳条件是什么？
当咱们没法肯定产品的需求是什么时，最好使用敏捷方法。从收集用户故事开始就让产品负责人和Scrum团队参与进来可以让咱们更高效地利用时间。用户故事是产品负责人但愿开发的功能和特征的简要描述。
而后，根据这些软件功能，产品负责人和Scrum团队建立一个名为Product Backlog的待办事项列表。创建Product Backlog后，Scrum团队就会建立Sprint Backlog。客户所需的产品功能将会被安排在不一样的Sprint中完成。所以，Sprint中是下一个版本中的功能，这么作的目的是为了每次都开发和部署产品的一小部分功能。工具
产品负责人和Scrum团队将召开每日站会来review开发进度。这种方法有助于解决产品或需求中的不肯定问题。因此整个产品开发流程就是：开发部分功能—测试—收集反馈并继续开发—直至产品负责人对最终产品满意为止。学习
什么状况下敏捷不是最佳选择？
敏捷并不老是最好的方法，例如需求基本是肯定的。当项目具有可靠的历史记录做为开发基准时，咱们最好采用瀑布式开发方法。
数据中心的构建就是一个很好的例子。需求和任务开发顺序都很明确，无需作太多的规划。所以，若是按照前文所述的“部分开发-反馈-继续开发”这一流程进行显然是不切实际的。测试
那么，什么时候步入敏捷？
如今，咱们已经清楚了解了敏捷的定义，适用条件及在什么状况下最好使用传统的开发方法。下面，让咱们了解一下在什么状况下最好使用敏捷。具体状况可能比较多，仅在下文中列举几类主要状况：设计
- 产品需求不肯定时
这种状况下，敏捷可使项目更快启动，并让产品负责人参与到开发过程当中。用敏捷的方式，咱们就没必要在不肯定客户是否会满意的状况下花六个月的时间记录产品需求。产品负责人能够在开发新产品功能时，根据他或她的反馈做为开发过程的一部分，以最快的速度将功能呈现出来，从而确保产品能够更快交付。blog
- 敏捷是软件开发项目的最佳选择
由于软件开发过程自己就容许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其余功能。Sprint则容许开发团队单独测试和部署这些功能，从而确保开发效率。生命周期
- 协做的团队可从敏捷方法中受益（每日站会）
敏捷方法的关键是天天的站立会议。会议上，团队能够讨论当前的开发进度、遇到的问题和来自产品负责人的反馈。若是有人可以负责召开这些会议并将会议结果更新到敏捷看板上就行了。由于协做的团队成员能够随时访问和更新故事板，这将有助于团队协做的顺利开展。项目管理
这一点能够经过Worktile的迭代故事板能够作到，在每日站会的时候迭代负责人能够拖动需求看板来改变需求状态及时更新需求进度。开发
- 积极参与的产品负责人
产品负责人的实时反馈是敏捷成功的关键。这样不只能够取代繁琐的需求文档，还能确保清晰的传达产品负责人的需求。产品负责人参与并为开发团队提供持续的反馈，能使团队更快地开发出正确的产品。产品负责人应该参加天天站会，并表达本身的指望、喜爱和不满。这样能确保开发团队开发出产品负责人想要的产品。
- 团队工做与协做——积极主动的团队成员
社会责任是敏捷方法的关键驱动因素。敏捷但愿建立一个能在必定程度上实现自我管理的团队环境。敏捷教练但愿建立一个积极并表现出主动性的团队。若是团队成员没能遇上进度或积极参与，那么敏捷教练但愿其余团队成员可以互相帮助、鼓励和激励。敏捷教练将以身做则，奠基团队中相互鼓励和问责的协做基调。
- 从失败中学习的意愿
快速试错更快速地从失败中学习。原型设计和反馈是敏捷的重要工具。传统的开发方式试图在项目启动前描述全部的需求，这么作会浪费大量时间，尤为是在开发新产品时。因此一旦有了想法就应该马上进行开发，即便当前的产品并不是产品负责人想要的。这样作的目的是要经过不断的反馈来调整产品方向并继续开发。
- 管理层支持敏捷框架并具有团队赋权的企业文化
敏捷能够为企业带来文化和指望层面的转变，由于它鼓励团队赋权，让团队负责作出决策并承担相应的风险。与之相反的是，在传统的开发团队中，项目经理须要提供明确的方向，而在敏捷开发中，敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由，仅提供能让团队快速成长的指导和方向，而不是控制团队的每一步行动。
拥抱敏捷令人兴奋。由于它让项目负责人多了一种项目管理方法，来解决项目进度中的各种问题。但与其余方法同样，敏捷的应用也存在限制，也有其不适合的任务。总而言之，敏捷为项目经理提供了更多的选择，让他们有可能更好地管理项目。
项目管理工具让项目经理能够更好地完成本职工做，正确的项目管理工具让咱们可以在预算范围内，按时保质地完成工做。Worktile在这方面能够发挥巨大做用。做为一个项目管理工具，它为您提供了实时规划、监控和报告的方法。
文章来源：Worktile敏捷博客
欢迎访问交流更多关于技术及协做的问题。
文章转载请注明出处。