Scrum
由 Jeff Sutberland 和 Ken Schwaber 开发的一种流行的敏捷方法论，主要角色包括同项目经理类似的 Scrum 主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
Scrum of scrums scrum 合作会议
多个 Scrum 开发团队参加的会议，参会人员通常是 ScrumMaster 代表 Scrum 合作会议会讨论各团队的开发进展。并协调多个团队之间的工作，该技术通常用于超大规模的Scrum 项目。对于这种项目其开发团队必须再分为较小团队。
Scrum Master（考试时翻译为： Scrum 主管， 试题两种说法都会覆盖）
Scrum 方法论定义的三种角色之一， Scrum Master 负责帮助团队遵循 Scrum 过程。
SDLC
系统开发生命周期的缩写。 SDLC 是一种非敏捷的，瀑布式开发方式，规定项目应该以对当前前期计划浓墨重彩的长周期方式来进行。
Self-organization 自我组织
敏捷理念之一，指团队不应该被管头管脚或指手画脚，而应该以更有机的方式来构成。
Servant Leadership 服务式领导
敏捷领导力原则之一，指出领导人角色，采用服务团队的方式进行领导效果最好，服务式领导方式奉行己所不欲，勿施于人。
Spike 探测（考试翻译为“小试验”，习题都会覆盖）
帮助团队回答问题并决定前进方向的快速试验。
Sprint 冲刺
Scrum 项目持续一周到一个月的一次迭代。
Stakeholder 干系人
任何与项目利益相关的人，无论影响是积极的还是消极的。
Stakeholder management 干系人管理
让干系人知晓项目最新进展，与干系人进行沟通并满足他们要求的过程。干系人管理始自正确识别干系人。敏捷项目重视干系人的参与。同时利用干系人的专长和精力为项目服务。
Standardized test 标准化测试
同一位参试人员每次考试结果都相差无几的一种测试。标准化测试的目标是形成这样一条结果曲线，即只允许预定百分比的参试人员通过测试。标准化测试的目的是衡量知识掌握程度和理解程度。
Story Card 故事卡
写有用户故事的一种索引卡（参见“用户故事”）。采用索引卡的形式是为了限制细节数量和提前计划团队如何应对。
Story Map用户故事地图
一组未交付，积压的故事，可以根据用户功能来拆分和组织，目标是设定正确的开发优先级。
Story Point 故事点
表示用户故事难度估计（所费功夫）的测量单位。故事点可以用小时数、天数、衬衫尺寸或裴波那契序列（参见裴波那契序列）中的数字来表达。
Sustainability 可持续性
可无限期维持的一种团队节奏或速度。敏捷团队要避免再一次迭代或发布末尾出现时间紧迫的情况，相反要尝试保持一种紧张但平稳的节奏。
Swarming 蜂拥式
整个团队专注于单个用户故事的一种敏捷合作技术。蜂拥式可用于整个产品未完项或仅用于
单个有难度的故事。
Task 任务
也称为工程任务，是对工作一种较小的划分。有单人承接，而且通常能迅速完成。任务是比用户故事更小的一种划分，而且不像用户故事， 任务可能会交付价值给客户，也可能不会。
Team 团队
经过授权的个体组合，共同为项目向客户交付价值而负责。
Technical Debt 技术债务
团队选择目前暂时不实施的技术决策，但如果一直不做最终会成为阻碍。例如，团队开发代码时选择走捷径，及时这条捷径并不符合组织规定的编码标准，这样做就会产生技术债务。
Test-Driven Development 测试驱动开发（测试先行开发）
一种有利于敏捷的开发实践，先对模块的验收测试进行定义，在编写模块代码，这样代码将围绕着通过这些测试而构建，只要写对代码就必然应该通过测试。
Tester 测试员
极限编程方法论定义的角色。帮助客户定义验收测试，然后周期性检查产品，是否通过验收测试，并就测试结果和相关人员进行沟通。
Theme 主题
一组故事，一次迭代或一个版本背后的主要目的。有产品负责人或客户来确定主题，同时得到团队的一致同意，例如，某位产品负责人确定某次迭代的主题为“报告”或“连通性”，这种情况下为这次迭代所选择的用户故事都要围绕该主题展开。
Timeboxing 时间盒（时间箱）
设定一个固定的交付日期来约束项目或版本发布，然后在进度允许的情况下实现尽可能多的交付价值和功能开发。
Tracker 跟踪员
极限编程方法论中定义的角色，在项目中衡量团队的工作进展，据此进行沟通，团队的跟踪员会追踪迭代计划和发布计划的执行情况及测试工作进展，通常会将跟踪结果公布于信息发射源。
Traditional Management 传统管理方式
敏捷语境中的一种参照，指自上而下或瀑布式的项目管理方式，强调详细计划，执行和控制，开发周期较长，通常客户较少介入团队工作，传统项目中，团队是被动管理型，而非自我组织型。
Transparency 透明度
敏捷项目的价值观之一，体现方式是展现团队每位成员手头的工作，同时每人的工作进展让团队其他成员都能看到。
User story 用户故事
一个或多个给用户增加价值的商业需求，撰写用户故事所需的工作量相对较小。典型做法是将用户故事记录在故事卡上。
Validation 确认
确保产品会被客户所接受的过程。
Value 价值
寻求如何为客户增加价值是多数团队决策的驱动力。
Value Stream Mapping 价值流程图
以消除浪费为目标的分析一连串流程的方法，目的是通过映射使分析师更深入的了解系统。价值流映射法是精益的一种技术，用来分析系统中的材料和信息流转，并识别和消除其中的浪费。
Value-based Prioritization 基于价值的优先级
让产品负责人或客户基于功能的交付价值来决定哪项功能先开发的一种做法，同样也应用于项目论证概念中。
Velocity
一次固定迭代中团队可以交付的需求数据或用户故事树
Verification 核实
确保产品符合规范的过程
Virtual Team 虚拟团队
地理上分散在各处的团队。虽然敏捷项目偏好团队集中办公，但很多时候虚拟团队的方式更切合实际。虚拟团队使得项目沟通及其他很多方面变得更加困难。
Visbility 可视性
每位团队成员的工作及进展应该对所有利益相关的干系人保持透明的理念。工作及进展应该公开展示，让每个人都能看到。
War Room 作战室
整个团队聚集于专属空间一起工作的一个地方。作战室有助于促进沟通，形成团队意识，以及避免出现孤岛。
Waterfall 瀑布式方式
一种传统的、非敏捷的管理哲学，偏好项目前期进行详细计划，紧接着是很长一段执行和控制期。瀑布式开发方法论以抗拒需求变化而知名。
Wideband Delphi Estimating 宽带德尔菲估计法
团队成员聚在一起演示用户故事，讨论面临的挑战，然后私下进行估算的一种估计技术，每个故事的估算结果都会被匿名标注在图表上，然后团队就故事点范围进行讨论，并尝试达成普遍共识。
Wireframe 线框图
一种轻量级的、非功能性的用户界面设计，展示了主要的界面元素及其如何交互。团队无须编写代码，通过线框图就可以传递给用户有关系统如何工作的概念。
Work-in-progress（ WIP）过程中工作（在制品）
已着手进行开发的需求或任务。 WIP 通常会在信息发射源上公开展示，其进展也会随着工作流的进行而同步展示。
Workflow 工作流
开发过程中一系列一致同意且被团队遵循的工作阶段。例如，如果某团队决定每项任务都要经过下述阶段：启动、设计、编码、测试，集成和完成，那么这一系列阶段就代表了该团队的工作流。
粤公网安备 44010602010970