黑暗敏捷 Dark Scrum
黑暗敏捷 Dark Scrum 作者：Ron Jeffries 译者：陈旭 （微信公众号：敏捷变革中心）
我们来谈谈“黑暗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的原则和价值之前，它被滥用几乎是不可避免的。
似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。 来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。
如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。 如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。 当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！