【软件工程】软件开发模型:敏捷开发(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:本质区别(软考核心考点)
这是软考中极易混淆的点,必须搞清楚:
| 对比项 | Scrum | XP |
|---|---|---|
| 本质 | 管理框架(管人、管事、管节奏) | 工程方法(管代码、管技术、管质量) |
| 关注点 | 项目管理流程 | 代码质量与工程技术 |
| 核心内容 | 角色、事件、工件 | 结对编程、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 #软件工程