困扰开发人员使用 Scrum 的 9 个实践

Scrum承诺要解放开发者：它是对定义许多瀑布项目的命令和控制做法的彻底转变。
Scrum是关于自我管理的团队和可持续的步伐。它应该是一种 "高贵的体验"（Agile Software Development with Scrum (Schwaber and Beedle), 2001）。

世界上充斥着Scrum培训师、敏捷教练和Scrum大师，他们传播着自我管理Scrum团队的信息，由他们决定做什么和何时做。

但是对于许多Scrum团队来说，现实是非常不同的，开发人员也深受其害。许多人觉得没有什么变化。事实上，有些人认为Scrum比瀑布更糟糕。

以下是困扰使用Scrum的开发人员的9种做法：

1、每个Sprint的紧缩时间
在Scrum占领软件开发世界之前，组织通常使用传统的项目管理方法。通常被称为 "瀑布式"。

瀑布式项目通常有详细的长期计划，没有反馈回路来检查产品的增量。瀑布项目通常在旅程结束时有一个紧缩时间。在项目的最后几周，团队往往会被逼到超出其可持续发展的极限，按照计划交付。

尽管有所有的承诺，许多Scrum团队面临的紧要关头要多得多，几乎每个Sprint都有。团队会在高压下用多日加班来结束Sprint，以 "按承诺 "交付。这种情况比传统项目中偶尔出现的紧要关头更糟糕。

Scrum不应该是这样的。团队不应该担心每个Sprint都要按计划交付。他们应该专注于找到实现其目标的最佳方法。而不是按照承诺来交付。然而，这仅仅是理论上的。

实践中，许多团队都受到紧缩时间的困扰。

2、故事点的误用
在我所知道的（数百个）Scrum团队中，大多数都使用故事点。他们中至少有一半人在为故事点挣扎。故事点的最初想法是摆脱以小时为单位的估算，使估算更容易。但这并不奏效。

故事点经常被误用。特别是因为它们是数字，可以用于计算。例如，在Sprint中完成的项目的点数之和--称为速度--通常被认为是显示团队的能力。而这就打开了一个麻烦的缺口。

首先，不同团队的速度可以被比较，速度较低的团队将不得不为自己辩护。许多Scrum领域之外的人不明白，每个团队都有自己的定义，什么是 "5"，什么是 "13"。所以你不能比较不同团队的速度。

其次，管理层经常希望看到速度的增长。速度成为成功的主要指标，而不是产品的增量是否带来预期的价值。但同时，团队也会专注于在每个Sprint做更多的工作，而不是专注于 "简单--最大限度地减少未完成的工作量的艺术"（《敏捷宣言》原则）。但团队也可以夸大他们的故事点。过去的 "5 "现在会被定义为 "8"。

滥用故事点的例子还有很多。它们的底线是，故事点代替了产品，成为了关注的中心。这的确是一种反模式，但却很常见。

Scrum并没有告诉你如何估算。事实上，如果你根本不想估算，Scrum也允许这样做。但是，这也只是理论。告诉那些强迫团队提高速度的经理吧。

3、为 "完成 "冲刺而偷工减料
令我难过的是，我认识的许多团队认为按计划交付很重要。这完全忽视了一个事实，即Scrum旨在用于复杂的环境中，你不知道会发生什么，甚至在Sprint中也不知道。

在他们应该按承诺交付的想法下，他们有时会觉得倾向于偷工减料。例如，有几次，团队告诉我他们跳过了测试的最后部分，以 "完成 "Sprint。

Scrum团队不应该专注于交付他们计划要交付的所有项目。他们应该专注于为Sprint设定一个目标，并找到优化的方法来实现这个目标的机会。

4、产品负责人的独断专行
另一个常见的问题是产品拥有者如何对待他们的团队。我很同情那些被产品负责人置于压力之下的开发者，因为产品负责人告诉他们应该做什么，而且还经常让他们承受交付的压力。

这是否与问责制的名称有关，我不知道（产品所有者），但与这些给开发人员施加压力的人的想法相反，他们在等级制度中并不比开发人员高。

Scrum团队应该是自我管理的。他们应该决定他们将做什么，如何做以及何时做。产品负责人是Scrum团队的成员之一。他们的具体职责是管理产品Backlog。

但是开发人员应该负责在Sprint期间发生的事情。他们应该负责他们在一个Sprint中能做多少事情，以及如何实现Sprint目标。这根本就不是产品负责人的职责。

5、无用的事件
Scrum 事件对开发人员来说可能毫无用处。例子是：

• 日常 Scrums 只是状态会议，没有添加任何有用的东西；
• Sprint 回顾只是抱怨会议，因为实际的改进问题不在团队的控制范围内，所以没有任何改变；
• Sprint 评审没有利益相关者在场。

• 他们本可以利用这段时间做一些有用的事情。
• 他们的流程被打乱了。当被打扰时，需要时间才能重新回到工作流程中。因此，即使每天 15 分钟，开发人员的时间也会减少 30 分钟。
• 毫无意义的会议会损害团队的凝聚力。开发人员变得疏远，因为团队一起做的每一件事（事件）都会伤害他们个人。
• 挫败感越来越多，因为开发人员被迫做一些没有给他们带来任何好处的事情。

6、外部依赖
Scrum 团队应该努力在每个 Sprint 中至少有一次产品的工作增量。这个增量是 Sprint Review 检查的输入。我经常看到并体验到团队由于外部依赖性而无法做到这一点。

当团队依赖某人做团队之外的事情时，就会发生外部依赖。这可能是数据库管理员更改表，UX 设计人员在...UX 上创建更新，安全人员按下批准按钮，或者来自另一个团队的开发人员是某段代码的专家。

没有什么比让整个团队停滞不前更令人沮丧的了，因为他们正在等待团队以外的人，他们的优先级不同。

Scrum 团队应该是跨职能的，这样他们就不会依赖团队以外的人。但是，有多少团队在没有这些令人沮丧的依赖性的意义上是真正的跨职能团队？

7、发布列车
越来越多的Scrum团队作为SAFe机器的一个齿轮在工作。他们是发布列车的一部分。发布列车放大了我已经提到的许多问题。他们引入了更多、更长的会议，更多的依赖关系，更多的固定在速度和故事点上，甚至更多的关注于交付承诺的东西。

在PI规划中，团队必须提前规划多个Sprints，并考虑到其他团队的规划。尽管他们的环境很复杂，你不知道会发生什么。

他们创造的规划会在每个Sprint中困扰着他们，唯一的办法就是坚持他们在发现事情的实际运作之前的几周和几个月形成的想法。但这些见解可能会使火车出轨，所以要忽略它们。

另外，在所有这些依赖性和承诺的情况下，可持续的步伐是一个白日梦。

Scrum不应该是SAFe的一部分。但对于许多Scrum团队来说，现实是不同的。SAFe有效地吞噬了Scrum并使其成为他们自己的东西。它把Scrum变成了一个无法辨认的怪物。

8、在Scrum团队之外没有Scrum的思维方式
我所经历的痛苦情况之一是成为敏捷岛的一部分。我的团队是18个拥抱敏捷的Scrum团队之一，旨在将其发挥到极致。抱着这样的观念：复杂的环境需要不同类型的行动，而不是传统的长期详细计划或命令式管理。

我们知道自我管理和经验主义是多么重要。但我们的利益相关者和管理层并不关心，也不可能关心。每当我们反对详细的计划，或想与利益相关者讨论我们的学习成果时，我们都会遇到不理解甚至是蔑视。

我们是梦想家，不知道在 "现实世界 "是如何运作的。而他们知道，按照他们的说法。我们试图接受Scrum或其他敏捷方法，被认为是有魅力但很天真。

处于这种境地的开发者们处境很糟糕。他们知道事情可以变得不同，但却没有权力带来改变。不，他们被忽视了，如果幸运的话，他们会被留在他们的Scrum岛做他们的事情。只要他们不想从不在岛上的人那里得到哪怕是最低限度的投资。

9、交付而不是发现
Scrum是一个发现框架。它的目的是通过交付小块的工作产品和检查，从中学习来发现创造价值的最佳方式。所有这些都是因为Scrum的目的是在一个复杂的环境中使用，你不知道会发生什么。

但是这种观念已经到处落地了。无数的Scrum团队只把注意力放在交付上。当团队把东西带到生产中时，他们会很高兴，因为这就是成功。

但是仅仅交付功能并不是成功。真正的成功是在功能真正提供附加值的时候。例如，当人们使用它并且对它感到满意的时候。或者当这个功能提高了产品的性能。

间接来说，对功能的关注伤害了开发者。因为忽视了解一个产品的增量是否真正带来了价值，会导致将精力投入到原来根本没有用的东西上，或者需要比原来更多的返工。

开发人员由于缺乏发现而遭受到团队的低效率。

总结
Scrum已经有近30年的历史了，但它仍然给开发者带来了很多痛苦。虽然我所列举的例子都不是Scrum的本意，甚至也不符合Scrum的精神，但它们还是发生了。

因此，Scrum的形象有问题，它承诺为开发者提供解放，但却成为了一个监狱。

我可以想象，当开发者听说他们需要使用Scrum时，他们会感到很反感。如果我可以给你一个建议，当你处于这个位置时：当你注意到组织的其他成员对敏捷性一无所知，并且不想朝这个方向发展时，就站出来反对使用Scrum吧

网友讨论：
1、一旦尝试了看板，就很难再回到 Scrum。我希望我现在的团队改用看板。

2、大多数公司实际上都在使用看板，只是他们称之为“scrum”，每两周他们就会将事情推向一个新的“冲刺”

3、没有“最佳方法”，它完全取决于你的团队所做的工作类型、工作的临时性、利益相关者的参与程度以及你需要从他们那里获得多少知识等。

4、故事点根本不适合看板。在看板中，“速度”相当于周期时间，即任务开始（和/或进入看板）与任务完成之间的时间。自然地，要使看板正常工作，您需要良好的状态管理。
换句话说，看板针对消除障碍进行了优化，重点是在没有障碍的情况下快速完成工作项目，而不是完成最多的事情。使用 Scrum，即使您的工作项目在您的董事会上搁置了三个月，您也可以获得非常好的速度。在看板中，这类项目确实会影响您的周期时间。在任何一个系统中，将那个项目放在你的板上都是明显的功能障碍。

5、故事点实际上是一个愚蠢且无用的概念。世界上每家公司、每个部门，甚至工程部门（不是软件部门）都使用实时指标。所有公司都会立即获取您的故事点并通过代数将它们转换为时间指标。你可能会说他们这样做很愚蠢，但他们的要求是时间估算。是软件行业决定使用糟糕的时间估算版本，而不是它们。

6、我最近遇到的关于 Scrum 的最大问题是产品所有者滥用实践，特别是将他们编写的任务进行改进。

7、每日站立就像飞行员在飞行前绕着飞机走动：在一个好的公司里，绝大多数时间，它是“毫无意义的”。

8、在站会期间，我讨厌的是当每个人都回复主持站会的人（通常是团队领导、scrum 主管或其他人）时，就好像在报告或证明他们如何度过他们的时间一样。但这不是站会的重点——你是在告诉团队的其他成员你在做什么。这是进行协作的机会，或者是某人提出他们是否需要帮助或志愿帮助的机会，因为您缺乏或独特的知识可能会有所帮助。如果你们在一起工作得很好并且沟通良好，那么您甚至可能不需要开会，但如果不是这样，那么开会也不是一个坏习惯。

9、Scrum 在这一点上基本上是一个教派。追随者盲目地遵循它并获得认证就像这是某种仪式一样。他们不能批判性地思考它只是接受它是怎样的。他们认为这是一个完美的过程，如果它不起作用，那就是公司错了。基本上所有公司都是这样。

10、这些事情没有银弹。没有一个你可以实施的敏捷框架会永远完美。我们从中学习，加强我们的弱点，暴露或创造新的弱点，团队的变化，环境的变化，我们接受事物作为我们的新常态，并卡在新的局部最大值。这些东西是很难的，而且往往更容易插入一个框架然后移动，陷入一个模式而不去挑战它，与一个想象中的 "瀑布 "世界相比较，并认为没有什么变化。

Scrum的使用率迅速上升，因为当时大多数行业的情况要差得多。大多数团队不是在估计未来几周的工作，他们是在估计未来一年的工作，在一堆其他部分理解和坚定估计的工作之上。经常性的流程改进通常是闻所未闻的。一些仪式，如日常工作会议，有助于缩小沟通和所有权的差距，这在当时是很正常的（与我们现在的正常情况不同）。

SAFe之所以受欢迎，是因为许多规模最大、发展最慢的组织在采用敏捷实践方面起步太晚，而且多年来一直投资于 "如果计划不成功，我们就得更努力地计划 "的方法来做事。敏捷给他们的感觉是在倒退，但SAFe的味道足够像他们多年来采用的官僚主义，同时又有敏捷和框架的洒脱，同时还能得到一些神奇的敏捷汁液。这是一种先走后跑的情况，如果你在15-20年前就在采用Scrum的团队中，然后在博客中说你在10-15年前就从Scrum向其他方面发展，那么对你个人来说，SAFe会感觉是一种倒退，但你知道如何骑车并不意味着所有人都准备好了，。

另外，许多组织并不想签署持续改进的协议，他们只想解决眼前的（认为的）问题，然后回去赚钱。每隔几年对流程进行一次重组或改造已经很正常了，要适应不断变化的做法是一个更大的步骤（需要领导力、文化建设等）。一段时间后，我们会习惯于这些好处，痛苦会更加突出，作为领导质量和纪律的某种功能，熵会消磨掉好的部分，而且会变得很烦人，但对一些组织来说，这没关系，因为他们仍然记得大规模问题X得到解决的大庆典。

11、我的简单理论是Scrum受到经理们的喜爱，因为清晨的Standups。这让他们觉得自己在做出贡献。

另外，Scrum的另一个驱动力是 "Scrum大师 "课程的普及。一个周末，你就在你的公司有了一个新的头衔，由你的公司支付。这比获得PMP证书要容易得多。

我所知道的大多数在真正的大项目上使用敏捷的公司的冲刺都是这样的：

• 冲刺1--（实施新的通信协议，用奇怪的屁股PLC）。预计2周完成。
• 冲刺2 - 完成冲刺1，预计2周。
• 冲刺3 - 完成冲刺1，预计2周。
• 冲刺4 - 完成冲刺1，预计2周。
• 冲刺5 - 完成冲刺1，预计2周。
• 冲刺6 - 完成冲刺1，预计2周。
• 冲刺7 - 完成冲刺1，预计2周。
• 冲刺8 - 完成冲刺1，预计2周。
• 第9个冲刺 - 客户要求安装。让顶尖的程序员飞到现场，把MVP塞进地方，无论如何都要让这该死的东西能够正常工作，骗过客户。

我所知道的大多数在大型项目上使用看板的公司是这样的：

进度，进度，进度，进度，进度，进度，进度，发布。进度，进度，进度，进度，进度，进度，进度，发布。进度，进度，进度，进度，进度，进度，进度，发布。进展，进展，进展，进展，进展，进展，进展，发布。进展，进展，进展，进展，进展，进展，进展，发布。进展，进展，进展，进展，进展，进展，进展，发布。进展，进展，进展，进展，进展，进展，进展，释放。进展，进展，进展，进展，进展，进展，进展，发布。

12、Scrum 只是一个迷你瀑布，经常被具有自上而下领导心态的组织滥用，这导致团队并不是真正的自我管理。我已经变得有点“真正的”敏捷，并且放弃了在乎我是否能达到冲刺目标、参加每一个仪式或评估任何事情。我宁愿建立信任并完成工作。
团队可以决定举行什么仪式。您不必每天都有样片或回答这三个问题，而只需走板，这样压力就会小得多。依赖性总是存在的，因为我经常处理的项目中的应用程序本质上是单一的，并且由多个团队开发，因此您必须协调工作。
无论如何，我相信在被称为冲刺的迷你瀑布中，我们总是可以学习或发现新事物，使我们调整我们的思维和目标，所以拥有目标可能是一件好事，但它们不能一成不变. 敏捷的时候不能死板。
Scrum 只是一个您可以构建的框架，但您必须发现为您的团队工作的最佳方式。永远不要认为这些框架就像您需要遵循的圣经才能进入一些神奇的软件开发人员天堂。这不是敏捷的真正本质。