2. Azure企业云项目交付方法论
Azure企业云项目的交付，很少是单一方法论的胜利。一个典型的上云项目，往往同时包含合规审计要求的固定里程碑、需要快速试错的POC验证、以及必须持续迭代的运维优化。因此，本节的核心不是比较哪种方法论"更好"，而是建立一套判断标准：在什么场景下用哪种方法论，以及Microsoft Cloud Adoption Framework（CAF）与Well-Architected Framework（WAF）如何在验收交付中发挥作用。
三种方法论的适用场景判断
瀑布模型在Azure交付中并未过时，它的价值集中在范围明确、变更成本高、外部依赖强的场景。例如企业数据中心的整体迁移，涉及网络割接窗口、机房搬迁计划、合规审计节点，这些工作一旦启动就很难回退，必须按阶段串行推进。瀑布的验收特征是：每个阶段有明确的交付物和签署确认，验收标准在项目启动时就已冻结。
敏捷方法适合需求不确定、需要快速获得反馈的场景。Azure上的应用现代化改造、新业务系统上云，往往在初期无法准确预估工作量和最终形态。敏捷通过2～4周的迭代，每个Sprint交付可运行的功能增量，验收方式从"最终一次性验收"转变为"每个迭代的增量验收"。在Azure交付中，这通常体现为每个迭代结束时，通过Azure DevOps的Pipeline将增量部署到测试环境，由业务方确认功能是否符合预期。
DevOps不是与瀑布、敏捷并列的第三种项目管理方法，而是贯穿交付与运维的技术实践体系。它的核心是把交付流水线、基础设施即代码（IaC）、监控告警、自动化测试固化下来，使变更可以小批量、高频次、可回滚地进入生产环境。在验收交付阶段，DevOps的价值体现在：验收不再依赖人工截图和手工记录，而是通过Pipeline的执行日志、IaC的部署结果、监控面板的基线数据来提供客观证据。
CAF与WAF在验收交付中的分工
Microsoft Cloud Adoption Framework（CAF）解决的是"怎么把云用起来"的问题，它覆盖策略、规划、就绪、采用、治理、管理六个阶段。在验收交付中，CAF主要提供两类指导：一是治理基线，包括订阅设计、命名规范、标签策略、策略即代码（Azure Policy）的落地要求；二是迁移与现代化的路径，明确每个工作负载的迁移方式（重新托管、重构、重建、替换）及其对应的验收要点。
Well-Architected Framework（WAF）解决的是"云上架构好不好"的问题，它从可靠性、安全性、成本优化、卓越运营、性能效率五个支柱评估架构质量。在验收交付中，WAF提供的是架构评审的检查维度：可靠性支柱关注SLA、可用区部署、备份恢复；安全性支柱关注身份、网络隔离、密钥管理；成本优化关注资源规格、预留实例、自动缩放；卓越运营关注IaC、CI/CD、监控；性能效率关注SKU选型、缓存、CDN。
两者的关系可以这样理解：CAF告诉你"该建什么、按什么规范建"，WAF告诉你"建得合不合格"。验收交付时，CAF的治理要求是合规性验收的输入，WAF的五支柱是技术质量验收的输入。
验收交付中的方法论组合实践
实际项目中，三种方法论和两大框架通常是组合使用的。以一个典型的Azure企业上云项目为例，可以按以下方式组织：
阶段一：规划与就绪（瀑布+CAF）。项目启动阶段，范围相对明确——需要迁移的工作负载清单、合规要求、时间窗口都已确定。此时采用瀑布的里程碑管理，同时依据CAF的"规划"和"就绪"阶段，完成订阅设计、网络拓扑规划、治理基线定义。验收标准在这一阶段冻结，包括：订阅命名规范、标签策略、Azure Policy分配清单、网络连通性测试用例。
阶段二：迁移与现代化（敏捷+CAF+WAF）。进入实际迁移阶段后，需求不确定性增加——某些应用在迁移过程中才发现依赖关系复杂，需要调整方案。此时采用敏捷迭代，每个Sprint迁移1～2个工作负载。每个迭代结束时，依据CAF的迁移路径确认工作负载是否按预期方式上云，同时依据WAF的五个支柱进行架构评审。验收方式为：每个迭代的增量验收，检查项包括资源部署是否成功、安全策略是否生效、性能基线是否达标。
阶段三：运维与优化（DevOps+WAF）。迁移完成后进入持续运维阶段，DevOps实践成为主线。通过Azure DevOps Pipeline实现基础设施即代码的持续部署，通过Azure Monitor建立监控基线。验收方式转变为：Pipeline执行成功率、IaC部署一致性、监控告警响应时间。WAF的五个支柱在此阶段用于定期架构评审，识别优化点。
验收交付中的关键判断点
无论采用哪种方法论组合，Azure项目验收交付都需要回答三个核心问题：
第一，治理基线是否落地？依据CAF的治理要求，检查订阅结构是否符合设计、标签是否完整、Azure Policy是否按预期生效。具体操作是：在Azure Portal的Policy页面查看合规性仪表板，确认不合规资源数量为零或已记录例外。如果存在不合规资源，需要判断是策略配置问题还是资源本身问题，并记录处理方式。
第二，架构质量是否达标？依据WAF的五个支柱逐项评审。以可靠性为例，检查关键工作负载是否部署在可用区、是否配置了备份和恢复策略、SLA是否满足业务要求。以安全性为例，检查是否启用了Azure Defender、是否配置了NSG和防火墙规则、密钥是否存储在Key Vault中。每个检查项都需要有明确的通过/不通过判断，以及不通过时的整改计划。
第三，交付证据是否完整？验收交付不是口头确认，而是需要可追溯的证据链。证据包括：IaC模板文件、Pipeline执行日志、监控基线截图、测试报告、架构评审记录。这些证据需要与验收标准一一对应，确保每个验收项都有对应的证据支撑。
常见误区与规避建议
在Azure交付实践中，方法论的选择容易出现两个极端：一是过度依赖瀑布，试图在项目启动时冻结所有需求，导致后期变更困难、交付周期拉长；二是盲目追求敏捷，在没有明确治理基线的情况下快速迭代，导致资源命名混乱、安全策略缺失、成本失控。
规避建议是：用CAF建立治理基线，用WAF定义质量门槛，再根据工作负载的特性选择瀑布或敏捷。治理基线是"硬约束"，无论采用哪种方法论都必须满足；质量门槛是"评审标准"，在每个交付节点都需要检查。方法论是"执行方式"，根据需求确定性和变更成本灵活选择。
对于DevOps实践，关键不是工具本身，而是把交付过程固化为可重复、可验证的流水线。在验收交付中，这意味着验收不再依赖人工操作，而是通过Pipeline自动执行部署、测试和验证，验收人员只需要检查Pipeline的执行结果和监控数据。这种方式不仅提高了验收效率，也降低了人为错误的风险。