敏捷术语表

讨论敏捷时常用的术语

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

 

A ∙ B ∙ CD ∙ EFGHIJKLMNOPQ ∙ RSTUVWXYZ

A

验收标准

判断工作项(用户情景)是否成功实现和测试的标准. A story is ‘done’ when all criteria pass 测试ing; conversely, 如果任何标准测试失败,那么故事就不是“完成”的. 也被称为满意的条件,描述了更高水平的条件, 当遇到, 交付业务价值.

验收测试

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

敏捷开发

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

敏捷宣言

敏捷软件开发宣言(Manifesto for Agile Software Development)是2001年2月编写的一份历史文档,它定义了轻量级的四个关键值和12条原则, 响应, 适应性强的软件开发.

B

待办事项列表

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

行为驱动开发(BDD)

行为驱动开发(behavior -driven 发展, 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 发展. 规划扑克有助于建立团队凝聚力和培养自组织团队.

产品待办事项列表

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

产品负责人

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

Q

R

重构

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

释放

从开发团队到客户日常使用的潜在可交付产品的增量. 当一个或多个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管理员和产品负责人,产品负责人向团队描述优先级特性. Scrum团队对所讨论的任务有了足够的了解 能够 选择从产品待办事项列表转移到sprint待办事项列表.

冲刺评审

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

利益相关者

与组织价值流所生产的产品/服务有利益关系的任何一方.

利益相关者价值

利益相关者在组织价值流所产生的产品/服务中的利益价值. 有时与顾客价值互换使用.

单口

旨在快速有效地解决任何团队成员可能遇到的障碍的日常会议. 站立会议不超过15分钟, 集中精力回答这些问题:“自从我们上次见面后你都做了些什么?? 在我们再次见面之前该怎么办? 哪些障碍或可能会阻碍你履行承诺?”

故事点

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

T

任务

一个独立的工作单元. 敏捷故事被分解成一系列必须在一个sprint中完成的任务. 任务通常被划分为4到8小时的工作量.

任务板

一块实际的或电子的板,代表当前冲刺中的任务状态, 常分为“做”,“进行中”和“完成”.”

测试驱动开发(TDD)

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

主题

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

限定

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

U

单元测试

执行少量隔离功能的测试,目的是验证编写的代码是否满足基本的验收测试.

用户故事

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

V

价值点

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

速度

团队的速度是指在给定的时间内完成的与故事相关的故事点的数量 时间(典型的迭代或冲刺). 例如,如果团队完成了8个故事,每个故事在一个 四个星期 冲刺,那么他们的速度是每四周40个故事点.

W

瀑布

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

X

XP(极限编程)

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

Y

Z

查看更多信息?

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

敏捷服务

咨询服务

训练

人员配备

转换服务

现在打电话

☎︎

联系