两者的区别在于开发完成后会发生什么。早期，软件开发没有具体的管理流程。随后出现了瀑布式开发流程Waterfall，它提出软件开发活动可以通过开发和构建应用程序所花费的时间来定义。那时，开发、测试和部署软件往往需要很长时间，因为在开发过程中没有审查和权衡。交付的软件也是有缺陷和错误的劣质软件，交付时间也不尽如人意。当时，软件项目管理的重点是长期的、拖延的规划。瀑布过程与三重约束模型相关，也称为项目管理三角。三角形的每一边代表项目管理三要素中的一个要素：范围、时间和成本。正如AngeloBaretta所写，三重约束模型“将成本视为时间和范围的函数，并且这三个约束以确定的、可预测的方式相互作用。......如果我们想缩短进度（时间），我们必须添加成本.如果我们想扩大范围，我们必须增加成本或时间。从瀑布流向敏捷瀑布流的生产和工程领域流向了线性化过程：就像房子需要支撑才能盖上屋顶一样。同样，软件开发问题被认为可以通过提前计划来解决。来自从头到尾，开发过程由路线图明确定义，沿着路线图可以获得最终交付的产品。最后，瀑布模型被认为对软件开发来说是不好的和违反直觉的，因为通常项目的价值是直到开发过程的最后才意识到，导致许多项目以失败告终。此外，客户在项目结束之前看不到任何可用的软件。敏捷采用不同的方法，它取消了对整个项目的规划，承诺估计的时间点，并简单地遵循计划。与瀑布过程相反，它假设并拥抱不确定性。它的哲学是to响应变化而不是讨论过去，它认为变化是客户需求的一部分。敏捷价值观敏捷得到敏捷宣言的认可，它定义了12条原则（LCTT译注：本文没有使用原文的简单句型，而是摘自《敏捷软件开发宣言》官方中文译文）：我们最important目标是通过持续提前交付有价值的软件来满足客户。对需求的变化持开放态度，即使是在开发后期。工作软件经常交付，间隔几周或一两个月，往往需要更短的周期。业务人员和开发人员必须在项目的每一天相互协作。激发个人的斗志，建设以个人为核心的项目。以信任为后盾，提供实现目标所需的环境和支持。面对面的交流是传递信息最好、最有效的方式。工作软件是进度的主要衡量标准。敏捷过程提倡可持续发展，责任人、开发人员和用户都必须能够保持稳定持续的步伐。对卓越技术和良好设计的不懈追求会增强敏捷性。考虑到简单性，这是尽量减少不必要的努力的艺术。最好的架构、需求和设计来自自组织团队。团队定期反思他们如何提高效率，并相应地调整他们的行为。敏捷的四大核心价值是（LCTT译注：这里的翻译也来自敏捷软件开发官方宣言）：个体和交互高于流程和工具工作软件高于详细文档客户协作高于合同谈判响应变化高于合规规划这与瀑布过程的严格计划风格相反。在敏捷过程中，客户是开发团队的一员，不仅仅是在项目开始时参与项目需求的定义，在项目结束时接受最终产品。客户通过验收标准帮助团队，并在整个过程中保持投资。此外，敏捷需要整个组织的变革和持续改进。开发团队与其他团队一起工作，包括项目管理和测试团队。做什么以及计划何时做由指定的角色领导并由整个团队商定。敏捷软件开发敏捷软件开发需要自适应规划、演化开发和交付。许多软件开发方法、框架和实践都遵循敏捷概念，包括：Scrum看板（可视化工作流）极限编程XtremeProgramming(XP)LeanDevOpsFeature-DrivenDevelopmentFeature-DrivenDevelopment(FDD)Test-DrivenTest-DrivenDevelopment(TDD)Crystal方法动态系统开发方法(DSDM)自适应软件开发自适应软件开发(ASD)所有这些都已单独或一起用于开发和部署软件。最常用的是Scrum、看板（或Scrumban）和DevOps。Scrum是一个采用团队的框架，通常由ScrumMaster、产品经理和开发人员组成，他们以跨职能、自主的方式工作，以加速软件交付，为客户提供重要的商业价值。它的重点是较小增量的快速迭代。看板是一个敏捷框架，有时称为工作流管理系统，可帮助团队可视化他们的工作以最大限度地提高效率（从而变得敏捷）。看板通常由数字或物理显示板表示。团队的工作随着仪表板上的进度而移动，例如从从未开始到进行中、测试、完成。看板可以让每个团队成员随时看到所有工作的状态。DevOps价值观DevOps是一种文化，一种心态，一种开发软件或基础设施的方式，一种构建和部署软件和应用程序的方式。它假设开发和运营之间没有障碍，他们一起工作没有冲突。DevOps建立在其他两个领域的实践之上：精益和敏捷。DevOps不是公司内的职位或角色；是一个组织或团队对持续交付、持续部署、持续集成的不懈追求。根据GeneKim（ProjectPhoenix和ProjectUnicorn的作者）的说法，有三种方法可以定义DevOps的哲学：第一：过程原则第二：反馈原则第三：持续学习原则DevOps软件开发DevOps不会凭空发生;是一种敏捷实践，本质上是一种共享的文化和思考软件开发和IT或基础设施实施的方式。当您想到自动化、云、微服务时，您会想到DevOps。在一次采访中，《加速构建和扩张高性能技术组织》的作者NicolForsgren、JezHumble和GeneKim是这样解释的：软件交付能力很重要，它极大地影响组织成果，例如利润、市场份额、质量、客户满意度和组织战略成就。目标。伟大的团队实现高交付量、稳定性和质量；他们不会折衷这些属性。您可以通过实施精益、敏捷和DevOps实践来提高能力。实施这些实践和能力也会影响您的组织文化，并将进一步有利于您的软件交付能力和组织能力。知道如何提高能力需要做大量的工作。DevOpsvs.AgileDevOps和Agile有相似之处，但又不完全相同，有些人认为DevOps优于Agile。深入了解它们以避免混淆很重要。相似之处毫无疑问，两者都是软件开发技术。敏捷已经存在了20多年，DevOps出现得更晚。两者都追求软件的快速开发，他们的想法都是基于如何在不损害客户或运维利益的情况下快速开发软件。两者之间的区别在于软件开发之后会发生什么。在DevOps和Agile中，都有软件开发、测试和部署的阶段。然而，敏捷过程在这三个阶段之后终止。相反，DevOps包括事后的持续运维。因此，DevOps会持续监控软件的运行情况，进行持续开发。在敏捷中，不同的人负责开发、测试和部署软件。而DevOps工程角色负责所有的活动，开发就是运维，运维就是开发。DevOps更侧重于削减成本，而敏捷是精益和减少浪费的代名词，侧重于敏捷项目会计和最小可行产品等概念。敏捷关注并体现经验主义（适应、透明和检查）而不是预测措施。总结敏捷和DevOps是截然不同的，尽管它们的相似性使人们认为它们是相同的。这是对敏捷和DevOps的一种损害。根据我作为敏捷专家的经验，我发现组织和团队从高层次上理解什么是敏捷和DevOps，以及它们如何帮助团队更高效地工作、更快地交付高质量产品并增加客户非常有用满意。有价值的。敏捷和DevOps绝不是对抗性的（或者至少不是故意的）。在敏捷革命中，他们是盟友而不是敌人。敏捷和DevOps可以相互协作和对齐，因此它们可以共存于同一个地方。
