ARTICLE · 1288842
04-软件开发模型(敏捷模型)
04-软件开发模型(敏捷模型)大家好！今天我们继续细说软考高级架构知识点。本节来讲解软件开发模型（敏捷模型）的内容 敏捷开发不是某一个固定的过程模型，是一类以用户需求为核心、迭代增量、快速反馈的轻量级软件过程思想的集合。2001 年，17 位行业专家共同发布《敏捷宣言》，奠定敏捷的基础。敏捷解决的痛点：传统重型过程（瀑布）文档多、周期长、变更成本高、很难适应当今快速变化的需求。 ✅ 一句话考点：敏捷属于增量 + 迭代开发；适合需求变化频繁的项目。 ⚠️ 软考易错坑：敏捷宣言不是说不要文档、不要流程、不要合同、不要计划；只是优先级更低。可工作软件是敏捷最重要的交付物。 区分两个名词： 迭代：同一套需求反复打磨优化； 增量：每次增加一部分新功能； 敏捷 Sprint 同时具备迭代 + 增量特性。 Scrum 是最流行的敏捷框架，有固定角色、工件、事件（仪式）。 ⚠️ 考点：Sprint 周期一旦确定，不能随意拉长缩短；Sprint 内部需求一般不插入。 适合需求高度不稳定、风险高的项目，强调工程实践。XP 四大价值观：沟通、简单、反馈、勇气。核心实践（高频考点）： 对比：Scrum 是管理框架；XP 是一套工程实践。二者经常搭配使用（Scrum+XP）。 看板不是固定迭代，是持续流动式敏捷，没有 Sprint。核心：可视化工作流、限制在制品 WIP、管理流动、持续优化。适合：运维支持、工单、维护类工作、需求持续流入、无法按固定迭代规划的场景。 考点区分：看板是流式、无固定迭代；Scrum 是时间盒 Sprint 迭代。 以功能特征 Feature为核心驱动，适合大型软件项目。流程： 是一族方法（Crystal Clear、Yellow、Orange、Red）。核心思想：不同项目、不同风险、不同规模，敏捷流程轻重不同。根据项目规模、关键性选择不同的水晶；人是第一位，流程随人适配。 一句话：水晶以人为本，是 “可伸缩” 的敏捷。 早期敏捷，强调固定时间、固定预算，范围可变；MoSCoW 需求优先级模型：Must have 必须、Should have 应该、Could have 可以、Won’t have 本次不做，软考选择题高频。 源自精益生产，核心 7 大浪费：部分完成的工作、额外过程、多余功能、任务切换、等待、缺陷、知识传递。核心：消除浪费、快速流动、延迟决策、尽早交付价值。 ❌ 易错：故事点不是人天，是相对复杂度。 敏捷不禁止文档，拒绝 “前置大文档”；文档按需、轻量化。常见：用户故事 User Story（格式：作为 XX，我希望 XX，以便 XX）、验收标准。 用户故事 INVEST 原则（高频）：Independent 独立、Negotiable 可协商、Valuable 有价值、Estimable 可估算、Small 小、Testable 可测试。 这类场景一般使用瀑布，或者敏捷 + 阶段门（混合模型）。
非常感谢大家一直以来的支持与陪伴！如果这期内容对你有收获、有帮助，欢迎点赞、关注，持续解锁更多IT架构干货，我们下期再见！ 知识链接： 05.软件工程生命周期开发模型--敏捷开发
一、敏捷是什么（软考标准定义）
二、敏捷宣言（4 条，必考）
个体和交互 胜过 过程和工具 可工作的软件 胜过 详尽的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划
三、敏捷 12 条原则（理解 + 选择题考点）
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 欢迎需求变更，即使在开发后期。敏捷过程利用变更为客户创造竞争优势。 经常交付可工作的软件，交付周期越短越好（几周而不是几个月）。 业务人员和开发人员必须天天在一起工作。 围绕积极的个体开展项目，给他们所需环境和支持，信任他们能完成工作。 在团队内部，最有效的信息传递方式是面对面交流。 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发，责任人、开发人员、用户维持一个恒定节奏。 持续关注技术卓越和好的设计，增强敏捷能力。 简单 —— 使未完成的工作最大化的艺术。 最好的架构、需求和设计出自自组织团队。 团队定期反思如何提高效率，并据此调整自己的行为。
四、敏捷核心通用特点（选择题高频）
迭代增量：把大项目拆成多个短迭代（Sprint），每个迭代产出可运行、可交付的软件增量； 拥抱变化：需求可以动态调整； 客户持续参与，持续反馈； 自组织团队，减少层层管控； 轻文档：只保留必要文档，拒绝文档驱动； 价值优先：优先开发高价值需求。
五、主流敏捷方法（软考必考，逐个掌握）
1. Scrum（考的最多）
三大角色
产品负责人 PO（Product Owner）：负责产品 Backlog、排优先级、代表客户，决定做什么； Scrum Master（SM，Scrum 主管）：不是项目经理；仆人式领导，移除团队障碍、保护团队、保障 Scrum 流程正常运行，不分配任务； 开发团队（Dev Team）：自组织、跨职能，5–9 人最佳，负责估算、实现、测试本迭代功能。
三大工件
产品待办列表 Product Backlog：整个产品所有需求池，持续维护、优先级排序； 迭代待办列表 Sprint Backlog：从 Product Backlog 选出，本 Sprint 要完成的任务集合； 增量 Increment：Sprint 结束输出的可工作、可验收的软件版本。
五大事件（仪式）
Sprint 规划会：确定 Sprint 目标，挑选需求，拆解任务； 每日站会 Daily Scrum（15 分钟以内）：昨天做了什么、今天做什么、遇到什么障碍；不是汇报会； Sprint 评审会：向 PO、客户演示增量，收集反馈，更新产品 Backlog； Sprint 回顾会：团队复盘本迭代，哪些做得好、哪些改进； Sprint：一个固定时长迭代，通常 1–4 周，时长固定，中途不改变 Sprint 目标。
2. XP 极限编程（Extreme Programming）
结对编程：两人一台机器共同编码 测试先行 TDD：先写测试用例，再写业务代码 持续集成 CI、小版本频繁发布 简单设计、重构 现场客户：客户全职在团队内随时答疑 编码规范、隐喻、集体代码所有权
3. Kanban 看板方法
4. FDD 特征驱动开发（Feature-Driven Development）
开发整体模型 特征列表 按特征规划 按特征设计 按特征构建 特点：面向对象、以小特征为单位交付；适合大型团队。
5. Crystal 水晶方法系列
6. DSDM 动态系统开发方法
7. Lean 精益软件开发
六、敏捷的估算方式（考点）
故事点（Story Point）：相对估算，不是工时；常用斐波那契数列：1,2,3,5,8,13… 计划扑克：团队共同估算故事点
七、敏捷工件、文档考点总结
八、敏捷模型 优点、缺点
✅ 优点
快速响应需求变更，客户满意度高； 早期持续交付可用版本，风险提前暴露； 强调沟通，减少误解； 聚焦业务价值，避免做无用功能； 自组织团队，激发主动性。
❌ 缺点
对团队、客户的参与度要求很高；客户没时间深度参与很容易失败； 进度、成本预估比较困难，不容易精确管控； 文档偏少，后期交接、审计、合规场景吃力； 适合小团队，超大型复杂项目直接纯敏捷容易失控； 依赖团队自律，管控弱，容易范围蔓延。
九、适用场景 & 不适合场景
✅ 适合敏捷：
需求不明确、变化频繁、市场快速迭代（互联网产品）； 快速验证业务原型、抢占市场； 中小型跨职能团队； 客户可以持续投入、参与评审、及时反馈。
❌ 不适合敏捷：
需求稳定、固定不变、高合规审计（军工、航空、医疗安全关键软件）； 合同严格固定范围、固定交付物，客户无法持续配合； 分布式大团队、强外包审计、需要全套前置规格文档；
十、敏捷 vs 瀑布（软考必考对比）
表格
瀑布模型 | 敏捷模型 | |
需求 | 前期一次性冻结，尽量不变 | 需求可变，持续细化 |
交付 | 末期一次性交付 | 迭代增量、频繁交付可用版本 |
管理方式 | 计划驱动、阶段评审 | 价值驱动、反馈驱动 |
文档 | 重文档，文档是基线 | 轻文档，必要文档 |
风险 | 风险集中在后期 | 风险早期持续暴露 |
适合 | 需求稳定、高合规审计 | 需求多变、快速创新 |
十一、软考高频易错坑汇总（必看）
❌ 敏捷 = 不要文档 → 错！敏捷拒绝前置冗余文档，保留必要文档； ❌ Scrum Master 是项目经理，负责分配任务 → 错；SM 是障碍移除者，团队自组织； ❌ 每日站会用来汇报给领导 → 错；是团队内部同步，识别障碍； ❌ 故事点 = 开发工时 → 错；是相对复杂度估算； ❌ 所有项目都适合敏捷 → 错；安全攸关、强合规项目一般不适合纯敏捷； ❌ Sprint 中途可以随便加需求、修改 Sprint 目标 → 错；Sprint 目标在迭代内稳定，变更放入 Backlog 下一轮； DSDM 的 MoSCoW 优先级是高频选择题； XP 的 TDD、结对编程是标志性工程实践； 看板没有固定时间盒 Sprint，和 Scrum 最大区别。
十二、补充：敏捷和增量、迭代关系
迭代：反复打磨同一个需求； 增量：每次增加新功能； Scrum Sprint：迭代式增量开发。
