敏捷与DevOps的关系：编排流水线，还是流水线里的机器

[[敏捷的本质是负反馈调节，而非提速工具|敏捷]]和[[DevOps的本质是消除信息不对称|DevOps]]共同的目标都是让业务拿到快速、可靠、易修改的软件，但侧重点不同——用制造业装配流水线来类比，能看清二者的分工。传统瀑布开发下，软件交付流程是一条完整连续的流水线，产品从头到尾一次性生产完成；敏捷开发的应对策略是把这条流水线拆分成多条小的子流水线，每条子流水线生产出一个增量版本，客户满意就进入下一条子流水线继续生产——这种拆分和迭代能让团队更灵活地应对需求变化、依据客户反馈及时调整。所以敏捷更多是一种针对生产过程本身、以及过程中人与人沟通方式的创新编排方式。DevOps则更像是流水线里的机器本身——负责原材料管控、质量管控；它并不关心流水线是一条还是拆成多条，而更关心产品一旦进入流水线之后如何又快又高质量地”下线”，因此DevOps致力于用自动化提升生产效率、用测试和质量规约保证产品质量，本质上更侧重工具与工具之间的协同（虽然这不代表DevOps完全排斥人与人的协同，只是相对更倾向用工具和自动化流程去替代人工协同）。这解释了为什么二者存在互为延伸的关系：从敏捷的角度看，DevOps是它的延伸——阶段上把敏捷延伸进了运维阶段，能力上用工具能力补充甚至替代了人员能力，有了DevOps之后敏捷方法论的实施效果被大大增强；从DevOps的角度看，敏捷是它的内核——DevOps的重要目标是通过缩短迭代周期实现业务快速上线，离开敏捷根本做不到，只有和敏捷结合，DevOps才真正有了”灵魂”，而不只是一堆工具的集合。可迁移启发：判断一个团队”做了DevOps却没见效”，可以先检查它是否真的有敏捷这个”内核”在支撑——如果只是把CI/CD工具堆砌起来，却没有相应的迭代式生产组织方式（子流水线+快速反馈）配合，DevOps就只是一套没有灵魂的工具集合。

结构图：

flowchart LR
  A["传统瀑布:一条完整流水线"]
  A --> B["敏捷:拆分为多条子流水线<br/>=编排生产过程本身(人与人的组织方式)"]
  B --> C["DevOps:流水线里的机器<br/>=原材料/质量管控(工具与工具的协同)"]
  C -.DevOps是敏捷的延伸(阶段+工具能力).-> B
  B -.敏捷是DevOps的内核(灵魂).-> C