企业官网建设流程全解析

• 教程

本篇指南基于 FAQGURU 仓库的 Agile 面试问答专题 展开，系统梳理了敏捷开发的核心理念（敏捷宣言与 12 原则）、核心工作单元（用户故事、迭代）、进度度量手段（速度、故事点、燃尽图）以及工程质量实践（重构、TDD、持续集成）。读完本文，你将掌握 27 个高频敏捷面试问题的标准回答口径，并能区分迭代与增量、Scrum 与 Agile、燃起图与燃尽图等易混淆概念，为技术面试和团队实践打下扎实基础。

一、敏捷的定位与核心理念

什么是 Agile？

Agile（敏捷）是一种时间盒（time boxed）、迭代式的软件交付框架，它从项目启动之初就开始以增量方式构建软件，而不是等到项目末期一次性交付全部成果。

其工作方式可以拆解为三步：

1. 把项目拆解成一个个小块的用户功能，即用户故事（User Stories）；
2. 对用户故事进行优先级排序；
3. 以约两周为一个**迭代（iteration）**周期持续交付。

因此，凡是与 Agile Manifesto（敏捷宣言） 核心理念一致的开发过程，都可以称之为敏捷。需要注意，Agile 是一个框架性概念而非单一方法，它有多种具体落地方法（详见后文"实施敏捷的常用方法论"）。

敏捷与其他软件交付方式的差异

在 FAQGURU 的 Agile 问答 中，敏捷与传统（瀑布式等）交付方式的区别被概括为以下几点：

• 分析、设计、编码与测试是连续进行的活动，而非顺序执行的独立阶段；
• 开发是迭代式的，成果逐步成型；
• 计划是自适应（adaptive）的，随实际情况动态调整；
• 角色边界模糊，团队成员职责交叉、协作更紧密；
• 范围可以变化，需求变更被允许且被欢迎；
• 需求可以变更，这与瀑布模型"冻结需求"的做法截然不同；
• 可工作的软件是衡量成功的主要标准。

从源码结构看，readme.md 也印证了这份指南的定位：FAQGURU 收录的是"真实面试中的真实问题"，答案相对精炼，旨在作为面试准备的参考工具，因此上述每一条差异都值得在面试中结合自己的项目经历展开说明。

敏捷宣言：四大价值观

2001 年 2 月，17 位软件开发者在犹他州聚会，讨论轻量级开发方法，并发布了《敏捷软件开发宣言》（Manifesto for Agile Software Development）。宣言阐述他们如何"通过亲身实践并帮助他人实践，找到了更好的软件开发方式"，包含四大价值观与12 条原则。

四大价值观的核心表述是：右侧条目虽有价值，但敏捷团队更重视左侧条目：

需要强调的是，"而非"并不意味着完全抛弃右侧内容——文档、工具、计划与合同在项目中仍有价值，只是当两者冲突时，敏捷团队会优先选择左侧。

12 条敏捷原则

完整背诵并理解这 12 条原则，是敏捷面试的高频考点：

1. 我们的最高优先级是通过尽早并持续地交付有价值的软件来满足客户；
2. 欢迎不断变化的需求，即使是在开发后期。敏捷过程利用变化为客户创造竞争优势；
3. 频繁交付可工作的软件，周期从几周到几个月，倾向于更短的时间尺度；
4. 业务人员和开发人员必须在整个项目中每天一起工作；
5. 围绕有动力的个体构建项目，为他们提供所需的环境和支持，并信任他们能够完成任务；
6. 向开发团队传递信息以及团队内部沟通，最有效率的载体是面对面的交谈；
7. 可工作的软件是衡量进度的首要标准；
8. 敏捷过程倡导可持续开发。发起人、开发者和用户应能无限期地保持恒定的节奏；
9. 持续关注技术卓越与良好设计，这会增强敏捷性；
10. 简单——即"最大化不做的艺术"——是至关重要的；
11. 最好的架构、需求与设计出自自组织团队；
12. 团队要定期反思如何变得更有效，并相应地调整自己的行为。

产品路线图（Product Roadmap）

产品路线图指的是产品功能的全局视图（holistic view），它承载并具象化了产品愿景（product vision）。在面试中可进一步补充：路线图通常按时间维度排列功能主题（如季度、里程碑），是沟通愿景、对齐干系人预期、辅助优先级决策的重要工具；它与一次迭代的 sprint backlog 不同，粒度更粗、时间跨度更长。

二、敏捷的工作单元与节奏

用户故事（User Stories）

用户故事是客户希望在自己的软件中看到的功能特性。它们的典型特征包括：

• 写在索引卡片上，以鼓励面对面的沟通（与 12 原则中"面对面交谈最有效率"相呼应）；
• 单个故事的工作量通常不超过几天；
• 它们是敏捷计划的基础单元（basis of our Agile plans）。

一个常见补充是标准的用户故事句式："作为一个（角色），我想要（功能），以便（价值）"，并附带验收标准来界定"完成"的定义。

敏捷迭代（Agile Iteration）

迭代是 1～2 周的短期周期。在一个迭代内，团队选取优先级最高的用户故事，将其完整构建，并作为可运行的、经过测试的软件交付给客户。分析、设计、编码、测试都在一个迭代内发生。

注意区分两个概念：这里的"迭代"是敏捷执行的基本节奏单元（等价于 Scrum 中的 Sprint），而"迭代式开发"是一种更广义的开发哲学，详见下文。

增量开发与迭代开发的区别

这是面试中极易混淆的一对概念：

• 迭代式开发（Iterative）：是一个持续循环的软件开发过程，开发周期（Sprint 与 Release）不断重复，直到最终产品达成。核心在于"重复、打磨、逼近目标"。
• 增量式开发（Incremental）：把系统功能切分为若干增量（increments）或部分（portions），每个增量中，一段功能通过跨职能协作（从需求到部署）被完整交付。核心在于"切分、逐块、累积交付"。

可以这样理解两者的关系：迭代强调"反复循环优化"，增量强调"分块逐步交付"；敏捷项目通常是"迭代式 + 增量式"的结合——每个迭代交付一块完整可用的功能增量。

Scrum 与 Agile 的区别

• Scrum：在 Scrum 中，Sprint 是开发的基本单元。每个 Sprint 之前有计划会议（planning meeting），会上识别并估算本 Sprint 的任务；每个 Sprint 内，团队产出一部分完成的产品。
• Agile（广义）：在敏捷中，每个迭代都让团队经历完整的软件开发周期，包括计划、设计、编码、需求分析、单元测试和验收测试，并向干系人演示产品。

一句话总结：Agile 是实践（practice），Scrum 是遵循该实践的过程（process）。Scrum 是敏捷最主流的一种落地框架，此外还有 XP、Kanban 等方法。

Spike 与 Zero Sprint

这两个概念都与"正式迭代之前的准备"有关：

• Zero Sprint（零号冲刺）：在正式第一个 Sprint 启动之前引入，用于开展研究。通常在项目启动阶段执行，典型活动包括：搭建开发环境、准备产品待办列表（product backlog）等。
• Spike（尖峰）：一种特殊类型的故事（story），用于研究、探索、设计甚至原型验证。在 Sprint 之间可以插入 Spike 来处理某个技术或设计问题。Spike 分两种：
  • Technical Spike（技术型）：用于验证技术方案、探索技术可行性；
  • Functional Spike（功能型）：用于澄清业务需求、探索功能边界。

面试回答时可以补充：Spike 的特点是没有明确的商业交付价值，产出通常是"结论、原型或方案文档"，其时间盒需要严格控制。

三、进度度量：速度、故事点与燃尽/燃起图

Velocity 与项目速率

**Velocity（速度/速率）**是敏捷中最核心的度量指标之一，计算方式为：一个迭代内所有已完成用户故事的工作量估算之和。它回答了两个关键问题：

1. 敏捷团队在一个 Sprint 内能完成多少工作；
2. 完成整个项目大约需要多长时间。

**项目速率（Project Velocity）**是团队"燃烧"故事点的速率，例如"每个迭代 30 个故事点"。这意味着：到目前为止，团队平均每个迭代能识别、编码并测试 30 个单位的功能（故事点），未来迭代也大致能做到这个量级，从而为"发布日之前能完成多少"提供相当可靠的预判。

需要注意的是，Velocity 是团队的"经验值"而非目标值，不同团队之间不可横向比较；它主要用于内部预测与排期。

故事点、工作量与刻度（Story Points / Efforts / Scales）

故事点用于讨论一个故事的难度，而不分配实际工时。常用刻度有几种：

• 斐波那契数列（Fibonacci）：1, 2, 3, 5, 8, 13, …（原文档写为 1, 2, 3, 5, 8, 13, …，这是最常用的刻度，因其间隔随数字增大而拉开，符合估算精度递减的直觉）；
• 线性刻度（Linear）：1, 2, 3, 4, …；
• 2 的幂（Powers of 2）：1, 2, 4, 8, …；
• 服装尺码（Cloth size）：XS, S, M, L, XL。

使用故事点而非工时，是为了规避"估算绝对工时"带来的虚假精确，把讨论焦点放在相对难度上。

燃尽图（Burndown Chart）的作用与要点

燃尽图是一个展示团队进度（以"被燃尽的工作量"计）的图表。要点包括：

• 工作通常以故事点表示，代表功能量；
• 当一段功能被编码、测试并由用户评审通过后，即视为"被燃尽（burned）"，图表随之更新；
• 图表应呈现稳定的下降趋势，直到明确团队能在发布日期前完成故事点待办（backlog）；
• 一句话概括其目的：燃尽图展示的是时间盒（迭代）结束前还剩余多少工作。

燃起图（Burnup Chart）与燃尽图对比

两者都用于跟踪项目进度：

• 燃起图（Burnup Chart）：展示随时间推移已完成的故事数/工作量，即"做了多少"，通常还叠加一条总范围线，范围变化时一目了然；
• 燃尽图（Burndown Chart）：展示随时间推移还剩多少工作，即"剩多少"。

一句话对比：燃起图看"已完成累积量"，燃尽图看"剩余工作量"。

保持迭代长度一致的三大优势

在整个项目期间维持一致的迭代长度，有以下明确优势：

1. 帮助团队客观地度量进度——固定节奏让"是否按期完成"可量化比较；
2. 提供衡量团队速度的一致手段——Velocity 只有在周期相同时才可比；
3. 建立一致的交付模式——形成稳定的发布节奏与团队工作节律。

时间盒计划需要重排优先级时，该由谁决定？

如果时间盒（timebox）计划需要重新排定优先级，应当由整个团队共同参与，包括：产品负责人（Product Owner）和开发者（Developers）。其背后的逻辑是：产品负责人代表业务价值，开发者掌握技术约束，二者协同才能做出既符合商业目标又可落地的优先级决策。

四、质量与工程实践

重构（Refactoring）

重构是为了改善性能/代码质量而对既有代码进行修改的过程，修改后功能保持不变。也就是说，重构只改变代码的内部结构与可维护性，不改变其外部行为。

在敏捷语境下，重构是质量策略的第一条，它与 TDD 紧密配合：先让测试保障行为不变，再放心重构。面试中可以补充重构的常见手法（提取方法、消除重复、简化条件表达式等），并强调"没有测试保护的重构是危险的"。

测试驱动开发（TDD）

测试驱动开发又称测试驱动设计。其流程是：

1. 开发者先编写一个自动化测试用例，描述新的功能或改进；
2. 然后编写足够小的代码让该测试通过；
3. 最后重构新代码，使其达到可接受的（代码）标准。

TDD 的本质是通过"红灯→绿灯→重构"的循环，让测试成为设计工具而非事后验证。它直接呼应敏捷"可工作的软件是首要进度标准"与"持续关注技术卓越"的原则。

为什么持续集成（CI）对敏捷很重要

持续集成（Continuous Integration）在敏捷中的重要性体现在四点：

1. 保障按时发布——尽早发现 bug 与集成错误，避免问题在发布前夕集中爆发；
2. 保证构建质量稳定——敏捷代码交付频繁（通常每 2～3 周一个 Sprint），稳定的构建质量是硬性前提，CI 持续校验这一点；
3. 维持代码库高质量、无 bug 状态——每次集成都经过自动构建与测试；
4. 管理分支影响——如果开发在分支上进行，CI 通过自动构建与合并功能，检查分支改动对主干（main trunk）的影响。

从实践角度，CI 与"每个迭代交付可运行软件"直接绑定：没有 CI，频繁集成意味着频繁出错。

敏捷质量策略清单

FAQGURU 的 Agile 专题 汇总了以下敏捷质量策略：

• 重构（Re-factoring）
• 非单人开发（Non-solo development），即结对/集体代码所有权
• 静态与动态代码分析（Static and dynamic code analysis）
• 评审与检查（Reviews and Inspection）
• 迭代/Sprint 演示（Iteration/sprint demos）
• 全员演示（All hands demo）
• 轻量级里程碑评审（Light weight milestone reviews）
• 短反馈循环（Short feedback cycles）
• 标准与指南（Standards and guidelines）

可以看出，敏捷质量不是靠"测试阶段集中把关"，而是把质量活动前置并融入日常开发：重构、结对、代码分析、评审、演示与反馈循环共同构成了内建质量（built-in quality）体系。

优秀敏捷测试人员应具备的素质

一个优秀的敏捷测试人员（Agile Tester）应当具备以下素质：

• 能快速理解需求——敏捷需求变化快，测试人员必须快速抓取要点；
• 熟练掌握敏捷原则与概念——理解迭代、用户故事、速度等基本语境；
• 理解需求持续变化中的风险——需求一变，风险分布就变，需要敏锐感知；
• 能基于需求对工作排定优先级——在有限迭代内聚焦最有价值的测试；
• 保持业务人员、开发者与测试人员之间的持续沟通——沟通是敏捷测试的生存线。

五、实施边界：方法论、挑战与不适用的场景

实施敏捷的常用方法论

Agile 是一个框架，其下有一系列具体的方法（methods），常见包括：

• 极限编程（Extreme Programming，XP）——强调工程实践（结对编程、TDD、持续集成）；
• Scrum——以 Sprint 与固定角色（PO、SM、开发团队）为特征的过程框架；
• 精益软件开发（Lean Software Development）——源自丰田生产系统，强调消除浪费；
• 看板（Kanban）——以可视化流动与 WIP 限制为核心；
• 水晶方法（Crystal Clear）——强调"以人为本、按项目规模裁剪流程"的轻量方法族。

敏捷开发中的典型挑战

敏捷软件开发的挑战包括：

• 需要更多的测试与客户参与——对投入度要求高；
• 对管理层的影响大于对开发者的影响——管理方式必须转变；
• 每个功能必须完成才能进入下一个——"完成"的定义需要严格把控；
• 所有代码必须正常工作，以确保应用始终处于可工作状态——这与"每个迭代交付可运行软件"互为因果；
• 需要更多的计划——迭代计划、发布计划、细化（refinement）都是持续活动。

这些挑战提示我们：敏捷不是"少计划、少文档"，而是"计划更频繁、更贴近实际"。

何时不适合使用敏捷？

在采用敏捷之前，应当先自问以下五个问题：

1. 功能是否可拆分（Is functionality splitable）？——如果需求高度耦合、无法切成小块，敏捷增量交付无从谈起；
2. 客户是否可得（Is customer available）？——缺少客户/干系人频繁反馈，敏捷会失去方向；
3. 需求是否灵活（Are requirements flexible）？——需求被合同严格锁定时，响应变化无从落地；
4. 是否真的受时间约束（Is it really time constrained）？——固定截止日期下仍要评估迭代节奏是否可行；
5. 团队是否足够熟练（Is team skilled enough）？——敏捷对团队自组织与工程能力要求较高。

这五个问题本质上是对"敏捷适用边界"的诚实检验，也是面试中展示工程判断力的加分点。

六、在 FAQGURU 中继续系统化学习

FAQGURU 是一个面向技术面试准备的问答仓库，核心入口是 readme.md，其中按主题划分了 40+ 个面试专题。Agile 专题 属于其中的通用工程素养板块，与 Git、Design Patterns、Code Problems 等专题互补，构成"软技能 + 硬技能"的完整备考矩阵。

• 中文读者可以参考 中文版目录，其中第 40、41 项分别列出了"敏捷开发之 Agile"与"敏捷开发之 Scrum"；
• 仓库同时维护俄语（topics/ru/readme.md）、韩语（topics/ko）等多语言版本；
• 如果你想为社区贡献翻译，可参考 CONTRIBUTING.md 中关于新增翻译目录的流程说明。

最后提醒一点：本专题中的多数问答属于开放式问题（open-ended），如 readme.md 所述，面试官更看重的是你围绕答案展开的讨论与论证，而非背诵本身。建议在掌握本文 27 个要点的基础上，结合自己的真实项目经历，把每个概念"讲成一个故事"。

• 教程