暗黑敏捷——Dark Scrum（上）

Posted 2021-04-25 软件质量报道

我们来谈谈“暗黑Scrum”。很多时候，至少在软件方面，Scrum似乎压迫人们。很多时候，Scrum并不想象的“橄榄球比赛”那样——快速、可靠、稳定地完成软件交付。但结果，却是每个人都受苦。大多数情况下，开发人员遭受的痛苦超过任何人。

 

我最近思考的主题是：

Kent Beck——我原来的“敏捷”导师，曾经说他发明了极限编程，让世界对程序员来说是安全的。事实证明，世界对程序员来说还不安全。 Scrum对程序员来说可能非常不安全。Scrum的共同创造者之一Ken Schwaber用另一种语境来解释：“这让我感到悲伤”。

 

Scrum，做得相当好，是一个很好的框架，我对此非常诚恳。与业务部门建立强有力的联系，决定需要做什么以及需要推迟什么，这些都是不错的；团队拥有构建产品所需的所有技能，这也很好；每隔几周构建一个经过测试的、实实在在的产品，并向项目干系人演示，这也是一件好事；最后反思一下事情的进展情况以及如何改进它们，也很好。我已经研究、使用和思考Scrum多年了，关于它的一切都非常好。不完美，但非常好。

不幸的是，Scrum是一个概念， 按照Scrum预期去做，它是一种理想的框架。像每一个好主意一样，现实有时会不尽如人意，有时会差很多。我将这样的结果称为“暗黑Scrum”

 

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

让我们看看在Dark Scrum中事情如何变得糟糕的，只需几步就变得糟糕。在本节中，我们将观察一个经历Dark Scrum的团队。 暗黑Scrum领导者（更准确翻译是：权力拥有者，为了方便阅读，用“领导者”代替）没有问题：他们只是做错了。

 

自组织发生缓慢

显然，需要一些时间更好地践行Scrum，因为它有新的角色和活动。更难的是，它要求我们采用新的价值观。我们应该让所有研发人员自我组织来完成这项工作。召集Scrum会议并通过Scrum角色召唤自己很容易，但真正落地就并不容易。

 Scrum通常从很少受过培训的人开始，甚至了解它都很不够，并且很多人认为“他们知道他们应该做什么”。如果他们做错了就应该不足为奇，而且经常是这样。

 通常，今天的权力拥有者认为他们的工作是决定其下属应该做什么，告诉他们这样做，并希望看到他们这样做。 相反，Scrum教导：解释需要做什么，然后就往后站，让团队自我决定去做事情。

 人们不能是一下子就进入Scrum的新操作模式。忘掉旧方法需要时间，学习新习惯需要时间，学会信任团队更需要时间。团队需要时间来学习如何被信任：这是本文想传递的基本信息。 Scrum的训练就始于接受训练的人员的学习过程。

 当那些熟悉旧工作而不是新的Scrum工作的人开始从事Scrum活动时，Dark Scrum就开始了。它是这样的：

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

 每天，团队应该聚在一起组织一天的工作，即“每日Scrum”这种实践，强加给典型的团队。房间里可能有一个人——ScrumMaster，他被告知应该怎么做。但没有告知程序员；很多时候，甚至没有告诉产品责任人（Product Owner，PO）。几乎可以肯定，其他领导们还没有被告知。

但领导已经知道他的工作。领导的工作是保持每个人都在做事，确保开发人员正在做正确的事情，如果不是这样，就“重定向”他们。每天都有强制性的会议，领导可以做到这一点，这是多么方便！

 结果是：不是团队每天围绕他们的联合任务团结起来并整理出好的方法，而是其他人将信息从他们身上拖出来，在他们的头脑中处理，然后告诉每个人该做什么。由于没有像昨天早上预期的那样，这种不正当的活动往往带来很多责备和紧张。

 暗黑Scrum每天都会压迫团队。自组织不可能出现。

 

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

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

好吧，领导们可能是Scrum的新手，但他们对如何处理这个问题了解很多。因此，每两周他们就会出现并告诉这些程序员他们必须构建什么。哦，那些程序员会反击。但领导们认为程序员懒惰、顽固，并不断给他们压力，因为这就是他们管理人的方式。所以他们告诉团队该做什么，他们最好这样做。

当然，领导们很少或根本不知道如何编程，程序员通常至少有一些线索。他们不知道代码的状态是什么，程序员通常都知道。在Scrum中程序员应该决定要做多少工作，但在Dark Scrum中，领导们知道的更好。领导们凌驾于团队之上，认为这是他们的工作：带动团队。

结果永远不会改变。团队真诚地尝试做所要求的事情。开发人员知道说“这是不可能”没有意义，即使是不可能的。他们只是因为懒惰、愚蠢和麻烦制造者而受到痛斥。所以他们尽力而为，这还不够好。

在Sprint结束时，结果没有达到权力者的要求。奇迹再一次没有发生。开发人员再次失败。幸运的是，我们有机会纠正它们：Sprint评审！

 

我们批评所做的事情 – 还有没做的。

每个Sprint，利益相关者都会关注团队的成就，并提供有关如何前进的指导。伟大的理论，当组织不是Scrum专家的情况下很少在实践中能做到。

在实践中，“暗黑Sprint评审”开始时有人提醒每个人团队“承诺”做什么。 （也就是说，在团队说“我们会尝试”之前就要求了什么。这是一个承诺，不是吗？）然后领导们看看团队给他们带来的可怜的失败。

你猜怎么着。该组织的要求超过团队能够做到的，当然团队没能做到。团队尝试了，并且在尝试时，他们采取了所能想到的各种捷径来完成所有那些不合理的请求。所以，团队在测试上吝啬、在设计上吝啬，甚至太累而无法一面思考一面工作。

团队做得不够，他们所取得的成就并不是很好。“球队”再一次失败了。

幸运的是，暗黑Scrum的领导者、PO和项目干系人，他们确保程序员完全了解他们做得多么糟糕。这肯定会激励每个人下次做得更好。为了帮助团队，咱们有Sprint反思会（Retrospective）！

 

我们告诉他们如何改进......

在Sprint反思会中，研发团队回顾之前的Sprint，以及更早的阶段。他们观察到哪些进展顺利、哪些进展不顺利。他们弄清楚如何改善下一次的流程。

在实践中，暗黑Scrum领导者会帮助团队，会提醒团队——你们做到那么差，尽管他们对团队的管理有多紧。他们向这些开发人员明确表示团队的失败——这是一次失败——肯定是懒惰和无能造成的。

为了激励团队做得更好，他们指出了不改进的后果，这几乎肯定会包括“人员的轮换”。这总能引起团队成员的注意。

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

• 开发人员：我们需要进行更多测试以减少错误数量。

• 领导：不，你已经在功能开发上落后了。您需要更聪明地写代码。停止放入bug，所以就不需要消除bug。我们需要功能，而不是测试！
  

  
  

• 开发人员：设计越来越苛刻。我们需要重构来改进它。

• 领导：不。你为什么一开始就写一个糟糕的设计？没有人告诉你写一个糟糕的设计。停止这样做并解决问题。还有一个周末即将来临。就这么办！

  
  

• 开发人员：要求不清楚，他们没有得到澄清，然后我们构建的内容在最后一刻被拒绝。 

• 领导：我们聘用你们，因为你们聪明并且能想出办法。你们应该自我组织来解决这些问题。坐而论道不如起而行之，建立我们想要的东西！

  
  

你明白了。头悬梁、锥刺股，一直是软件研发人员所要面对的。 Scrum并没有改变这一点。

 

哇，这令人沮丧

嗯，当然，Scrum实际上正试图改变这一切。但是，直到组织的心灵和思想发生变化，旧式管理才会有很大的改变......现在每隔几周发生一次......通常每一天都会发生！

 

我们开发人员可以做什么？

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

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

来自PO和/或其他权力拥有者的大部分压力来自于他们无法清楚地看到我们正在做什么、实际上已完成了哪些工作。如果我们取得的进展像水晶（联想到水晶开发模式）那样透明，那就可以改变我们的境遇。

如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕。他们的恐惧会使我们承受更大的压力，因为恐惧经常表现为愤怒，他们会对我们生气。经常，非常生气。

如果我们在功能之前处理设计或基础设施，功能似乎很慢。这使得我们的领导者担心我们会延迟或无法提供重要功能。我们可能再次遭受恐惧和愤怒。

如果因为我们的设计落后而放慢速度，我们会减少功能。更少的功能，会得到更多的恐惧、更多的愤怒、更多的压力。

当领导层看不到工作软件时，他们会对未来感到害怕 - 这是正确的。他们总是以无助的方式表现出恐惧，而这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实、实时、有效的软件，并具有可见功能！

（待续）