敏捷词汇表
敏捷词汇表
A
Acceptance Criteria (AC)接收标准（验收标准）
- 产品负责人从业务或干系人角度定义的外部质量特征。接收标准定义期望的行为并用于判定PBI（产品待办列表条目）是否开发完成。
- 为了让用户、客户或其他权威机构认可，组件或系统必须满足的退出标准
Acceptance Test 接收测试
- 验证是否满足接收标准的测试过程。
- 一种测试，定义每个PBI必须交付的业务价值。接收测试可以验证功能需求或非功能需求，如性能或稳定性。这种测试用来帮助指导开发过程。
- 针对用户需求和业务流程的正式测试过程，执行此过程以确定系统是否满足接收标准，并且使用户、客户或其他授权的实体能够决定是否接受此系统。
Acceptance Test Driven Development (ATDD) 接收测试驱动开发
一种技术，在开发过程开始之前，参与者使用实例讨论接收标准，然后将其分解成一组具体的接收测试。与“实例化需求(Specification By Example)”同义。
Accountability 责任担当
教练信任教练对象，并通过双方从开始就共同设计的架构和方法，以不带主观臆断和责备的态度，使教练对象在思考、学习或行动的过程中对自己的发展进程和目标负责。教练以“每个人都要对自己的发展b负责”的心态来协助教练对象建立起对自己的责任担当系统。建立责任担当的问题包括：“你会怎么做？”“什么时候？”
Adaptation 适应（调整）
经验式过程（Empirical Process）的三个支柱之一；适应是一种反馈，用来对正在开发的产品或产品开发过程进行调整。另外可以参阅“经验式过程”、“检视”和“透明”。
Agile 敏捷
- 敏捷宣言中表示的一组特定的加个管和原则。参见敏捷宣言网站。
- 泛指，用于指代一组相关的增量式迭代开发方法。Scrum是一种敏捷开发方法。另请参阅“极限编程”、“看板”和Scrum。
Artifact 工件
在产品开发过程中产生的实际附属物。如产品待办列表、冲刺待办列表和潜在可交付的产品增量都是Scrum的工件。
B
Boy Scout rule 童子军原则
- 离开营地时，总是做到比发现时更干净。如果地上脏乱，不管是谁弄脏的，都清理干净。
- 每次在一块代码区工作，离开时总是要把代码整理得比你动手时更干净，而不是弄得更乱。
burndown chart 燃尽图
一种曲线图，横轴是时间（如迭代内的每天），纵轴上是迭代内剩余工作量。随着时间的推移，剩余的工作量越来越少，图表上的一般趋势是工作量燃烧到0.通过计算趋势线，可以在燃尽图上显示对应的产出，从而了解工作什么时候可以完成。如下图：
burnup chart 燃烧图
和燃尽图相对。一种曲线图，用来显示逼近目标的工作进度，纵轴上标有目标值。随着时间推移，工作逐渐完成，进度线条逐步上升并接近于目标线。在燃烧图上，我们可以通过计算趋势线显示对应的产出，从而了解什么时候可能完成。如下图：
C
cadence 节奏
规则的、可预测的节律或心跳。具有一致持续时间的冲刺，为每一次开发工作建立节奏感。
chaotic domain 混乱域
- 需要快速响应的一种情况。我们深陷危机，需要立即采取行动，以防止损失扩大化并至少需要重新建立一定的秩序。
- Cynefin框架中域的一种。请参阅“繁杂”、“复杂”、“简单”域。
commitment 承诺
把自己和行动过程绑定在一起的行为。Scrum鼓励承诺。承诺意味着无论顺利与否，每个团队成员都专注于达成团队的共同目标。
Component Team 组件团队
专注于创建组件的团队，这些组件从属于客户想要购买的大型产品。组件团队创建软件资产或组件，其他团队可以重用并组装成有价值的客户方案。与特性团队相对。
confidence threshold 信心门限（临界值）
- 构想（产品级规划）的完成的定义。
- 为了能有足够的信心来决定是否投资继续进一步开发，这是决策者需要的信息。
Continuous Integration 持续集成
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。持续集成 from o Martin Fowler
Cost of Delay (CoD) 延迟成本
与拖延工作或延误里程碑相关联的财务成本。延迟成本强调“时间有财务成本”的概念，而且为了能做到经济合理的权衡，了解这个成本很重要。 > 延迟成本是“传达时间对我们希望实现的结果的影响的一种方式”。更正式地说，它是总期望值相对于时间的偏导数。延迟成本结合了对价值的理解以及该价值如何随着时间流逝而流失。更简单地说，就是对以下问题的答案：“如果延迟1个月，我们要花多少钱？”。或者，“如果我们能提前1个月得到这个，对我们有什么价值？” – 来自维基百科
cross-functional team 跨职能团队
一个由所有职能技能（如UI设计、开发者、测试人员）及完成工作所需要的多个专长成员所组成的团队。可以参看“特性团队”
D
daily scrum 每日站会
开发团队每天执行的一个同步、检视与调整的计划活动。每日站会属于Scrum框架中的核心实践，时间长度限制在15分钟以内。
DEEP原则
缩略语。产品待办列表是Detailed appropriately, Emergent, Estimated, Prioritized，即详略得当、涌现的、经过估算的、按照优先级排序的。由Roman Pichler和Mike Cohn发明的，表示一组用于评估产品列表质量的标准。
defined process 定义好的流程
具有明确定义的一组步骤的过程。假如有相同的输入，定义好（预定义）的流程每次都会产生相同的输出（在确定的变化范围内）。与之相对的是“经验式过程”
definition of done 完成的定义
- 在冲刺（sprint）结束时，团队宣布 他们的工作成果能够变成“潜在可交付”之前，团队期望成功完成工作的检查列表。最小的完成的定义应该是能产生产品功能的一个完整切片，它应该是经过设计的、已经构建好的、集成过的、测试过的并且提供了相应的文档，最终会交付经验证的客户价值。
- 该术语有时用来描述应用与所有PBI的验收标准，即通用的验收标准。
definition of ready 准备的定义
一个包含条件的检查列表，在sprint计划过程中，认为一个产品待办列表已经准备好，可以b放入冲刺（sprint），那么这个检查列表的条件需要满足。该术语不是所有的CST（Certified Scrum Trainer）都认可，因为存在过度准备的风险。
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
赞助
有了你的赞助，Bob会继续更新本页面，以及敏捷问题集
以太赞助：0x521aacB43d89E1b8FFD64d9eF76B0a1074dEdaF8
