项目有多种形式，也有多种实施方式。项目团队需要认识到相关特征和方案，以选择最可能使项目成功的方法。
敏捷实践指南涉及四种生命周期：
1、预测型生命周期
这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。强调根据部门划分的，有效的，顺序的工作；不会再结束前交付商业价值；遇到变更，产生意想不到的成本。
2、迭代型生命周期
这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。项目复杂性高，变更频繁，项目氛围受到相关方对所需最终产品的不同观点支配时，采用迭代生命周期更有优势。
3、增量型生命周期
这种方法向客户提供各个已完成的， 可能立即使用的可交付成果。少量可交付成果的频分交付，确保客户能尽早获得价值。
4、敏捷生命周期
这种方法既有迭代，也有增量，便于完善工作，频繁交付。增量交付会发现隐藏或误解的需求。敏捷生命周期是符合《敏捷宣言》原则的周期。特别是，客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果，是衡量进展的主要尺度。 为了适应更频繁的变更，和更频繁地交付项目价值，敏捷生命周期结合了迭代和增量方法。
-
基于迭代的敏捷
团队以迭代相等持续时间的时间盒形式交付完整的功能；团队不会同时完成所有迭代工作。
-
基于流程的敏捷
从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理各列的进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
四种生命周期的特征比较如下表所示：
迭代 vs 增量
迭代”和“增量”是敏捷软件开发中的两个重要概念，要想比较彻底地理解“迭代”和“增量”，我们将其对比一下。
迭代，就是在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程；
而增量，则是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。
二者的对比如下图所示：
敏捷适用性筛选器：
有各种评估模型可用来帮助确定使用敏捷方法的适合性或差距。这些模型评估项目和具有适应性和适用性的组织因素，然后提供分数表明一致性或潜在风险领域。《敏捷实践指南》附件 X3P125-138综合提供了各种流行的评估模型，它们可用作敏捷适用性筛选器。
混合生命周期：
对于整个项目，没有必要使用单一的方法。为达到特定的目标，项目经常要结合不同的生命周期要素。预测、迭代、增量或敏捷方法的组合就是一种混合方法。项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。项目采用敏捷方法亦或预测法，都无关紧要。 要提出的问题是：“我们怎样做才能最成功？”当团队创造价值时，是否需要反馈？如果需要，增量方法将会有所帮助。在探讨各种想法时，是否需要管理风险？如果需要，迭代方法或敏捷方法将会有所帮助。 当组织无法交付中间价值时，敏捷方法可能不是很有用。这样没有问题，但为了敏捷而敏捷并不是目标。关键在于，要选择一个对项目、风险和文化管理有用的生命周期或生命周期的组合。 关乎频繁向客户交付。而这种交付要给团队带来反馈，团队利用上述反馈规划并重新规划下一部分的工作。
许多团队无法在一夜之间切换到敏捷工作方式。对于那些已经习惯于预测型环境、并在其中获得成功的人士，敏捷技术的观感截然不同。组织越大，活动部件越多，转换需要的时间就越长。因此，计划一个渐进的过渡是有意义的。
渐进的过渡涉及到要增加更多的迭代技术，以便改进学习，加强团队和相关方的一致性。之后， 还要考虑增加更多的增量技术，以加快对发起人的价值和投资回报。上述各种方法的组合被视为一种混合方法。
在一个风险不大、具有中低程度不确定性的项目中尝试这些新技术。在组织成功地使用混合方法后，再尝试更复杂的项目，这些项目需要增加更多的技术。这是一种根据组织的情况、特定的风险，以及团队适应并接受变革的就绪情况而调整的渐进混合过渡。
混合敏捷方法：
敏捷团队很少将其实践局限于一种敏捷方法。每个项目背景都有其各自的独特性，比如团队成员技能和背景的不同组合；开发中的产品的各个组成部分；以及工作环境中的年龄、规模、关键性、复杂性和监管制约因素等。敏捷框架并不是针对团队定制的。为了定期交付价值，团队可能需要对实践进行裁剪。通常，团队都会实践各自特殊的敏捷组合，即便他们使用一个特定的框架作为起点也不例外。
协调方法 ：
裁剪敏捷框架的一个例子是，一个广泛使用的常见协调方法涉及到协调使用 Scrum框架、看板方法和极限编程 (XP) 方法的要素。Scrum为产品待办事项列表、产品负责人、Scrum 主管以及跨职能开发团队的使用提供指导，包括冲刺计划、每日例会、冲刺评审和冲刺回顾会议。看板面板帮助团队进一步提高效率，方法是将工作流可视化、使障碍更容易被察觉，以及通过调整在制品限制来实现流程管理。此外，受极限编程启发的工程实践，如使用故事卡、持续集成、重构、自动化测试和测试驱动开发，将进一步提高敏捷团队的效力。总之，与孤立采用各种实践相比，协调这些不同来源的实践将产生更好的协同成果。
有时，为了更好地配合，根据项目属性对方法进行裁剪。敏捷实践指南表 3-2列出一些要考虑的项目因素和裁剪方案。
关于影响裁剪的因素的更多指导，请参见《敏捷实践指南》P119-123附件X2“影响裁剪的属性”。更详细的内容参考《敏捷实践指南》。