软件工程学习笔记3——敏捷开发

张张一直在路上

已于 2024-03-18 09:45:53 修改

阅读量1k

点赞数 11

分类专栏：软件工程文章标签：软件工程学习笔记

于 2024-03-15 16:58:20 首次发布

本文链接：https://blog.csdn.net/qq_44778824/article/details/136732829

版权

14 篇文章 0 订阅

订阅专栏

本文探讨了敏捷开发的起源、原则以及与瀑布模型的区别，包括需求分析、架构设计、质量保证和部署方式。指出敏捷开发强调以人为中心，迭代交付，但也需要特定条件才能有效应用。

摘要由CSDN通过智能技术生成

一、敏捷开发

有人认为：

然而，这些是敏捷开发的真正含义吗？

要理解敏捷开发，我们先要了解其诞生背景。在 2001 年那会，“重型”的瀑布模型还是主流，整个流程走完通常周期很长。长周期导致风险增加、难以响应变化。

由瀑布模型衍生出很多模型，除上篇介绍的，还有当时不怎么有名，现在却如雷贯耳的轻量级开发方法，例如极限编程（Extreme Programming，XP）、Scrum 等。

2001 初，17 位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起，讨论替代瀑布模型这种重量级软件开发过程的新方法。

但是没能达成一致，所以退而求其次，把大家都认同的理念整理出来，也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟。
在这里插入图片描述

敏捷宣言指出：敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。

当你开发做决策的时候，遵守了敏捷开发的价值观和原则，不管你是不是用 Scrum 或者极限编程，那么都可以算是敏捷开发。

敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的、敏捷的方法来改善甚至是替代它。

敏捷开发是一种以人为核心，迭代，循序渐进的开发方式。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
简单的说，敏捷开发并不是追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价值，减少麻烦，敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作，需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。

这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践，Scrum 主要用来管理项目过程，极限编程重点在工程实践，而看板将工作流可视化。

基于 Scrum 和极限编程的实践，来对比一下敏捷开发模型和瀑布模型的差异。

好处是减少了大量需求文档的撰写，可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。

在敏捷开发中，每个 Sprint 只做一部分需求，所以是一种渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计。

缺点：这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象，产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构。

缺点：相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的。

瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境。测试验收通过后，发布部署到生产环境。
在敏捷开发中，这种持续构建、持续发布的概念叫持续集成，因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。