本词汇表是旨在说明敏捷与DevOps中各种术语。
由于敏捷与DevOps存在紧密的联系，在讲述DevOps时需要引用到大量的来自敏捷的词汇，因此本文试图做些整理
| 词汇名称 | 对应英文 | 说明 |
|---|---|---|
| 重构 | Refactor | 指保持某个对象的外在行为不变，优化其内部结构。代码重构是重构的一种。 |
| 代码重构 | Code refactor | 保持程序代码的外在行为不变，优化代码。在面向对象编程中，典型的是保持类的对外行为不变，优化类的内部结构。 |
| 测试驱动开发 | Test driven development | 利用测试方法来驱动软件程序的设计和实现。其方法主要特征是先写测试程序，然后再编码使其通过测试。常见的测试驱动开发可以分为单元测试驱动开发和验收测试驱动开发 |
| 单元测试驱动开发 | Unit test driven development | 利用单元测试方法，典型采用xUnit类工具，来驱动程序的设计和实现，其方法主要特征是先写单元测试程序，然后再编码使其通过测试。 |
| 验收测试驱动开发 | Acceptance test driven development | 利用验收测试方法，典型采用自动化界面或接口测试方法，来驱动软件程序的设计和实现。其方法主要特征是先写自动化界面或接口测试，然后再编码使其通过测试。 |
| 时间箱 | Time box | 在限定的时间长度内开展活动，以时间为结束标志。 |
| 迭代 | Iteration | 重复反馈过程的活动，其目的通常是为了逼近所需的目标或结果。每一次对过程的重复被称为一次“迭代”，而每一次迭代得到的结果会被用来作为下一次迭代的初始值。 |
| 敏捷迭代 | Agile Iteration | 指每次按照相同的开发方式短期的开发软件的部分，或前期开发并不详尽的软件，每次开发结束获得可以运行的软件，以供各方干系人观测，获得反馈，根据反馈适应性的进行后续开发，经过反复多次开发，逐步增加软件部分，逐步补充完善软件，最终开发得到最后的软件。敏捷迭代包括了迭代和增量。 |
| 特性驱动开发 | Feature Driven Development | 简称FDD，最初由Peter Coad 及其同事作为面向对象软件工程使用过程模型而构思的，然后在其上扩展并增强了Coad的工作，描述了一个可用于中、大型软件项目的适应性敏捷过程。主要包括开发全局模型、构造特征列表、特征计划、特征设计、特征构建五个协作。 |
| 回顾会议 | Retrospective Meeting | 这是在Scrum中所要求的会议，也可以在非Scrum的环境下运用。回顾会议旨在对前期中的人、关系、过程和工具等等各方面进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。在回顾会议的最后，团队应该选择将要在下个迭代中要采取的改进。 |
| 燃尽图 | Burn Down Chart | 用图形化的方式来表述随着时间的推移，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴表示待完成的工作，常见的是待完成的故事点数、待完成的工时、待完成的用户故事数量，X轴表示时间，一般的，刻度是工作日。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 |
| 计划会议 | planning meeting | 这是在Scrum中所要求的会议。计划会议旨在对马上进行的迭代进行估算， 澄清并选择待开发项，识别后续行动。 |
| 用户故事 | User Story 从用户的角度出发去描述一个待开发产品的各种外在行为。所有用户故事的集合体现了产品对用户的价值（或商业价值）。 | |
| 速度 | velocity | 表示开发的快慢，常见有两种算法：1）迭代完成的故事点数；2）每人天完成的故事点数 |
| 敏捷思维 | Agile Thinking | 与敏捷精神、敏捷理念、敏捷价值观等词汇接近，目前没有客观严格的定义，一般理解为源自于敏捷宣言的理念，包括了注重团队协作、尊重个体、拥抱变化、快速响应、注重沟通、注重价值交付、增量交付可用软件等。 |
| 敏捷方法框架 | Agile method framework | 是指一种系统的阐述了软件开发核心领域并给出了面向全局框架的方法论，其由多个敏捷开发实践根据此框架有机的组合而成。比如Scrum、XP、FDD、DSDM。 |
| 敏捷实践 | Agile practice | 是指一种符合敏捷宣言的解决特定的、局部的问题的开发方法。比如单元测试驱动开发、燃尽图、用户故事等等。 |
| 敏捷管理实践 | Agile management practice 指敏捷开发实践中处理人员交互、信息交流的实践，比如计划会议、回顾会议、燃尽图。 | |
| 敏捷工程实践 | Agile engineering practice | 与敏捷技术实践是同义词，指敏捷开发实践中与代码实现、测试、设计、需求分析等密切相关的实践，比如重构，测试驱动开发，演进设计，持续集成，自动化测试等等。 |
| 敏捷技术实践 | Agile technical practice | 与敏捷工程实践是同义词，指敏捷开发实践中与代码实现、测试、设计、需求分析等密切相关的实践，比如重构，测试驱动开发，演进设计，持续集成，自动化测试等等。 |
| 自组织 | self-organizing | 在自然科学领域，自组织（self-organization)是指混沌系统在随机识别时形成耗散结构的过程。 在软件工程领域，从字面意思上，可以理解为指向着已自组织（英文是self-organized)前进，其基本特征是每个个体都有自主性，又能整合出整体的特征。 |
| 增量 | Incremental | 是指在以前的迭代的基础上增加的可用功能。 |
| 每日构建 | Daily build | 每日自动进行编译，然后运行自动化测试对构建进行验证，并给出报告。 |
| 持续集成 | Continuous Integration | 指当代码提交后，马上启动自动编译、自动化测试来快速验证软件，从而尽早地发现错误和代码冲突。 |
| 持续交付 | Continuous delivery | 指当代码提交后，能够快速并自动的启动编译、打包、安装到运行环境，中间过程可以安排各类自动测试，从而保证交付质量。一般的，持续交付包括持续集成 |
| 持续部署 | Continuous Deployment | 持续的自动的部署到生产环境，一般理解，持续部署是持续交付的一种形式 |
| 每日站立会议 | Daily standup meeting | 在Scrum方法中，每个冲刺的每一天，都会举行的一种项目状况会议。会议准时开始，时长不超过15分钟，所有成员都需要站立。每位成员回答3个问题。1、今天你做了什么？2、明天你计划做什么？3、有什么问题阻碍了你？ |
| 产品待办列表 | product backlog | 是指产品需求的列表（Backlog的条目可以是用户故事）。产品负责人根据商业价值对列表的条目进行排序，团队按照顺序进行开发。 |
| 史诗 | epic | 通俗来说就是大型用户故事。一般由许多较大的、不确定的需求组成，本身具有更低的优先级。因此，不能直接通过它进行迭代规划，而是要先把它划分成较小的、真正的用户故事。 |
| 应用部署 | Application Deployment | 部署编译后结果到运行环境 |
| 制品管理 | Artifact Management | 编译后制品的管理，一般相同源代码的编译后制品尽量只生成一次 |
| 完成的定义 | Definition of Done | 与退出条件、成功标准类同 |
| 信息技术服务管理 | ITSM (Information Technology Service Management) | |
| 质量检查 | JKK Ji-Kotei-Kanketsu | 来自日文，有逐级逐段严格检查的意思，确保质量，JKK的概念是一种完美状态：在你所处在的工作流程中不要做低质量的工作，不接受流程早期就出现错误的输出，不把糟糕的情形输出到下一个流程。 |
| 服务级别协议 | Service Level Agreement-SLA | |
| 单件流 | One-piece-flow | |
| 在制品 | Work-in-Progress WIP |
时间： 2024-10-03 17:02:29