敏捷关键词术语表：考前快速过一遍

在软件开发的世界里，敏捷（Agile）早已不是什么新鲜词，但对许多刚接触或即将参加敏捷认证考试（如CSM、PMI-ACP）的朋友来说，它依然像一团缠绕的毛线——概念多、术语杂、关系绕。别慌！本文就是为你量身打造的“考前速通包”，用轻松科普的方式，帮你快速梳理那些高频出现的敏捷关键词，让你在考场上胸有成竹，轻松过关。

首先，我们从“敏捷宣言”说起。它不是法律条文，也不是技术规范，而是2001年由17位软件大佬在雪山上达成的“价值观共识”。它强调四组对比：个体与互动高于流程与工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。记住这四条，你就掌握了敏捷的“灵魂”。考试中常考“哪个更重要”，答案往往指向左边那项。

接着是“Scrum”，这是目前最流行的敏捷框架。它的核心角色有三个：产品负责人（Product Owner）、Scrum Master、开发团队（Dev Team）。PO负责定义“做什么”，是需求的代言人；Scrum Master是团队的教练和清道夫，确保流程顺畅、移除障碍；开发团队则负责“怎么做”，是自组织、跨职能的实干派。三者缺一不可，考试常考角色职责混淆题，比如“谁负责排优先级？”——答案是PO。

Scrum的节奏靠“Sprint”驱动，通常2~4周为一个迭代周期。每个Sprint开始前有“Sprint Planning”（计划会议），结束时有“Sprint Review”（评审会）和“Sprint Retrospective”（回顾会）。评审会是给客户看成果、收集反馈的，回顾会则是团队内部复盘：“哪里做得好？哪里能改进？”——这是持续改进的关键。别把这两个会搞混了，考试最爱考这个！

再说说“用户故事”（User Story）。它不是小说，而是一种轻量级的需求表达方式，格式通常是：“作为一个[角色]，我想要[功能]，以便[价值]。”比如：“作为一个用户，我想要一键登录，以便节省注册时间。”用户故事强调从用户角度出发，关注价值而非技术细节。与之配套的是“验收标准”（Acceptance Criteria），它定义了故事完成的“合格线”，是测试的依据。

“燃尽图”（Burndown Chart）是Scrum中常见的可视化工具，横轴是时间，纵轴是剩余工作量。理想情况下，曲线应平稳下降至零。如果曲线突然上扬，说明有新任务加入或估算失误；如果长期平缓，则可能进度滞后。考试中常给你一张图，让你判断团队状态，掌握趋势解读是关键。

“看板”（Kanban）是另一个常用敏捷方法，源自丰田生产系统。它不强调固定迭代，而是通过“可视化工作流 + 限制在制品数量（WIP）”来优化流动效率。看板三要素：可视化板、WIP限制、持续改进。它适合维护型项目或需求变化极快的场景。与Scrum相比，看板更柔性，但两者也可结合使用（Scrumban）。

“持续集成”（CI）和“持续交付”（CD）虽然不是Scrum专属，但在敏捷实践中极为重要。CI指开发人员频繁将代码合并到主干，并自动构建测试；CD则是在CI基础上，确保软件随时可部署。它们共同目标是减少集成风险、加快反馈循环。考试中若出现“如何减少发布风险？”这类题，CI/CD往往是正确答案。

最后，别忘了“敏捷教练”（Agile Coach）和“仆人式领导”（Servant Leadership）。前者是组织级的变革推动者，后者是Scrum Master的核心领导风格——不是发号施令，而是服务团队、赋能成员。这体现了敏捷以人为本、信任自组织的核心理念。

当然，还有“增量交付”“技术债”“重构”“结对编程”“MoSCoW优先级”等术语，也都值得你快速过一遍。但记住：理解背后的“为什么”比死记硬背更重要。敏捷不是教条，而是思维和文化的转变。

考前最后一晚，与其熬夜刷题，不如闭眼回想这些关键词的逻辑关系：角色如何协作？流程如何循环？工具如何辅助？价值如何交付？当你能把这些点串成线、织成网，敏捷的骨架就清晰了。祝你考试顺利，敏捷之路越走越宽！