传统的铁三角框架概念，即范围、成本和日程在软件开发团队中根深蒂固;在敏捷开发团队中，团队成员希望达到一组目标，而经理和高管们去按传统的铁三角框架目标去考察他们。如何在敏捷开发中有效的进行成效评估?

　　以往的软件开发团队都被认为受到软件“铁三角”的限制。三角形的三个边分别是“范围”、“日程”和“成本”。因为敏捷团队非常强调质量，而质量被认为是坐落在三角形的中间。任何项目想要成功，都希望操控某一个维度，同时保持其他维度相对不变。很多敏捷团队会变更范围，并监控成本、日程和质量。

　　Jim Highsmith认为这个铁三角大大限制了敏捷团队的灵活性，他建议使用另一种“敏捷三角形”。

　　现在有很多敏捷开发团队陷于两难境地。一方面，人们告诉他们要敏捷、灵活、学会自我调整，另一方面，人们又告诉他们要遵从原有的传统铁三角框架，即范围、成本和日程。本质上，这等于告诉他们“要在一个很小的盒子里面保持灵活”。敏捷团队尽力希望达到一组目标，而经理和高管们去按另一组目标去考察他们。

　　Jim建议“敏捷三角形”应该包括以下三个顶点：

　　1、价值——当前要发布的产品对客户的价值。

　　2、质量——通过可靠、适应性强的产品为客户持续不断地交付价值。

　　3、约束——传统的范围、日程和成本。

　　在他看来，尽管约束是很重要的项目参数，但并不是项目的目标。他补充道：

　　价值和质量才是敏捷开发的目标，而随着项目的进展，约束会需要调整，以提升客户的价值。日程也许还是固定的约束，但是范围就得调整，以在日程约束之内交付最高的价值。

　　Jim同时认为：开发过程的焦点，应该放在可发布的产品上，而不是可执行的范围。敏捷开发团队应该提出这样的问题：“产品今天能够进行发布吗?”这有助于将战略重点放在产品上，而不是总盯着细节需求不放。

　　他承认：价值和质量相对于与成本和日程更难以衡量，然而，注意力还是应该放在度量价值上，要度量通过可发布的产品而交付的价值，而不是想着怎么精确计算不那么重要的东西，比如“敏捷三角形”中的约束因素。

　　相对于精确度量不那么重要的东西，能够模糊度量非常重要的因素，这要有价值得多。

　　因此，在Jim看来，敏捷团队应该将关注点放在可发布的产品上，而不是被传统铁三角限制住。传统铁三角的三个顶点转变为“敏捷三角形”的一个顶点，被称为约束。质量和价值这两个顶点定义了目标，对于项目干系人来说，它们才是最重要的东西，因而更值得关注。