假设一个固定交付的项目，这个开发项目是构建一个应用程序，时间表是一年。在项目进行期间可能出现什么问题？
一个固定交付的项目意味着它具有固定的范围、固定的时间表和固定的成本。
长期以来，传统的项目管理方式侧重于由项目范围、预算和时间表组成的“三重约束”，这也被称为铁三角。任何项目的“三重约束”都保持着彼此之间的平衡，任何一项发生变化就可能导致其他项发生变化。
其实，三重约束是错误的，主要有两个原因：
第一，三者之间的关系会发生变化，不会一直维持着平衡状态。
第二，过于关注“三重约束”反而容易忽略质量等其他重要约束。
“三重约束”只关注了项目的交付交互，而忽略了项目的价值交付。如果我们所提供的解决方案不能增加价值，那项目按时、按预算交付的意义是什么呢？
敏捷开发是一种以迭代、协作和快速响应变化为核心的软件开发方法。它强调灵活性、适应性和持续交付，以满足客户需求并提高质量的软件产品。
客户本身可能并不知道自己想要什么，也不知道项目团队采用何种方式交付，因此在交付方法中保持灵活性至关重要，利用交付周期、获得反馈并不断改进工作方式。
传统的项目管理方式对于一个固定的交付项目其实没有那么适用。
首先，通过对构建范围的时间和成本进行估计，但这估计结果仍存在着偏差。根据不确定性锥，早期估计结果可能会比实际交付所需的偏差多达4倍。即使在需求完成后，估计结果也可能比交付所需的费用低 1.5 倍。
其次，一年的开发周期对于一个技术项目来说是很长的时间。即使我们对项目有固定的要求，并保证不会有任何变化，但如此长的开发周期仍会出现不能预料的变动，如对所写内容的理解将发生变化。潜在的客户需求和优先事项将发生变化。
最后，使用阶段的传统方法，我们通常无法确定能否在分配的时间内交付了所有预算工作，这会导致将工作从一个阶段推到未来阶段。
其实，无论使用传统还是敏捷交付方法，交付固定项目都是有风险的。但不得不承认在固定交付项目中使用敏捷方法可能会有一些优势。
在项目进行过程中，项目需求随时会发生变化。敏捷开发方式能灵活应对这些变化，让团队快速响应新的反馈和需求，以确保最终产品满足客户的需求。
敏捷开发方式强调定期交付产品的工作增量，而不是等到项目接近尾声时才爆炸式交付。即使产品的所有功能尚未完成，但定期交付的产品能让客户尽早使用并从中受益。
使用迭代可以让团队更好地预测未来。在每 2 周迭代 （Sprint） 结束时，团队可以使用平均吞吐量和剩余积压工作来预测交付整个项目所需的时间。在使用阶段和按顺序交付时，这种级别的可预测性是不可能的。
使用限时迭代和优先产品待办事项列表为团队的有效性提供了透明度。这使得进度跟踪更加有效，并加快了问题和风险的识别和解决。
敏捷方法促进了对产品的持续反馈以及团队反思和回顾的时间。对产品的反馈会带来更高质量、更有效的解决方案。团队反思和回顾推动了团队流程的改进，从而使团队合作更加有效和愉快。
敏捷的增量交付方法允许及早识别和缓解项目风险。通过提供较小的增量，可以在问题升级之前及时解决问题。
敏捷开发能够轻松适应需求的变化，但前提是必须与客户仔细协商。
假设固定范围与交付时间表和预算完全匹配，那范围的增加会破坏平衡。但如果客户了解范围是固定的，每次对范围的任何更改是用另一个范围所替换而不是增加，则这仍然有效。
举个例子，一个表示范围的存储桶。一个存储桶的容量是需要交付的确切范围量，如果进行添加就意味着必须删除相同大小的其他内容。
运用敏捷开发方式需要拥有一个完全敬业的团队，且在项目的整个生命周期中保持团结。
但如果人员成本的估算基于为特定任务在项目内外轮换的专家，就会发现的人员成本估算低于专门团队的人力成本。
当客户和开发团队之间关系牢固，每个人都在寻求双赢的解决方案时，敏捷效果最好。
然而，在典型的固定交付项目中，合同往往是输赢的。如果交付团队能够比计划更快地交付，即使他们没有为客户提供真正需要的东西，他们仍会获得更多利润。
因此，在客户获得实际需要的一切和交付团队估计之间通常存在紧张关系。
在固定交付的项目中使用敏捷开发方式是一把双刃剑。
虽然敏捷开发方式具有适应性、早期价值交付等好处，但范围、预算管理以及与合同相关的问题等挑战可能成为项目进行过程中的重大问题。
但我们不得不承认，敏捷开发方式更加人性化。