想象一下初创技术业务，创始人正在努力开拓可持续发展的商业利基市场。该部门正在快速变化，他们必须快速开发用户准备支付的服务。这很棘手！
他们只能通过市场调查发现这么多，所以他们需要进行实验。这意味着尝试各种不同的产品。他们需要逐步学习并尝试改进产品，直到他们开发出真正有效的解决方案。
您可能会看到许多与工作相关的项目 - 特别是涉及复杂，快速移动情况的项目 - 类似于这种情况。您可以致力于一个可交付成果或解决一个问题，但随后需要改变并修改您的计划。
如果您使用传统的项目管理方法，这些修订将导致错过最后期限，成本膨胀和工作量增加。而且，在最糟糕的情况下，您可以发现在项目过程中情况发生了很大变化，最终产品在最终交付时与原要求不再具有相关性。
敏捷项目管理是一种帮助您应对这些挑战的方法。在本文中，我们将描述敏捷是什么，我们将解释为什么它是有益的。
什么是敏捷项目管理？
敏捷项目管理的要素已经存在了几十年。然而，两个事件有助于为该方法奠定基础。
首先，1986年，Hirotaka Takeuchi 和 Ikujiro Nonaka 在哈佛商业评论中发表了一篇名为“ 新产品开发游戏 ”的文章。在其中，作者概述了一种开发类似橄榄球比赛的产品的新方法。
他们设想了一种项目管理方法，就像在球场上一样，团队成员通过不断重新评估情况并做出相应的响应来实现他们的目标。因此，项目将不断发展，但会导致产品更加充分地满足客户的需求。
第二次活动发生在2001年，当时一群软件和项目专家开会讨论他们最成功的项目的共同点。他们创建了敏捷项目宣言，其中概述了支持敏捷项目管理的价值观和原则。
敏捷项目管理以Takeuchi和Nonaka的产品开发方法为基础，并融合了敏捷项目宣言中概述的价值观和原则。
敏捷与传统项目管理
让我们将敏捷项目管理与传统项目管理进行比较，以显示这些方法的不同之处。
| 敏捷项目管理 | 传统项目管理 |
|---|---|
| 团队是自我导向的，只要他们遵循商定的规则，他们可以自由选择完成可交付成果。 | 团队通常由项目经理严格控制。他们按照一开始就商定的详细时间表工作。 |
| 随着需求和用途的出现，项目要求在流程中得到发展。这可能意味着最终结果与开头设想的结果不同。 | 在项目开始之前确定项目要求。这有时会导致“范围蔓延”，因为利益相关者经常要求的不仅仅是他们需要的，“以防万一”。 |
| 用户测试和客户反馈不断发生。从错误中学习，实施反馈和发展可交付成果很容易。但是，为此所需的持续测试是劳动密集型的，如果用户没有参与，则可能难以管理。 | 在设计和实施所有内容时，用户测试和客户反馈将在项目结束时进行。这可能意味着问题可能在发布后出现，有时会导致昂贵的修复，甚至是公众召回。 |
| 团队不断评估其产品或项目的范围和方向。这意味着他们可以在流程中随时改变方向，以确保他们的产品满足不断变化的需求。但是，由于这一点，在开始时编写业务案例可能很困难，因为最终结果尚不完全清楚。 | 团队致力于最终产品，可在项目开始后的某些时间（通常是数月或数年）交付。有时，最终产品或项目不再相关，因为业务或客户需求已发生变化。 |
最终，传统的项目管理通常在稳定的环境中最佳，在固定的环境中，固定预算需要定义的可交付成果。在最终产品不确定或环境变化迅速的地方，敏捷通常是最好的。
关于流程
敏捷项目管理在其使用的角色和事件中也与其他项目管理技术不同。我们在下面概述了这些。
“Scrums”和“Sprint”
敏捷项目管理的核心是“Scrum”框架。这使用特定角色，事件，会议和增量来在特定时间范围内（例如，在30天内）提供可用产品。
该框架涉及三个关键角色：
1.产品所有者是正在开发的产品的专家。他或她代表关键的利益相关者，客户和最终用户，并负责确定项目的优先顺序并获得资金。
产品所有者描述了人们将如何使用最终产品，传达客户需求并帮助团队开发正确的产品。他或她的专业知识也有助于对抗范围蔓延。
2. Scrum master负责管理流程。这个人解决了问题，因此产品所有者可以推动开发，并最大化投资回报。Scrum master确保每个sprint都是独立的，并且不会占用额外的目标。
Scrum master负责监督沟通，以便利益相关者和团队成员可以轻松了解已取得的进展。
该团队是负责将需求转化为功能的专业团队。
团队将通过“冲刺”来处理每个项目 - 短期工作，在结束时提供完整，测试，记录和运行的产品。
每个sprint都以sprint计划开始 会议。在这里，团队成员决定他们可以在约定的时间范围内交付什么。他们定义目标并分配任务职责。
在冲刺期间，团队成员专注于实现他们定义的目标。他们将每天开会，进行15分钟的会议 报告进展情况，讨论他们当天的工作，并谈谈他们所面临的任何挑战。（鼓励会议参与者站起来，以便会议快速有效。）这些会议是日常检查过程的重要组成部分。
团队可以根据具体项目的工作原理自由改变他们的方法。
报告
在敏捷项目管理中，有定期报告进度的机会。
除了每日scrum会议之外，团队成员还会在每次sprint之后与产品所有者和关键利益相关者会面，以呈现sprint交付项目。在这次会议中，该小组共同决定他们应该为下一个sprint改变什么。
在此之后，scrum master（有时是产品所有者）举行回顾会议，在会议中他们查看他们在上一个sprint中使用的过程，并决定他们可以为下一个sprint做些什么。