【软件工程】软件开发模型:敏捷开发(Scrum/XP)

考点频率:★★★★★(选择题必考,下午题案例分析也常出现)
难度:⭐⭐⭐
建议:重点掌握敏捷宣言的四项价值观和十二条原则、Scrum的“3355”框架、XP的核心实践,以及Scrum与XP的本质区别

1️⃣ 为什么需要敏捷开发?

前面我们讲了瀑布模型、增量模型、迭代模型、螺旋模型。这些模型有一个共同点:都是“计划驱动”的——先做详细的计划,再按计划执行。

但现实中的软件开发往往不是这样的:用户自己也不知道想要什么,等到看到东西才说“不对,我要的不是这个”;市场竞争瞬息万变,半年前的需求今天已经过时了。

于是,2001年,17位软件开发领域的专家聚集在美国犹他州的雪鸟滑雪胜地,共同签署了敏捷软件开发宣言(Agile Manifesto)。从此,一种全新的开发理念诞生了:与其试图预测一切,不如拥抱变化

2️⃣ 敏捷宣言:四项价值观

敏捷宣言的核心是四项价值观,这是敏捷开发的“宪法”:

左项(更重视)右项(也有价值)
个体和互动高于 流程和工具
可工作的软件高于 详尽的文档
客户合作高于 合同谈判
响应变化高于 遵循计划

注意:敏捷不是不要文档、不要流程、不要计划——而是更重视左边的内容。文档“够用就好”,计划“能应对变化就好”。

3️⃣ 敏捷十二原则

在四项价值观的基础上,敏捷宣言还提出了十二条原则

序号原则
1通过及早和持续地交付有价值的软件使客户满意
2欣然面对需求变化,即使在开发后期也一样
3经常地交付可工作的软件(周期越短越好)
4业务人员和开发人员每天一起工作
5积极的个人为核心,给予他们环境和信任
6面对面沟通是最高效的信息传递方式
7可工作的软件是进度的首要度量标准
8敏捷过程提倡可持续的开发速度
9持续追求技术卓越和良好设计
10简洁——最大化未完成工作的艺术
11最好的架构、需求和设计来自自组织团队
12团队定期反思如何提高成效,并调整行为

软考记忆要点:原则1(早交付)、原则2(拥抱变化)、原则3(频繁交付)、原则7(可工作软件是进度标准)——这四个是选择题中最常考的原则。

4️⃣ Scrum:敏捷的“管理框架”

Scrum是一种轻量级的项目管理框架,它告诉你“什么时候开会、谁该参加、产出什么”,但不规定具体怎么写代码。

4.1 Scrum的“3355”框架

Scrum框架可以概括为3个角色 + 3个工件 + 5个事件 + 5个价值观

3个角色

  • 产品负责人(Product Owner):负责定义和优先级排序产品待办事项列表,确保团队做最有价值的功能
  • Scrum主管(Scrum Master):负责促进Scrum活动,指导团队掌握Scrum框架,消除障碍
  • 开发团队(Development Team):自组织的跨职能团队,负责在每个冲刺结束时交付可用的产品增量

3个工件

  • 产品待办事项列表(Product Backlog):按优先级排序的所有功能、缺陷和改进的列表
  • 冲刺待办事项列表(Sprint Backlog):团队计划在当前冲刺中完成的工作子集
  • 产品增量(Increment):每个冲刺结束时所有已完成工作的总和

5个事件

  • 冲刺(Sprint):固定时长的迭代周期,通常2-4周
  • 冲刺计划(Sprint Planning):每个冲刺开始时,团队确定冲刺目标和计划
  • 每日站会(Daily Scrum):每天15分钟,同步进展、识别障碍、规划当日工作
  • 冲刺评审(Sprint Review):冲刺结束时,向利益相关者展示产品增量并获取反馈
  • 冲刺回顾(Sprint Retrospective):冲刺结束后,团队反思并识别改进领域

5个价值观开放、勇气、尊重、专注、承诺

软考速记:Scrum的“3355”——3角色、3工件、5事件、5价值观。

5️⃣ 极限编程(XP):敏捷的“工程方法”

如果说Scrum管的是“管理节奏”,那极限编程(Extreme Programming,简称XP)管的就是**“代码质量”** 。

XP由Kent Beck于1990年代末提出,强调短周期迭代、持续测试、快速交付可用软件

5.1 XP的五大价值观

XP围绕五个核心价值观展开:

价值观含义
沟通团队成员与客户之间保持开放透明的沟通
简单追求最简解决方案,避免过度设计
反馈通过持续收集反馈及时调整产品方向
勇气敢于尝试新方法,做出艰难决策
尊重尊重团队成员和客户,建立互信文化

5.2 XP的核心实践(软考重点)

XP包含一系列具体的工程实践:

实践说明
结对编程(Pair Programming)两名开发人员共同在一台机器上编码,提高质量、促进知识共享
测试驱动开发(TDD)先写测试用例,再写代码,确保代码通过测试
持续集成(CI)每次代码提交后自动构建和测试,快速发现冲突
重构(Refactoring)持续优化代码结构,提升可维护性
频繁交付每几周交付一次可用功能
客户协作与客户保持密切沟通,深入了解需求
集体代码所有制任何开发人员都可以修改任何代码

软考速记:XP的核心实践——结对编程、TDD、持续集成、重构,这四个是最常考的。

6️⃣ Scrum vs XP:本质区别(软考核心考点)

这是软考中极易混淆的点,必须搞清楚:

对比项ScrumXP
本质管理框架(管人、管事、管节奏)工程方法(管代码、管技术、管质量)
关注点项目管理流程代码质量与工程技术
核心内容角色、事件、工件结对编程、TDD、持续集成、重构
告诉你什么何时开会、谁参与、产出什么如何写代码、如何测试、如何集成
适用场景需求方向明确,变化频率中等需求模糊,变化极快,对质量要求高
能否单独使用✅ 可以⚠️ 通常需要与Scrum等框架配合

一句话总结Scrum是“管项目的”,XP是“写代码的”。实际项目中,很多团队用Scrum做项目管理,同时在编码环节采用XP的结对编程和TDD。

7️⃣ 敏捷开发的优缺点与适用场景

7.1 优点

优点说明
快速响应变化需求变更不再是噩梦,而是常态
用户参与度高用户在每个迭代都能看到可运行的软件并提供反馈
风险可控早期发现问题,早期修正
团队士气高自组织团队,信任和授权

7.2 缺点

缺点说明
管理难度大需要团队高度协作和自组织能力
文档不充分过度依赖口头沟通,人员变动时知识传承困难
不适合所有项目对安全关键、合规要求严格的系统(如航天、医疗)不太适用

7.3 适用场景

适用场景说明
需求不确定用户需求模糊、经常变化
市场变化快互联网产品、创业项目
需要快速试错需要通过用户反馈快速验证产品方向
团队规模适中通常5-9人的小团队

对比记忆:瀑布模型适合“需求明确、变化少”的项目;敏捷开发适合“需求模糊、变化多”的项目。

8️⃣ 经典例题

例题1:以下关于敏捷开发的说法中,正确的是( )。

A. 敏捷开发不需要任何文档
B. 敏捷开发的核心是“计划驱动”
C. 敏捷开发强调“响应变化高于遵循计划”
D. 敏捷开发只适用于小项目

解析:A错误——敏捷不是不要文档,而是“够用就好”;B错误——敏捷是“适应式”而非“计划驱动”;D错误——敏捷适用于各种规模的项目,但通常小团队更易实施。C正确,这正是敏捷宣言的四项价值观之一。选C


例题2:以下哪个实践属于XP(极限编程)而非Scrum?

A. 每日站会
B. 产品待办事项列表
C. 结对编程
D. 冲刺评审

解析:每日站会、产品待办事项列表、冲刺评审都是Scrum框架中的事件或工件。结对编程是XP的典型工程实践。选C


例题3(判断):Scrum是一种工程实践方法,主要关注如何编写高质量的代码。( )

解析:错误。Scrum是管理框架,关注项目管理的节奏和流程;XP才是关注代码质量和工程实践的方法。

9️⃣ 记忆口诀

敏捷宣言四价值:个体互动、工作软件、客户合作、响应变化。
敏捷原则十二条:早交付、拥抱变、频繁交、自组织。
Scrum框架3355:三角色、三工件、五事件、五价值。
XP实践要记牢:结对编程、TDD、持续集成、重构好。

🔟 小测验(评论区对答案)

某互联网创业公司正在开发一款新产品,用户需求不明确,市场变化快。公司希望每个迭代都能让用户试用并反馈。以下哪种开发方式最适合?
A. 瀑布模型
B. 螺旋模型
C. 敏捷开发(Scrum + XP)
D. 增量模型

🔔本专栏日更,点击头像 → 专栏《软考中级高频考点》订阅,第一时间接收新内容

#软考中级 #软件设计师 #敏捷开发 #Scrum #极限编程 #XP #软件工程