敏捷术语表

讨论敏捷时使用的常见术语

敏捷方法已经在软件开发组织中获得了广泛的认可, 发展, 并持续提供新的有效的解决方案. 向CRi的专家学习敏捷开发中使用的独特术语. 本敏捷术语表提供了敏捷开发和敏捷项目管理中主要术语和概念的简要定义.

 

A ∙ B ∙ CD ∙ EFGHIJKLMNOPQ ∙ RSTUVWXYZ

A

验收标准

可以判断工作项(用户故事)已经成功实现和测试的标准. A story is ‘done’ when all criteria pass 测试ing; conversely, 如果任何标准没有通过测试,那么故事就没有“完成”. 也被称为满足条件,描述了更高层次的条件, 当遇到, 交付业务价值.

验收测试

验证工作项(用户描述)满足指定的接受标准的过程. 理想情况下,方法是尽可能地实现自动化. 验收测试的结果/输出是一份报告,它识别正在测试的每个验收标准的状态,以及该项目是通过还是失败.

敏捷开发

一种基于敏捷宣言原则的软件开发方法. 术语“敏捷”是基于迭代开发技术的几种特定方法的保护伞,在迭代开发技术中,需求和可交付成果通过自组织之间的协作发展, 跨职能团队.

敏捷宣言

敏捷软件开发宣言是2001年2月编写的历史文档,它定义了轻量级的4个关键值和12个原则, 响应, 适应性强的软件开发.

B

待办事项列表

也称为“产品待办事项列表”,“backlog是一个用户描述和缺陷的优先列表,按照对系统的价值从高到低的顺序排列. 积压包括功能性和非功能性用户描述以及技术团队生成的描述.

行为驱动开发(BDD)

行为驱动开发(BDD)是一种围绕用户期望在与之交互时体验到的行为来记录和设计应用程序的技术. 通过鼓励开发者只关注应用或程序所要求的行为, BDD有助于避免膨胀, 过多的代码, 不必要的特性或缺乏重点. 这种方法结合了, 增强并改进了测试驱动开发(TDD)和验收测试驱动开发(ATDD)中使用的实践.

燃尽图

Representation of the number of hours remaining for completion of a project; usually represented in chart form with points plotted on an x and y axis that map a downward trend of work left to do until burning down to zero.

燃耗图表

Representation of the number of stories completed; usually represented in chart form with points plotted on an x and y axis that map an upward trend of work completed until reaching 100%.

C

搭配(集中的团队)

并置指的是位于同一位置并在同一位置工作的开发团队. 搭配通常应用于跨职能团队级别. 在敏捷开发中,搭配是促进协作和渗透沟通的一个重要(但不是必需的)概念.

满意的条件

根据高级标准,可以判断工作项(用户故事)已经成功实现并测试以交付业务价值. A story is ‘done’ when all conditions pass 测试ing; conversely, 如果任何条件没有通过测试,那么故事就没有“完成”. 通过验收测试交付工作代码,证明满足了满足条件.

持续集成

持续集成是敏捷软件开发的基本技术之一. 基础架构被配置为支持完全自动化和可复制的构建, 包括测试, 一天跑很多次. 通过尽可能频繁地将更改输入主线, 最好是每天, 通过扩展夜间构建的概念, 持续集成有助于减少集成问题,并更快地识别和解决问题.

跨职能团队

团队由具备所有功能技能和专业技能的成员组成,从开始到结束完成一个项目.

D

分布式团队

开发团队在同一个项目中工作,但分布在多个地点或工作地点.

E

史诗

描述大量客户价值的用户描述,需要分解成许多更小的用户描述.

F

G

H

I

检查和调整

敏捷概念,团队通过查看产品来评估项目, 倾听彼此的反馈,并最终改进过程或改变过程.

迭代

一个软件开发活动发生并导致工作软件交付的时间窗口. 传统上持续2到4周,迭代可能短至1周或 只要 3个月. 在性质和定义上类似于“冲刺”.”

J

K

看板

基于精益软件开发原则的敏捷开发的概念性方法. 看板有三个主要组成部分:管理工作的可视化系统, 限制正在进行的工作, 而功是拉出来的,而不是推过来的.

L

精益

这是一个总称术语,指的是通过持续改进的可持续文化,使客户价值最大化,同时减少浪费,实现持续流的技术. 精益是一个在美国使用的术语.S. 最初的“丰田生产体系”. 又称精益办公、精益生产、精益思维、精益企业等.

M

N

O

P

结对编程

两个开发人员在一个工作站上一起工作的过程, 一个负责输入代码,另一个负责检查输入的每一行代码.

规划扑克

A consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in software 发展. 规划扑克有助于建立团队凝聚力和培养自组织团队.

产品待办事项列表

用户描述和缺陷的优先列表,按对系统的价值从高到低排序. 积压包括功能性和非功能性用户描述以及技术团队生成的描述. 产品负责人所有.

产品负责人

一个源自Scrum的角色,但现在已经独立于Scrum被广泛采用. 产品负责人管理产品待办事项列表, 解决开发过程中出现的问题,并签署工作结果. 产品负责人指导团队应该做什么,以及何时应该发布最终产品.

Q

R

重构

持续改进可用性的实践, 可维护性, 以及代码在不改变其行为的情况下的适应性. 一个缺点是它需要额外的工作,并且需要更改代码. 重构有时被用作减少技术债务的一种方法.

释放

从开发团队到客户日常使用的潜在可交付产品的增量. 发布通常发生在一个或多个sprint已经导致产品有足够的价值超过部署成本的时候. 一个版本根据日期承诺平衡功能、成本和质量需求.

回顾

在每一个sprint结束时召开一次会议,以反映在这个sprint中什么进行得很好,以及在下一个sprint中什么可以改进. 冲刺回顾被认为是检查和调整的必要部分,并允许开发团队计划未来的输出.

S

Scrum

敏捷开发项目管理框架最初是为了指导复杂的软件项目而开发的. 该框架通过将大量工作分解为几个较小的块,这些块在称为sprint的小时间窗口中工作,从而适应了复杂性. The framework defines three roles; the Scrum Team, 产品负责人 and Scrum Master. Scrum将大部分开发决策留给了自组织的Scrum团队, 项目决策是由团队达成共识的.

Scrum Master

接受过培训以促进日常Scrum会议的人员, 移除障碍, 监督团队在流程中的进展,跟踪Scrum团队的更新. Scrum Master负责执行Scrum团队同意实施的参与原则和规则.

自组织的

一个团队, 通常出现在Scrum中, 它通过各种沟通手段和经常性的有组织的会议自行管理. 自组织团队作为一个整体解决开发问题,并根据输入决定最佳解决方案, 各团队成员的能力和经验.

斯派克

通过一个基本的实施实验或原型来测试新产品的可行性, 未知的, 有风险或复杂的技术解决方案. 斯派克的结果是为未来的执行决策提供信息.

冲刺

A Scrum-specific term used to describe an 迭代; although the term is widely used in other Agile approaches.

冲刺 待办事项列表

规划活动的开发团队的计划, 在即将到来的sprint中实现计划完成的用户故事的任务和劳动力估算.

冲刺计划

Scrum团队的会议, Scrum master和产品负责人, 产品负责人向团队描述优先级特性. Scrum团队对所讨论的任务有了足够的了解 能够 选择哪些要从产品待办事项列表移到sprint待办事项列表.

冲刺评审

在sprint回顾中, 团队检查在迭代过程中完成了哪些故事,并向涉众和产品所有者演示这些故事.

利益相关者

对组织价值流所产生的产品/服务感兴趣的任何一方.

利益相关者价值

利益相关者对组织价值流产生的产品/服务的兴趣的价值. 有时可与客户价值互换使用.

单口

旨在快速有效地解决任何团队成员可能遇到的障碍的每日会议. 一个站立会议不超过15分钟, 并专注于回答这些问题:“自从我们上次见面以来,你在做什么?? 在我们再次见面之前要做什么? 以及有哪些障碍或可能阻碍你实现这个承诺?”

故事点

团队实现用户故事所需的相对工作规模. 一种估算敏捷故事大小的方法,用于在数小时内估算故事. 故事点比较一个故事和另一个故事,以确定一个相对的大小,然后分配点表示该大小.

T

任务

功的离散单位. 敏捷故事被分解为一系列任务,这些任务必须在一个sprint中完成. 任务的大小通常代表4到8小时的工作.

任务板

代表当前冲刺阶段任务状态的物理或电子板, 常分为“要做”,“在进行中”和“已完成”.”

测试驱动开发(TDD)

一种结合“测试优先”开发实践的开发方法,即在编写足够的生产代码来完成测试和重构之前,先编写一个测试.

主题

一组具有共同亲和力的敏捷故事. 一个主题可能包含几个史诗和许多用户故事.

限定

限制任何活动的时间总量的做法. 例子包括迭代、峰值和站立会议.

U

单元测试

运行少量独立功能的测试,目的是验证所编写的代码满足基本验收测试.

用户故事

与敏捷方法一起用于指定需求,并自然地以非正式的需求声明的形式呈现, 各项语言. 用户故事还详细说明了满意的条件(定义“完成”)和接受标准(定义“正确完成”).

V

价值点

预期由用户故事或特性交付的业务价值的相对规模.

速度

团队的速度是与给定时间内完成的故事相关的故事点的数量 时间(通常是迭代或冲刺). 例如,如果团队完成了8个故事,每个故事都是5个点 四个星期 冲刺,然后他们的速度是每四周40个故事点.

W

瀑布

软件开发过程的模型,其中过程通过概念的各个阶段向下流动, 初始化, 分析, 设计, 建设, 测试和维护. 类似的阶段可以定义为定义需求, 设计解决方案, 开发, 测试, 和实施.

X

XP(极限编程)

“极限编程,“敏捷方法的一个实现,专注于为应用程序需求生成最简单的编码情况,并包括成对编程等实践, 增量设计和持续集成.

Y

Z

寻找更多信息?

如果你对我们的敏捷服务感兴趣, 或者寻找一个定义或扩展的术语, 给我们一个信息.

敏捷服务

咨询服务

训练

人员配备

转换服务

现在打电话

☎︎

联系