小规模 Scrum 与大规模 Scrum

我们调查了小型和大型 Scrum 团队的个人成员。以下是一些主要发现。

Two different business organization charts

图片来源

Opensource.com

在《小规模 Scrum 框架》发布后，我们希望收集关于目标受众（顾问、开源开发者和学生）团队的工作方式和他们重视的价值的反馈。借此首次机会来审视、调整并帮助塑造小规模 Scrum 的下一阶段，我们决定创建一份调查，以捕捉一些数据点，并开始验证我们的一些假设和猜想。

[下载《小规模 Scrum 指南入门》]

我们使用调查的原因有很多，但其中最主要的原因是团队的全球分布、我们办公室可用的小型本地数据样本、与客户的沟通以及行业对调查的利用（例如，Stack Overflow 开发者调查 2018、HackerRank 2018 开发者技能报告和 GitLab 2018 全球开发者报告）。

Scrum 的迭代过程被用于促进创建如下所示的调查

该调查包含 59 个问题，我们邀请您完成填写，它在当地学院 (沃特福德理工学院) 和红帽的咨询和工程团队中分发。我们的初始数据收集自 54 位分布在小型和大型 Scrum 团队中的个人的回复，他们被询问了他们在团队中使用敏捷的经验。

以下是调查的主要结果和初步发现

高达 96% 的调查参与者实践某种形式的敏捷，在分布式团队中工作，认为 Scrum 原则有助于他们降低开发复杂性，并相信敏捷有助于他们项目的成功。
只有 8% 的调查参与者属于小型（一到三人）团队，51 人中有 10 人将其典型项目描述为短期项目（三个月或更短）。
大多数调查参与者是软件工程师，但也包括质量工程师 (QE)、项目经理 (PM)、产品负责人 (PO) 和 Scrum 主管。
Scrum 主管、PO 和团队成员是项目中的典型角色。
近一半的调查受访者同时参与或被分配到多个项目。
几乎一半的项目是客户/价值创造型，而另一半是改进型/非直接价值创造型或未分类。
几乎一半的调查参与者表示，他们的工作有时或大部分时间会得到澄清，并在开发前进行预估，并且有时或大部分时间可以进行延期。他们表示，要求澄清工作项是团队的责任。
几乎一半的调查受访者表示，他们为自己的代码编写测试，并且他们遵守最佳编码实践，记录他们的代码，并在合并前对代码进行审查。
几乎所有调查参与者都会向代码库引入错误，这些错误由他们、团队、PM、PO、团队负责人或 Scrum 主管确定优先级。
当任务复杂时，参与者会寻求帮助和指导。他们还在需要时承担项目中的其他角色，包括业务分析师、PM、QE 和架构师，他们有时会发现角色转换很困难。
当每天更换角色时，个人感觉平均会损失一到两个小时，但他们仍然在大部分时间内按时完成工作。
大多数调查参与者使用 Scrum (65%)，其次是混合方法 (18%) 和看板 (12%)。这与 VersionOne 的敏捷状态报告的结果一致。
每日站会、迭代、迭代计划和预估、Backlog 梳理和迭代回顾是遵循的最重要的 Scrum 仪式和原则，团队成员在会议前会做准备工作。
大多数迭代 (62%) 为期三周，其次是为期两周的迭代 (26%)、为期一周的迭代 (6%) 和为期四周的迭代 (4%)。百分之二的参与者由于严格的发布和更新时间而未使用迭代，所有活动都围绕这些日期进行组织和计划。
团队使用计划扑克来预估（故事点）用户故事。用户故事包含验收标准。
团队创建并使用完成的定义，主要用于特性方面和确定用户故事的完成情况。
大多数团队没有或不使用就绪的定义，以确保用户故事是可操作的、可测试的和清晰的。
单元测试、集成测试、功能测试、自动化测试、性能/负载测试和验收测试是常用的测试。
团队成员之间的整体协作被认为是高度的，团队成员使用各种沟通渠道。
大多数调查参与者每周在会议上花费超过四个小时，包括面对面会议、网络会议和电子邮件沟通。
大多数客户被认为是大型客户，其中一半了解并遵循 Scrum 原则。
客户在大多数时候尊重“无截止日期”，有时会帮助创建用户故事并参与迭代计划、迭代评审和演示、迭代回顾以及 Backlog 评审和细化。
只有 27% 的调查参与者知道他们的客户对敏捷的采用感到非常满意，而大多数 (58%) 根本不知道此信息。