所有敏捷软件项目都有目标：项目需要交付什么，何时需要交付以及在什么预算范围内交付。但要管理这三个约束可能是一个复杂的高度度行为。因此，我们可以从已有数十年历史的规划铁三角中汲取灵感，了解平衡不同的变量如何帮助敏捷软件团队实现敏捷项目管理的必杀技。
传统铁三角
铁三角项目模型的某些约束被认为是“钢铁般的”，因为你无法在不影响其他约束的情况下改变一个约束最初的铁三角项目管理是马丁·巴恩斯博士在1969年提出的，遵循瀑布式的产品开发方法：范围是固定的，而资源和时间是可变的。对于软件团队来说，这意味着团队通过定义产品要求来确定项目的范围（工作项列表）来启动项目。资源和时间表是可变的，根据固定范围进行估计。
- 范围是交付有效产品所要做的工作，例如特性和功能。
- 资源包括预算和致力于交付和执行的团队成员。
- 时间是团队向市场交付产品的时间，例如发布和里程碑。
铁三角项目管理的目的是为产品团队提供必要的信息，以便做出有助于业务的权衡。例如，如果团队面临固定范围，他们可能在项目进行到一半时才意识到赶不上发布日期。他们只能控制下面的几个变量：1) 时间 - 他们可以接受发布日期推迟或 2) 资源 - 他们可以为项目添加更多人员，但这将增加成本。随着 21 世纪软件开发的发展，对更好的协作和快速响应客户反馈的能力的需求变得至关重要，敏捷方法顺势诞生。
将铁三角映射到敏捷
如果您的团队采用瀑布式项目管理或是刚刚接触敏捷开发，那么切记，固定和估计之间是有区别的。与瀑布式开发不同，敏捷项目有固定的时间表和资源，而范围各不相同。虽然在敏捷开发中，项目的范围可能会发生变化，但团队会提交进行固定的工作迭代：如果使用 Scrum 框架和 WIP 限制，则是冲刺；如果使用看板框架，则是 WIP 限制。在整个开发过程中保持团队固定也是一种最佳实践。通过使团队在产品或项目上保持一致，他们可以通过建立信任和连续性来提高效率。
在敏捷开发中，范围的概念是相同的：要构建和交付什么样的软件。但是，敏捷专注于高层次的需求，而不是试图在前期提出深入而详细的需求。项目范围由产品经理在 Jira 之类的工具中定期管理和梳理（确定优先级）。产品经理根据来自各种渠道（市场状况、客户反馈、竞争等）的敏捷定性和定量反馈，决定在下一个冲刺中应该完成哪些工作。而且，由于资源和时间是固定的，开发团队更容易对市场变化做出反应，并更快地为客户提供价值。这种约束的透明性使团队能够诚实地保持一致、快速的发布节奏，而这正是敏捷开发的关键要素；通过铁三角的视角来看待项目，团队能够在不放弃计划的情况下进行调整。
长期敏捷规划和铁三角项目管理
随着项目规模扩大，需要更多团队，时间范围也越来越长。因此，尽管范围各不相同，但固定资源和时间的概念并不是所有敏捷项目的有效方法。长期敏捷规划需要一个更灵活的铁三角，使团队能够提前计划并确保他们实现业务目标。例如，想想精益创业运动，以及最低可行产品（MVP）的概念。顾名思义，MVP 是为客户创造价值的一小部分功能（范围）。要获得这个 MVP，团队可能需要坚持固定的范围，即功能的数量，而时间是他们唯一的变量（例如你无法在没有某些功能的情况下发布，因此发布日期被推迟了）。只有在启动 MVP 之后，团队才会切换到可变范围。
无论瀑布式开发和敏捷开发有什么区别，在使用铁三角方法时，都没有对错之分。它可以帮助您做出最佳决策和权衡，从而实现您的业务目标。时间线等工具可直观显示计划的各个组成部分（范围、人员和时间），从而帮助团队进行实时规划。使用团队在 Jira 中的现有数据，您可以轻松地利用范围、团队和时间来规划您的下一次产品发布。