敏捷和DevOps词汇表

本词汇表是旨在说明敏捷与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)	主要覆盖了软件上线后的运维，最近其范围有向软件开发升级方面的延伸。ITIL是ITSM的一种实施
质量检查	JKK Ji-Kotei-Kanketsu	来自日文，有逐级逐段严格检查的意思，确保质量，JKK的概念是一种完美状态：在你所处在的工作流程中不要做低质量的工作，不接受流程早期就出现错误的输出，不把糟糕的情形输出到下一个流程。
服务级别协议	Service Level Agreement-SLA	根据不同的级别制定不同的服务协议，常见的协议要素有时间要求，比如在多少小时内解决
单件流	One-piece-flow	一种为了实现适时适量生产，致力于生产同步化的最小批量生产方式，如再加上看板的运用，就彻底地实行了JIT了。来自生产企业的定义：指的是通过合理的制订标准生产流程并安排好每个工序的人员量、设备量，使每个工序耗时趋于一致，以达到缩短生产周期、提高产品质量、减少转运消耗的一种高效管理模式
在制品	Work-in-Progress WIP	包括正在加工的产品和准备进一步加工的半成品