什么样的团队才适合敏捷开发

并不是所有团队都适合适用敏捷开发这种方式，它并不是万金油。敏捷开发更适合需求不确定、变化大的项目团队，当在产品需求与开发等方面具有不确定性的情况下敏捷开发才会显得更有优势。

对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有20多年的历史。正如社交媒体圈子所说的那样，敏捷的声势与流行程度正在逐年见长。但敏捷是不是真的如坊间传闻的那样，是一个可以解决所有项目困境的使用广泛药？

当然不是！

敏捷的确是一种比较好的项目管理方法，敏捷也为项目负责人及其团队提供了一些独特的优势。

但我们之前将敏捷方法与传统的瀑布流方法进行了比较：敏捷解决了产品需求与开发等方面的不确定性，而瀑布流方法则试图将项目生命周期的各阶段，即启动、计划、执行和收尾等，按照严格的结构顺序进行组织。

传统的项目管理方法要求项目需求在项目开始之前就要收集并确定好。但敏捷方法则不同，敏捷更加实用和高效，要求产品负责人和关键利益相关者在产品开发过程中，参与构建和测试。 这样做能够大大节省时间。

为什么我们需要花上三个月的时间收集需求，再花上四个月的时间开发产品，到最后才发现开发的产品并不是客户真正想要的？为什么我们不能够开发一部分之后，展示给客户，将反馈整合到产品的开发中，然后不断重复这个过程并在更短的时间内构建客户想要的产品？简而言之，这就是敏捷的目标。

1、使用敏捷的优异条件是什么？

当我们无法确定产品的需求是什么时，较好使用敏捷方法。从收集用户故事开始就让产品负责人和Scrum团队参与进来能够让我们更高效地利用时间。用户故事是产品负责人希望开发的功能和特征的简要描述。

然后，根据这些软件功能，产品负责人和Scrum团队创建一个名为Product Backlog的待办事项列表。建立Product Backlog后，Scrum团队就会创建Sprint Backlog。客户所需的产品功能将会被安排在不同的Sprint中完成。因此，Sprint中是下一个版本中的功能，这么做的目的是为了每次都开发和部署产品的一小部分功能。

产品负责人和Scrum团队将召开每日站会来review开发进度。这种方法有助于解决产品或需求中的不确定问题。所以整个产品开发流程就是：开发部分功能—测试—收集反馈并继续开发—直至产品负责人对最终产品满意为止。

2、什么情况下敏捷不是优异选择？

敏捷并不总是较好的方法，例如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时，我们较好采用瀑布式开发方法。

数据中心的构建就是一个很好的例子。需求和任务开发顺序都很明确，无需做太多的规划。因此，如果按照前文所述的“部分开发-反馈-继续开发”这优异程进行显然是不切实际的。

所以，研发团队应该根据实际项目情况选择适合的开发方法，而不是听见什么好就用什么。