专业Scrum开发人员术语表

本术语表是使用Scrum和敏捷软件开发技术的软件开发团队专用术语的概述。

要了解更多关于Scrum框架的知识，我们强烈建议您参考Scrum指导™和Scrum术语表．

一个

A / B测试:通过评估两个或多个不同的实现来扩展假设驱动开发的思想，以找出哪一个工作得最好。通常这是通过不同的实现来实现的，然后将我们的一部分用户路由到每个实现。这允许度量哪个实现更好地支持预期的用户行为。A/B测试通常与特性标志和应用遥测相结合。

验收测试驱动开发:测试优先的软件开发实践，其中新功能的接受标准被创建为自动测试。失败测试被构造成随着开发的进行和验收标准的满足而通过。

应用生命周期管理(ALM):对软件应用程序和系统管理的整体观点，考虑到软件产品存在的所有阶段。

应用遥测:了解一个产品是如何使用的，是在投资领域做出更好决策的关键因素。通过显示使用统计数据、性能参数、用户工作流程和其他相关信息，应用遥测技术可以提供一些见解，以增加对这方面的了解。

B

行为驱动开发(BDD):敏捷软件开发实践在TDD中添加对新功能的期望功能行为的描述。

无可指摘的后期:是了解导致停机的系统因素，并确定可以帮助防止此类故障再次发生的学习和操作。这种做法是基于这样一种想法，即事后我们通常知道如何避免中断。但是过去是无法改变的，因此讨论谁应该做什么是没有用的，也就是指责。但这是关于通过从刚刚发生的事情中学习来塑造未来。我们能学到什么?我们如何改进我们的过程以使其更具弹性?

蓝绿色的部署:是一种在将系统升级到新版本时有助于减少停机时间的实践。它还有其他积极的影响，比如在紧急情况下的快速回滚。它使用两个相同的环境。一个环境(称为蓝色，以区别于另一个相同的环境)正在处理所有请求并执行所有生产操作。另一个环境(绿色)可以处理软件更新和配置更改，而不会影响生产。甚至测试也可以在绿色环境中毫无风险地执行。一旦绿色环境准备好了，所有请求都切换到这个环境，它就变成了新的蓝色环境。之前的蓝色环境同时变成绿色环境，可以用于下次更新。

分支:在版本控制系统中创建代码的逻辑或物理副本，以便可以独立地更改该副本。

C

干净的代码:表达良好、格式正确、组织良好的软件代码，以供以后的程序员理解。清晰胜于聪明。

代码覆盖率:指示测试执行的产品代码数量的度量值。

内聚和耦合:耦合是指模块之间的相互依赖关系，而内聚是指单个模块内的功能之间的相关性。

集体代码所有权:极限编程(Extreme Programming)普及的一种软件开发原则，该原则认为给定代码库的所有贡献者共同对整个代码负责。

持续交付:一种类似于持续部署的软件交付实践，除了需要人工操作来推动变更进入管道中的后续环境之外。

持续部署:一种软件交付实践，其中发布过程是完全自动化的，以便在没有人为干预的情况下将更改推广到生产环境。

持续集成(CI):由极限编程推广的敏捷软件开发实践中，新签入的代码被频繁地构建、集成和测试，通常是一天多次。

连续测试:传统的质量保证方法通常是在将产品交付到生产之前，在验证产品的最新版本之前完成所有的实现。相反，持续测试是将测试集成为开发的基本和持续部分的实践。它有助于更早地识别和解决问题，从而大大降低风险。如果与测试自动化、干净的代码和其他有助于减少回归测试工作的实践相结合，持续测试是特别强大的。

周期时间:是处理已经开始的项和完成项之间的时间(通常交付给真正的最终用户)。周期时间定义了工作在系统中流动的速度，最小化周期时间不仅有助于提高系统的效率，还有助于增加可预测性和快速响应更改或新见解的能力。

圈复杂度:一种基于代码库中独立逻辑分支数量的代码复杂度度量方法。圈复杂度用一个简单的整数表示。

跨职能:在Sprint中成功地产生一个可发布的增量所需的所有技能在团队中都是可用的，其中可发布指的是使软件在生产中可用。

D

“完成”的定义:对软件必须达到的期望的共同理解，以便可以发布到生产环境中，目的是为创建的软件提供透明度。由开发者管理。

开发人员:Scrum团队的任何成员，致力于在每个Sprint中创建可用增量的任何方面，而不管技术、功能或其他专长。

DevOps:在技能、思维模式、实践和筒仓思维方面，用来弥合开发和运营之间差距的组织概念。其基本思想是开发人员意识到并在日常工作中考虑对操作的影响，反之亦然。

开发和运营合作:是DevOps运动的核心。与将开发和运营分开不同，协作是关键。我们不是开发一些东西，然后让它在生产中运行成为其他人的问题，而是试图实现端到端责任。这不仅有助于使交付过程更加顺畅，而且还关闭了反馈循环。更紧密的合作加强了我们学习如何支持已经存在于设计和实现操作中的健壮操作。

DRY(不要重复自己的话):软件开发原则:避免在一个系统中重复使用相同的信息，防止在一个代码库中多次生成相同的代码。

E

工程标准:开发人员应用一组共享的开发和技术标准来创建可发布的软件增量，并根据这些开发人员可以检查和适应的增量。

错误的文化:如何处理错误对一个组织的创新能力有重要影响。如果人们认为错误是负面的，并试图避免它们，他们可能就不太可能冒险尝试新事物。相反，鼓励实验和学习是重要的，同时考虑如何控制风险和减少失败的影响。

极限编程(XP):敏捷软件开发框架，极度关注编程，并将工程实践发挥到极致，以创建和发布高质量的代码。与Scrum框架高度互补。

F

特色旗帜/功能切换:允许动态地打开或关闭(部分)功能而不影响用户对系统的整体可访问性的软件开发实践。

H

假设驱动开发假设驱动开发背后的基本思想是，在一个复杂的环境中，我们不知道为了实现最高可能的价值而投资在哪里:我们对此制定假设。一旦我们接受了不确定性，并同意我们的计划所基于的假设可能是错误的，那么改变开发新功能的方法就有意义了。验证我们的假设得到了高度的优先级，寻找小而快速的实验来获得更多的见解成为了工作的重要部分。

我

增量:一个功能齐全的工作软件，符合“完成”的定义，它添加到先前创建的“增量”中，其中所有“增量”的总和——作为一个整体——形成一个产品。当一个产品待办事项列表项满足完成的定义时，一个增量就诞生了。

基础设施代码:不用设置和配置基础设施和环境，这个过程可以通过脚本和参数文件自动化。虽然这种方法对于基础设施的初始设置来说并不更快(甚至可能更慢)，但它提供了许多优点。脚本和配置文件可以与软件的源代码一起存储在版本控制系统中。这允许为给定版本的软件创建精确匹配的环境。对环境的更改被记录在版本控制中，因为它们不再直接在环境上执行，而是通过更改和执行脚本来执行。可以很容易地创建生产环境的精确副本的新实例，例如用于测试目的。

米

平均检测时间(MTTD)就是发现问题的时间。MTTD不应该由愤怒的客户在热线的第一次呼叫来确定。监视工具可以帮助减少它。

平均恢复时间(MTTR):从问题发生到问题解决和系统恢复正常操作所需的平均时间。有多种技术可以帮助MTTR，如防御性编程和自修复系统，它们可以切换到紧急模式，以保持系统的基本功能正常运行。由于MTTD通常是MTTR的重要部分，减少MTTD也将有助于MTTR。

最小可行产品:实现假设驱动开发的一个实践是最小可行产品(MVP)。MVP是我们产品或功能的最小实现，它可以让我们更多地了解用户对它的反应或技术行为(如性能)

监控:显然，了解系统的当前状态是有帮助的。虽然大多数系统都支持日志记录来分析停机或问题期间发生了什么，但监视用于持续地检查当前状态。一旦一个或多个参数超出正常范围，就可以触发警报来启动一些操作

P

结对编程:由极限编程推广的敏捷软件开发实践中，两个团队成员共同创建新功能。

R

重构:由极限编程普及的敏捷软件开发实践中，代码在代码库中进行调整，而不影响代码的外部功能行为。

Release-Pipelines:自动化从代码提交到版本控制到生产中交付的步骤有助于提高该过程的速度和可靠性。这个实践通常被称为发布管道，因为它描绘了交付的稳定的变更流的理想状态。

年代

童子军规则:总是让代码库处于比修改之前更好的状态。一种迈向“干净代码”的方法。

Scrum:在复杂产品开发中支持团队的框架。Scrum由Scrum团队和他们相关的职责、事件、工件和规则组成Scrum指导™．

Scrum板:Scrum团队内部可视化信息的板，通常用于管理Sprint Backlog。Scrum板是Scrum中的一种补充实践，可以使信息可见，从而增加透明度。

Scrum指南™:Scrum的定义，由Scrum的共同创造者Ken Schwaber和Jeff Sutherland编写并提供。的Scrum指南由Scrum的职责、事件、工件以及将它们绑定在一起的规则组成。

Scrum团队:一个由产品负责人、开发团队和Scrum管理员组成的自我管理团队。

自我管理:Scrum团队是跨职能的，这意味着成员拥有每个Sprint创造价值所需的所有技能。他们还进行自我管理，这意味着他们在内部决定谁做什么、什么时候做以及如何做。

规范的例子:基于TDD和ATDD的敏捷软件开发实践，要求使用来自过去经验的现实例子，而不是在描述所需功能行为时使用未经测试的或抽象的语句。

T

自动化测试:自动化测试不仅是提高产品质量的一种方法，它还有助于减少周期时间。如果您将测试执行视为反馈的一种形式，那么自动化测试有助于更早地获得这种反馈。这降低了修复问题的工作量，并允许更快地交付可发布的增量。

测试驱动的开发(TDD):测试优先的软件开发实践，首先定义和创建测试用例，然后创建可执行代码以使这些测试通过。失败的测试被构造为在开发进行和测试成功时通过。

技术债务:通常不可预测的产品维护开销，通常是由不理想的设计决策引起的，增加了总拥有成本。可能在增量中无意存在，也可能为了更早实现价值而有意引入。

在生产测试:这个听起来非常危险的方法不仅有助于减少周期时间，还可以使您的测试更可靠。这意味着在生产环境中直接执行各种测试。为了减少因未测试的功能和失败的功能而影响生产操作的风险，可以使用各种技术使新功能只对测试流程或一小部分用户可用，而其他用户将使用以前的功能。一旦测试成功，更改将向所有用户推出。这种做法将帮助你摆脱各种测试阶段，如QA, UAT，分期等。由于测试在真实的生产环境中运行，您可以消除使用行为与生产环境稍有不同的测试环境的风险。

U

用户故事:从极限编程的敏捷软件开发实践，从最终用户的角度表达需求，强调口头交流。在Scrum中，它通常用于在产品待办事项列表中表示功能项。

单元测试:低层次的技术测试，关注于软件系统中可以独立快速执行的小部分。“单元”的定义和边界通常取决于上下文，并由开发人员商定

V

速度:一个可选但经常使用的指示，在Sprint期间转化为产品增量的产品待办事项的数量。它由开发人员跟踪，以便在Scrum团队中使用。

垂直团队:在传统的组织中，有许多不同的团队和部门参与到从客户提供反馈或建议改进到向客户交付新版本的过程中。销售和市场，产品管理，开发，质量保证，运营等等。但是每个不同的部门或团队都意味着有一个交接。交接往往是缓慢和容易出错的。相反，垂直团队结合了所有必要的能力来处理端到端整个过程。在这种情况下，团队通常只负责整个产品的一小部分。因此，这种方法不是将组织划分为水平层(部门)，而是建议将产品进行切片。