黑暗Scrum

Posted 2021-04-25 敏捷变革中心

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了黑暗Scrum相关的知识，希望对你有一定的参考价值。

我们来谈谈“黑暗Scrum”。至少在软件方面，Scrum似乎常常压迫人们。通常，Scrum不能像它本该的那样快速、可靠、稳定地交付。结果，每个人都在受苦。大多数情况下，开发人员比任何人都要承受更多的痛苦。

我最近很多想法背后的主题是：

我最初的“敏捷”导师Kent Beck曾经说过，他发明极限编程是为了让程序员的世界更加安全。事实证明，这个世界对程序员来说还并不安全。Scrum可能对程序员来说是非常不安全的。用Scrum的联合创始人之一Ken Schwaber的话来说:“这让我很难过”。

我很认真的说Scrum其实做得相当好，也是一个很好的框架。与决定需要做什么和需要推迟做什么的业务人员有紧密的联系是件好事。团队拥有构建产品所需的所有技能是件好事。每隔几周就构建一个经过测试的有形产品是件好事，向涉众（stakholders）展示它也是件好事，回顾工作的进展以及如何改进它们也是件好事。多年来，我一直在研究、实践和思考Scrum，关于它的一切都非常好。不是很完美，但真的很好。

不幸的是，这只是Scrum的理念，一个理想的按照预期的方式进行的Scrum。就像每一个好的理念一样，现实有时也不尽人意，有时它远远不及设想。我称之为“黑暗Scrum”。

黑暗Scrum: Scrum的一些典型滥用

让我们看看在黑暗Scrum中，事情是如何出错的，只需几个步骤。在本节中，我们将观察一个经历黑暗Scrum的团队，黑暗Scrum领导者的本意是好的，他们只是做错了。

自组织是缓慢发生的。

显然，要精通Scrum需要一些时间。它有新的角色和活动。更困难的是，它要求我们接受新的价值观。我们应该让我们的开发人员自行组织工作。我们很容易组织Scrum会议，并通过Scrum角色来称呼自己。但真正做起来却并不容易。

Scrum开始时，接受过培训的人很少，理解它的人更少。很多人认为他们知道自己应该做什么，不过如果他们做错了也不奇怪，事实上他们经常做错。

当今的掌权者常常认为他们的工作是决定人们应该做什么，告诉他们去做，并监督他们做。Scrum则不然，Srum解释需要做什么，然后退后一步，让员工自行组织去完成它。

以Scrum模式运营并不容易。忘记旧的习惯需要时间，学习新习惯需要时间，学习信任团队也需要时间，团队也需要时间来学习如何被信任，在某种程度上，这就是本文想要传递的潜在信息。Scrum的培训为接受培训的人开启了这个学习过程。

黑暗Scrum始于那些熟悉自己的旧工作，但不熟悉新工作的人进行Scrum活动的时候。它是这样的:

太棒了，我们每天都可以帮助团队！

每天，团队会聚在一起组织一天的工作。这种做法，即“每日Scrum”，典型的Scrum团队都会做。房间里可能有一个人，ScrumMaster，他被告知应该怎么做。程序员没有被告知，很多时候，甚至产品负责人也没有被告知。几乎可以肯定，其他掌权者也还没有被告知。

但掌权者已经知道他的工作。他的工作是高高在上的监督每个人都在做的事情，确保他们正在做正确的事情，否则就让他们改正。每天都有强制性的会议让他可以这么做，这是多么方便！

结果是：团队无法围绕他们的任务群策群力，整理出一份适宜的当天的工作方案。取而代之的是掌权者将信息从他们身上抽离出来，在自己的头脑中处理，然后再告诉每个人该做什么。由于事情没有像昨天早上预期的那样被完成，这种不正当的活动往往气氛紧张并充满了互相责备。

黑暗Scrum每天都会压迫团队，自组织不可能产生。

我们也有方便的频繁规划！

每个Sprint，Scrum产品负责人都应该与团队会面，并描述需要什么。然后团队确定他们可以做些什么来满足需求，并开始构建它。嗯，理论上就该这样。可实际上，甚至可能没有业务方面的产品负责人。即使有，他们可能也没有接受如何成为产品负责人的培训。

好吧，掌权者有者可能是Scrum的新手，但他们对如何处理这个问题知之甚多。因此，每两周他们就会出现并告诉这些程序员他们必须构建什么。哦，那些程序员会反击。他们懒惰，顽固。但掌权者会继续施压，因为这就是他管理人的方式。所以他们告诉团队该做什么，他们最好这样做。

当然，掌权者很少或根本不知道如何编程，程序员通常至少有一些线索。他们不知道代码的状态是什么，程序员通常都知道。程序员应该决定某项任务在Scrum中的工作量，但在黑暗Scrum中，掌权者更懂这个。他们把任务堆积起来分配，他们认为这是他们的工作：驱使团队前进。

结果永远不会改变。团队认真地尝试做被要求做的事情。他们知道无法说不可能，尽管它就是不可能的。他们只是会因为懒惰，愚蠢和制造麻烦而受到谴责，所以他们尽力而为，但就是不够好。

在Sprint结束时，结果不符合要求。魔法再一次没有发生，开发人员再次失败了。幸运的是，我们有机会直接处理这些事：Sprint评审！

我们需要批判性的评审已完成和未完成的事项

每个Sprint，利益相关者都会了解团队已达成的成果，并提供接下来相关工作的指导。伟大的理论，但在组织没有精通Scrum的情况下很少能在实践中完成。

黑暗Sprint回顾的第一步是提醒每个人团队“承诺”做什么。（也就是说，在团队说“我们会尝试”之前就提出要求。这是一个承诺，不是吗？）然后看看团队带来的可怜的失败。

你猜怎么着。组织要的比能完成的多，并且没得到满足。团队尝试了，并且在尝试时他们采取了他们能想到的所有捷径来完成所有那些不合理的请求。他们压缩测试工时，他们压缩设计工时，他们甚至在太累而无法思考时工作。

他们没有足量完成工作，已完成的工作做的也并不是很好。团队再一次失败了。

幸运的是，黑暗Scrum拥有掌权者，产品所有者和利益相关者，他们确保程序员可以完全了解他们做得多么糟糕。这肯定会激励每个人下次做得更好，在这一点上，我们有Sprint回顾！

我们要告诉他们该如何改进

在Sprint回顾中，团队回顾上一次Sprint，以及之前的历史。他们观察哪些进展顺利，哪些进展不顺利，并弄清楚如何在下一次进行改善。

在实践中，黑暗Scrum掌权者会帮助他们，提醒团队尽管他们被紧紧的管理着，但仍存在不足之处。掌权者向这些开发人员明确说明他们的失败- 这种失败 - 肯定是由于他们的懒惰和无能导致的。

为了激励团队做得更好，掌权者会不停的摇头叹息并指出不改进的后果，这总是会引起团队的注意。

有时团队会提出建议。以下是他们可能会说的一些事情，以及掌权者如何回答这些事情：

开发者：我们需要更多的测试来减少bug的数量。

掌权者：不，开发进度已经落后了。你编程的时候动点脑子。你不写bug就不需要解决它们。我们需要新功能，不是测试！

开发者：这个设计正变得混乱，我们需要重构并提升。

掌权者：不，你一开始想什么了做出这么蹩脚的设计？没人告诉你要设计的这么烂。马上收手把问题解决掉。快到周末了，就用这个周末把它解决掉。

开发者：需求不清晰，他们没有澄清需求，所以我们的工作在最后阶段被否决了。

掌权者：我们花钱雇你就是让你解决问题的。你需要自己想办法解决这些问题。别在这傻坐着了赶紧把我们想要的东西做出来。

现在你应该明白。把团队成员的鼻子放在磨刀石上磨，把脚放在火上烧，软件开发一直是这么干的。Scrum并没有改变这一点。

哎，这真是令人沮丧

嗯，当然，Scrum实际上正试图改变这一切。但是，除非组织的信念和思想真正的发生了变化，旧的管理方式依旧会频繁发生，它每隔几周，甚至每天都在发生。

作为开发人员我们能做什么？

黑暗Scrum正在滥用Scrum，他们与Scrum试图教给我们的东西明确对立。没有真正的Scrum专家会推荐任何这些做法。正在做这些事的人并没有“做的正确”。每个人都同意这一点。尽管如此，黑暗Scrum真实存在，它还经常发生。在我看来，在人们真正学习Scrum的原则和价值之前，它被滥用几乎是不可避免的。

似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。

来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。

如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。

如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。

当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！

增量的力量

Scrum要求我们在每个Sprint结束时交付一个经过测试的、集成好的、可工作的、可交付的产品增量。我们很快就会讲到如何做到这一点。现在，让我们设想我们可以做到。我们有能力每隔几周交付一个工作产品增量。

大部分的恐惧或担心会自行消失，因为领导层可以看到真正的成果。然而，还是会有某些担心，因为很可能眼前的结果和他们的预期有落差。每个人都希望有一辆跑车，但有时你只能得到一辆自行车。也许你想要一匹小马，但你只得到了一条狗。(我跑题了)。

尽管如此，只要手头有一个可靠的增量，经过测试，集成，实现他们要求我们做的最重要的功能，我们就可以改变对话:

掌权者：你做的还不够，你需要做的更多。

开发人员: 我们正在尽全力做，并将继续努力改进。与此同时，所有这些功能都是有效的，也是可用的。可能用我们实际交付的速率来预测我们的交付速度更准确。让我们先处理最重要的待办事项，让每一个代办事项都尽可能精简可能是最好的方法。

这不会马上神奇地起作用。但这将开始有所帮助，我们的产品增量越真实就越能影响人们的审视基准，并以此为基础进行管理。与我们通常认为的相反，我们的领导们并不愚蠢。他们正基于他们所掌握的信息尽全力做出做最好的决定，如果我们能以工作软件的形式给他们提供更好的信息，他们就会开始使用这些信息。这些信息会减少他们的压力。

再说一遍，这不是魔法，也不会在一夜之间发生。然而，我一次又一次地看到这种情况发生。（除了在世界上最不正常的组织中，实际上只有少数读者在那里工作）— 如果我们坚持下去，它会起作用。

这里有个要点

这件事的要点是，为了改变对话，为了减少压力和对峙，产品增量必须切实有效。它必须经过测试、集成，并潜在可发布，对所有在backlog中的待办事项都是如此。

这并不容易。更糟的是，我们没有在计算机科学中学习如何做到这一点，我们没有在软件工程中学习如何做到这一点，我们无法在IT技术学院学习如何做到这一点，我们也无法在你最喜欢的编程语言中找到它。有一些特定的实践使团队可以用增量的方式构建软件，使其测试充分、设计优良，并随时可以发布。

如果我们想要把黑暗Scrum变成Scrum本该有的样子，我们需要学习这些实践。幸运的是，它们并不难学，尽管像所有的编程一样，我们确实需要练习和努力来精通它们。在之后的文章中，我们将更详细地研究它们，但是让我们先简要地介绍一下:

验收测试

在Sprint结束时，对于团队是否构建了产品所有者“想要”的特性，存在争议是很常见的。这些纠纷很浪费资源，而且往往会让产品负责人和开发人员产生分歧。我们希望他们紧密合作，而不是互相争斗。

一个非常强大的实践是让PO和开发人员就每个故事的具体的、可执行的验收测试达成一致。把这些看作“测试用例”是有成效的。

团队: 好的，我们想让系统显示所有组织的30天的欠款以及全部欠款的总和。这是一个帐户表，另一个表显示了已标识帐户的欠款以及它们的总和。

PO: 不，不太对。我们不想展示30天的欠款，我们只想要展示超过30天的欠款。

团队: 好，就像这样？

PO：对，就这么干。

每一个小的例子都变成了故事或者待定项的验收测试。按照惯例，如果测试不运行，团队就没有完成这个故事。相反，如果测试确实通过了，产品负责人和团队就会同意我们已经完成了所要求的工作。

当然，产品负责人可能不喜欢她所看到的。但现在对话已经发生了变化。她不能合情合理的说“那不是我想要的”，因为这正是之前达成一致时她想要的。她可能意识到了一些东西，所以现在想要的有一些不同。这很好，PO的工作就是找到最好的产品。验收测试可以帮助我们理解需要什么，帮助我们知道什么已经完成了，并且帮助我们知道什么时候我们改变了想法并要求更改某些内容。

一个重要的额外好处是，当我们自动化这些测试用例时，我们可以运行所有这些用例，并确认产品仍然在做我们认为它应该做的事情。

增量式设计

在Scrum项目中，我们应该在每个Sprint之后交付一个经过测试的、有效的、潜在可交付的产品增量。显然，我们不能在一开始就搞清楚整个设计:我们甚至只粗略地知道产品将是什么。同样明显的，我们最终需要一个好的设计。因此，我们的软件设计必须增量地创建，每次创建一点。

没关系: 当产品很小而且不完整时，它不需要太多的设计。随着它的发展，它需要一个更大、更好、更健壮的设计。我们只需要在产品发展的同时改进设计。

在我们推进的过程中建立设计是困难的。它需要设计技巧、测试技巧和重构技巧。我们将在下面的文章以及本系列的其他文章中探讨这些问题。随着时间的推移，我们将向您指出关于这个主题的一些参考资料。

但基本的事实仍然是:如果我们要在每个Sprint中交付一个产品增量，我们必须找到一种方法，以增量的方式进行良好的设计。

重构

我们今天所知道的进行增量设计的最好方法叫做“重构”。重构是在不破坏现有代码的前提下改进现有代码设计的过程!

重构不重写。当然，如果我们有一个设计不好的程序，我们可以用更好的设计来编写一个新的程序，然而这将花费很长时间，而在Scrum中，我们没有很长的时间重写程序。我们需要在当前Sprint结束时有一个更好的设计。

重构是一个转变代码的过程，通常是非常小的步骤，使代码变得更好。现代IDE可以帮助我们做到这一点: 它们中的大多数都提供了一些自动化重构工具。他们可以提取一段常用的代码，并将其转换为方法或函数。它们可以将代码从一个类移动到另一个类。它们可以重命名变量，或者更改方法的签名。

用好重构，我们可以在进行的过程中逐步改进我们的设计。然而，关键字是“用好”，我们必须培养这种技能。

增量设计改进是必要的，重构实现这个目的的重要方法。

程序化测试

除了验收测试，我们还需要程序化测试。我们构建的每个特性都由许多编程步骤组成，在任何一个步骤中，我们都可能犯错误。我们使用程序化测试来避免这些错误。一个非常好的程序化测试形式是测试驱动开发，它是这样的:

在实现我们想要的特性的过程中，考虑一些小的步骤。先编写一个在该步骤完成时应该运行的测试。运行它: 确保测试失败。
构建代码以完成该步骤。运行测试: 确保测试通过。
检查代码，看看它是否足够清晰。如果没有，重构它。再次运行测试以确保一切正常。
重复此操作，直到特性完成为止。

这不是我们做事情的唯一方法，但它是我们目前知道的最好的方法之一。不管怎样，有很多小测试来支持每个更大的验收测试是非常有用的，因为小测试告诉我们哪里出错了，而验收测试只是尖叫着“有东西坏了!”

这些测试还帮助我们进行更大规模的重构。我认为一个完美的TDD程序员可以在TDD周期中完成她所有的设计改进，但是我的经验是，有时候我并没有马上注意到设计问题。当这种情况发生时，我可能需要在下一次处理代码时进行一些额外的重构工作。就像当我们开发一个特性时，我们的测试可以帮助我们确定我们的设计变更没有破坏任何东西。

持续集成

Scrum需要一个可运行的、经过全面测试的、可用的增量，包含前几个sprint中所有待办事项: 一个完整的、运行的、测试过的、可操作的程序。

显然，这要求团队的所有工作都必须在Sprint结束时完成集成、测试并上线工作。延迟集成会带来一些问题，其中许多问题需要大量调试。我们等得越久，情况就越糟。相反地，如果我们在做了一些小的工作更改之后便进行集成，就会变得容易得多。

自动测试，自动构建，是Scrum团队开发过程的重要组成部分。对于大多数团队来说，他们构建的频率越高，事情进展得就越好，随时可构建似乎是最好的，这就是为什么这种实践被称为持续集成。

在黑暗Scrum中求生