敏捷正迅速成为各行业行动、行为和工作的主流方式，因为它们寻求提高效率、最大限度地降低成本并增强员工能力。大多数软件开发人员自然而然地以这种方式思考、行动和工作，近年来，向敏捷软件方法靠拢的步伐加快了。
VersionOne 2018 年的《敏捷状态报告》显示，scrum 及其变体仍然是最流行的敏捷实施方式。这部分归因于近年来对《Scrum 指南》措辞的修改，使其更适用于非软件行业。
该指南还改变了对实施 scrum 所需团队规模的立场：之前推荐的 7±2 人团队规模更改为 3-9 人的范围。
与敏捷一样，规模是 scrum 中的热门话题，各种相互竞争的框架争夺霸权。扩展框架侧重于允许多个团队以无缝方式进行协调，本质上是在大规模上推广 scrum。然而，缩小规模（低于建议的最小团队规模）并没有受到关注，尽管这是许多行业的运作方式。
例如，有偿咨询工作通常涉及一两个人从事短期项目；由于顾问费用通常按小时或天收费，因此较小的团队为客户提供最大的价值。开源贡献者通常独自工作，尽管他们是更大社区的一部分。而完成毕业设计或研究作业的大学生通常以单人模式工作，在某些情况下会组成小团队。
所有这些形式都可以遵循敏捷的工作方式。Scrum 的原则和执行已应用于小规模团队；然而，它们的应用方式往往会导致某些东西被忽略。根据我们的经验，那就是质量。我们着手调查是否可以在团队规模缩小的情况下保持高质量和产出。
什么是小规模 Scrum？
我们研究的结果是小规模 Scrum，这是敏捷领域中一个期待已久的新概念，“支持计划、开发和交付生产质量的软件解决方案”。在这种情况下，“小规模”最多为三人。一项广泛的调查显示，这是行业、客户和小型开发团队一直在要求的，因为这种团队规模更符合他们的需求。由于行业普遍认可这种方法的效率，从事咨询项目的组织尤其要求找到使用一到两名开发人员运行 scrum 项目的方法。鉴于 scrum 已修改其指南以包含非软件行业，这种方法可能会使许多不同的行业受益。
在本指南中，我们将解释小规模敏捷——它是什么、如何工作以及如何帮助小型团队更好地工作。在未来的文章中，我们将介绍小规模敏捷宣言、框架和原则，并描述我们的调查结果以及下一步的方向。
1 条评论