无论采用瀑布生命周期，还是采用敏捷生命周期，一个项目通常都绕不开几类基本活动：
- 规划要做什么
- 设计如何实现
- 执行具体工作
- 确认结果是否符合要求
不同框架可能使用不同的术语，也可能对这些活动进行更细的拆分，但其底层逻辑并不会发生根本变化。
瀑布和敏捷之间真正明显的区别，并不是一方有规划、设计和确认，而另一方没有。它们的差异更多体现在：这些活动以多大的规模、在什么时间范围内发生，以及反馈需要等待多久。
瀑布：大规模、集中式地完成各类工作
在瀑布型项目中，规划、设计、执行和确认通常都是规模较大的阶段。
项目可能先集中进行需求分析和总体规划，再进入详细设计；设计基本完成后，才开始大规模开发或实施；等主要建设工作结束，再集中开展测试、验收和确认。
这种方式的特点是，同类工作高度集中。
规划阶段集中做规划，设计阶段集中做设计，执行阶段集中做执行，验证阶段集中做验证。每一个阶段都可能持续较长时间，并向下一阶段移交相对完整的成果。
这种模式并不等于没有风险管理，也不意味着项目团队不会检查和调整。问题在于，它的反馈周期通常更长。一旦前期的理解或设计存在偏差，可能要到执行后期甚至验收阶段才能得到充分验证。
敏捷：同样的工作，被分散到较小的迭代中
敏捷并没有取消规划、设计、执行和确认。
它只是把这些活动缩小，并分散到一个个迭代或冲刺中。
在每个冲刺里，团队仍然需要进行规划，确认本次准备完成什么；仍然需要设计，决定功能或方案如何实现；仍然需要执行开发、实施或配置工作；最后也仍然需要评审、测试和确认成果。
同类工作依然存在，也仍然会在一定范围内集中发生，只是每次处理的规模更小。
这意味着团队不必等待整个项目完成，才知道方向是否正确。每完成一个较小的增量，就可以获得一次反馈，并根据实际结果调整接下来的计划。
因此，敏捷缩短的并不只是工作周期，更重要的是缩短了从“作出判断”到“验证判断”的距离。
生命周期不同，底层管理规律并没有改变
正因为规划、设计、执行和确认是项目交付中的基本逻辑，所以无论是 PMI 体系，还是其他项目管理与敏捷框架，都不会轻易取消这些活动。
框架可以重新组织它们，可以改变它们的规模、频率和顺序，也可以让其中一部分工作并行发生，但不能假装项目不再需要规划、设计、执行和验证。
没有规划，团队很难形成一致方向。
没有设计，执行容易失去结构。
没有执行，所有方法都只停留在概念上。
没有确认，团队也无法证明结果是否真正符合要求。
这也是我理解项目流程管理的基础：方法可以变化，但交付所依赖的基本事实不会因为框架名称改变而消失。
我不会让项目服务于框架
我并不拘泥于某一个项目管理框架，也不会因为一个方法被称为“传统”就拒绝使用，更不会因为另一个方法被称为“敏捷”就默认它一定更优。
瀑布、Scrum、Kanban、Nexus，以及各种混合交付方式，都只是帮助项目解决问题的工具。
真正需要判断的是：
- 当前需求的确定程度如何
- 项目是否存在大量外部依赖
- 团队是否具备高频协作和反馈的条件
- 成果能否被拆分并逐步验证
- 现场、合同和验收机制允许多大程度的调整
- 哪种方式能够以更低的成本和风险交付价值
如果需求稳定、技术路线成熟、阶段边界清晰，较强的前期规划可能更有效。
如果需求不确定、反馈频繁、成果可以逐步验证，那么短周期迭代通常更合适。
如果同一个项目同时存在稳定工程任务和高不确定性的软件工作，那么采用混合方式，往往比强行统一成某一种生命周期更加合理。
我的核心理念：尊重事实，使用真正有效的方法
如果一定要概括我的核心管理理念，我认为它不是某个框架的名称，而是：
尊重事实，依据经过验证的经验，并选择当前环境下更合适的方法。
我会参考成熟框架，也会尊重成功实践，但不会把任何方法当成不能修改的教条。
只要一种做法适合当前项目，能够降低浪费、控制风险、改善协作，或者以更高效率交付更可靠的结果，我就会考虑使用。
如果实践证明存在更优的方案，我也会调整原来的方法。
对我来说，框架应该服务于项目，而不是让项目和团队为了保持框架的完整形式，承担额外且没有实际价值的成本。
项目管理最终要面对的，始终是真实的需求、真实的约束、真实的团队，以及真实的交付结果。方法可以灵活组合，但这种以事实和结果为依据的判断方式，是我不会改变的管理理念。