Scrum团队的敏捷度如何？

我今天遇到的大多数团队都很敏捷。 或者，所以他们宣称是。 所有这些团队都做Scrum，这使他们变得敏捷。 是不是

如果我回顾一下敏捷宣言所基于的12种实践（简称：敏捷实践），我得出的结论是Scrum重视一个子集：计划游戏，现场客户，小发布和整个团队。

尽管我的团队确实重视这种做法，但是我遇到的大多数执行Scrum的团队都没有现场客户。 此外，我主要看到开发人员和质量保证人员正式分离，而且这些团队经常使用大型版本（超过几个月）。 从好的方面来说，大多数团队使用持续集成，并有一套编码标准，通常是正式的。

在12种敏捷实践中平均应用3种使我感到奇怪。 这些团队真的敏捷吗？ 也许它们只是“小敏捷”。 那是东西吗？

敏捷原则

让我们看一下《敏捷宣言》背后的原理 。 第一要务是“通过尽早并持续交付有价值的软件来满足客户”。 紧随其后的是（即使在开发后期）接受不断变化的需求的重要性，以及认为工作软件是进度的主要衡量标准的观念紧随其后。

这些计划似乎可以通过带有用户故事的计划游戏得到支持，首先执行最有价值的故事。 这样，客户可以从每个冲刺中获得最大价值，对吗？ 没错，但我相信还有更多。

尽管有价值的软件非常重要，但我认为关键在于软件的早期和持续交付。 我们通过更改和扩展软件来增加价值。 这就是计划游戏和用户故事无法帮助我们的事情。 但是敏捷原则高度重视更改软件。

其余的敏捷实践

因此，有一些敏捷实践可以支持我们更改软件，使我们能够适应需求的变化。 这些实践包括验收测试的自动化，测试驱动的开发，结对编程，简单的设计和重构（不按任何特定顺序）。

我想知道，如果Scrum团队不遵循其他任何实践，他们将如何保持敏捷原则。 我已经看到团队通过要求“重构冲刺”来清理他们制造的混乱来响应新要求。 因为没有其他方法无法合并这些更改。 几年前，我曾经在这样的团队中工作过。

我不会说团队不遵循大多数敏捷实践就不可能连续交付有价值的软件。 但是我确实想知道它们怎么可能。 我的意思是，如果没有简单的设计并不断保持代码的清洁，即使在创建代码后的几个月内，代码的更改程度又如何？ 当缺乏稳定的单元和验收测试套件时，是什么引起了经纪人功能的标记？

因此，如果没有大多数敏捷实践，您真的可以稳定，持续地交付价值吗？

Scrum

我认为Scrum不应归咎于此。 不要误会我的意思。 我喜欢Scrum。

Scrum主要体现了极限编程（XP）的计划和管理规则。 我相信这要归功于Scrum，许多计划和管理实践已成为当今的主流。

仅仅是因为Scrum不包括其他敏捷实践，所以许多从事Scrum的人们认为这些都不重要。 我见过的最成功的团队在其他敏捷实践中也都做得最多，即使不是全部。 对于Scrum团队来说，这也是完全可能的。

您的里程可能会有所不同

在过去的几年中，我一直在尝试不同的方式来编写软件，但是每次我回到敏捷实践时，我都会发现它们最有效。

当然，您的里程可能会有所不同。 如果您使用不同的实践来更好地支持敏捷原则，那么我很想听听他们并亲自尝试。

翻译自: https://www.javacodegeeks.com/2014/04/how-agile-is-a-scrum-team.html