所有的敏捷项目都应有一个整体工作目标：项目需要交付什么，何时需要交付以及在什么预算范围内交付。然而如何管理这三块内容是一个复杂的问题。但我们可以从几十年前就已经出现的理论：“项目铁三角——范围、成本、资源”中汲取经验，以平衡不同的变量，帮助敏捷团队实现更好的项目管理。
一、传统项目铁三角
传统项目管理下的“铁三角”，指的是三者中任意一方的变动都会对其他二者产生影响。
项目管理的目标是平衡三者之间的关系，使其达到最佳的效果。铁三角最早是由 Martin Barnes 博士在 1969 年提出，它遵循的是瀑布模型方法：范围是固定的，资源和时间是可变的。对于软件来说，这意味着团队会通过定义产品需求来确定项目范围（工作项列表），然后进行研发工作，而资源和时间是可变的，并且根据固定的工作范围进行估算。
铁三角的相互影响：
铁三角的目的是为产品团队提供必要的信息，以便做出有助于业务的权衡。例如，如果团队面临固定的范围时，可能会在项目进行到一半时意识到产品无法按时交付。这时团队可以调整的变量是：
- 时间 – 团队可以接受较晚的发布日期
- 资源 – 团队可以为项目添加更多成员，这将增加成本
随着软件开发在 21 世纪的发展，更好的协作和快速响应客户反馈的能力变得至关重要，因此，敏捷方法诞生了。
二、将项目铁三角应用到敏捷
如果你的团队采用的是瀑布开发模型或对敏捷开发并不了解，那么弄清楚固定内容和估算内容之间的区别就非常重要。
因为与瀑布式开发不同，敏捷项目具有固定的时间表和资源配置，而范围则各不相同。虽然项目的范围在敏捷开发中可能会发生变化，但团队通常都有固定的迭代周期：如果使用的是 Scrum，则会应用迭代；如果使用的是 Kanban，则应用 WIP 限制。在整个开发过程中，团队整体保持固定也是一种最佳实践方法。通过使团队在产品或项目上保持一致，成员会在建立信任和持续性方面变得更有效率。
在敏捷开发中，范围的概念是相同的：构建和交付什么产品。与瀑布方法不同的是，敏捷专注于高层次的需求，而不是试图预先提出深入而详细的需求。产品负责人会通过 PingCode 这类工具定期管理和整理项目范围（比如确定优先级），整理来自各种渠道（市场状况、客户反馈、竞品等）的需求，进行定性和定量的分析来决定下一个迭代应该完成哪些工作。
而且由于资源和时间是固定的，开发团队更容易对市场变化做出反应并更快地为客户提供价值。这种透明的关系使团队对业务建立起一致的认知，并且时刻保持快速的发布节奏，这正是敏捷开发状态下的铁三角能带来的关键影响；应用铁三角的方式分析项目，团队面对不同问题能够灵活地进行调整。
三、长期敏捷规划和铁三角
随着项目变得越来越大，会需要更多的团队，时间也越来越长。因此，范围不同，但固定资源和时间的概念并不是适用于所有敏捷项目的有效方法。长期的敏捷计划需要一个更灵活的铁三角实践，让团队能够提前计划并确保他们实现业务目标。例如，精益创业的方法和最小可行产品 (MVP) 的概念。根据定义，MVP 是提供客户总价值中的一小组功能范围。为了交付 MVP，功能数量是团队固定的范围，时间是团队唯一的变量，且只有在 MVP 成功完成之后，团队才会切换成可变范围。
无论瀑布式开发和敏捷开发有什么区别，使用铁三角时，没有对错之分。这种分析方法可以帮助团队做出最佳决策和权衡，以实现业务目标。在 PingCode 中，像产品路线图这样的功能可以有效地可视化项目计划，如范围、资源和时间，来帮助团队实时规划和执行。
