如何防止Scrum将优秀的开发人员变成平庸的开发人员？
我发现这也发生在我的团队里，尽管他可能有点夸大了情况。
Scrum是一种将低于平均水平或较差的开发人员转变为一般开发人员的方法。它还擅长将优秀的开发人员转变为一般的开发人员。
每个人都只想从黑板上拿掉一些你一天就能完成的容易的事情，这样你就可以在明天的每日Scrum上报告一些事情。每个人都在努力采摘低垂的果实。如果什么都没有发生，你又在做什么呢？你没有动力去做聪明的事情，也没有花时间去思考解决方案的动机。你让球队失望了！速度在下降！
我认为，如果你有困难要解决的问题，你可以把它们交给聪明人，然后让他们自己去解决。你不要每天不停地骚扰他们，要求知道他们昨天做了什么，今天又计划做什么。每天都在更新，聪明人解决难题的动力在哪里？他们现在有了与初级开发人员相同的动机；找到最容易的门票来全面移动。
有时候我只想一个人呆几天，想个办法。如果我这么做了，我在Scrum上就没什么可说的了。所以取而代之的是，我会选择前端的颜色是错误的绿色或拼写错误的用户故事！你看，在午饭前，我一天就完成了两层楼！跟我走！
我不完全同意他的话，例如，我同意有一条评论说，不是他们(经理)不信任他们，而是他们在没有持续监督的情况下不能把事情做好。
当一个伟大的开发人员变成一个普通的开发人员时，总是有多种原因，但我确实发现日常Scrum可能是原因之一。那么，我如何防止Scrum会议的这种副作用呢？
我也意识到说起来容易做起来难，但我喜欢看看别人怎么看这个问题。
在阅读了到目前为止我得到的所有答案后，我意识到我需要添加一些信息来使我的问题更相关。
但在我开始之前，我想重复马丁·马特在他的回答中说过的话，这么多人觉得有必要对此说点什么，这一事实本身就表明了Scrum造成的挫折感。
完全同意！当我第一次问这个问题的时候，我已经预料到一些答案会是"；哦，你没有做对Scrum！
我用了“伟大的开发人员”这个词，我可能应该说是一个好的/好的开发人员，因为我已经看到了这个离题的答案。此外，在我的整个职业生涯中，我从来没有与伟大的开发人员合作过，所以我一开始就不应该使用它。我的意思是，我不时地看到，Scrum让优秀的开发人员表现得不那么好。
一些答案集中在一句话上，那就是他们没有持续的监督就不能把事情做好，并认为这是微观管理的问题。但这不是我的情况，例如我不做微观管理。我遇到的问题(也是时不时的)是，精通技术的开发人员不一定是精通业务的开发人员。有时他们会过于专注于完善他们的技术解决方案，而没有意识到我们最终要交付的产品。其他时候，这是一个需要协调的跨职能功能，特别是每个团队可能都有自己的优先级/时间表。这就是他们需要监督的原因。但我想我不应该只是照搬原帖中的常量监管这个词，一开始就不应该使用常量。但是，再说一次，如果有人认为伟大的开发人员和伟大的团队不能这么做，那么我没有反驳的理由。
一个答案说，每天的Scrum不知何故变成了一场谁完成了最多门票的比赛。我从来没有经历过这种情况。成熟的团队不会这么做(不过，成熟的团队不一定是伟大的团队)。有人经历过吗？
对于那些建议我阅读敏捷宣言的人，我的反驳是，这是我在2008年(12年前)为Scrum联合创始人肯·施瓦伯撰写的“企业与Scrum(开发者最佳实践)”一书写的一篇长篇书评，我在这里列出了我的书评，不是为了炫耀，而是为了表明：(1)我相信我在Scrum上做了足够长的时间，看清了它的优缺点。(2)我知道什么是敏捷。
我不确定人们怎么能选择只做简单的任务。当我运行Scrum时，您不能从顶部开始接受超过3张卡片的任务，并且您应该接受顶部的卡片，除非您真的有很好的借口不这样做。他不是按优先级排列任务的优先顺序吗？此外，任务不应该太难，以至于它不能移动。如果我看到任务没有超过两天的移动，整个团队会开会将任务分解成较小的任务，因为这显然是一个话题，而不是真正的任务跟踪雪橇人。
相关：软件开发人员原型(Podcast Complete Developer Podcast，第250集，2020-05-14。直接下载(MP3)--他们谈论哪些原型与Scrum兼容。(原型：牛仔/牛仔、完美主义者、看门人、专家、叛逆者、英雄和常规程序员(暗物质开发者)。)-彼得·莫滕森(Peter Mortensen)。
究竟是什么构成了一个伟大的开发者？一个伟大的开发人员是否能够可靠地解决原本难以解决的问题，其结果是经过几天(甚至几周或几个月)的跨学科研究，然后进行开发和测试，结果是十几行代码？或者一个伟大的开发人员可以解决平凡的问题，但速度非常快，生成代码的速度可能是普通开发人员的十倍？或者其他什么？-大卫·哈曼。
Scrum有点像共产主义，它只在理论上有效。这就是在实践中毁掉它的原因。在一次成功的Scrum之后，经理们要求提高速度。Scrum的评估很快就变成了最后期限。开发人员停止互相帮助，因为这在黑板上是看不见的。开发人员说，当他们知道他们不会去做这些任务时，任务就会变得很容易。如果你的第一个任务做得不好，那么就会提醒你在Scrum会议上每天都落后于计划。开发人员寻找不使用Scrum的工作。-保罗·麦卡锡(Paul McCarthy)。
我和我的朋友都是Scrum团队的一员，他们不是Scrum的粉丝。原因是，作为一个拥有专门的流程管理器的流程，它通常会将所有其他流程弯曲和中断，并成为这个总体流程，在该流程中，除了Scrum例程和使这些Scrum例程看起来成功之外，您什么都不做。
冲刺(两周的部分)是第一位的。因为在两周结束的时候有人会问我们是否完成了我们承诺要做的事情，所以优先买到“做完”的门票。这意味着要抄近路才能把票做完。当冲刺结束时，我的团队不会进行单元测试或代码审查。在我朋友的团队中，他加入了if语句来处理QA发现的错误，而不是真正找到错误的根本原因来完成票证。这两周的关注可能会导致无限缺陷的方法论。显然，在Scrum中，它需要通过产品所有者，但除非他们痴迷于边缘情况，否则很容易就会漏掉很多东西，开发人员不会被鼓励深入考虑这一点。Scrum和无限缺陷可以成为好朋友，因为无限缺陷方法允许人为地提高速度，只要在冲刺之后发现错误，并因此将其视为新工作。通过不断生成新的bug，您可以获得更高的速度。
每个人都可以一天比一天地看到您的工作效率，这成为一个简单的评估指标。拥有一个公开的任务委员会意味着每个人都可以看到你做事情的速度有多快，包括管理层。在我的组织中有一些关键的人认为我很有效率，主要是因为我相对于其他人来说票务转移得太快了。当在此基础上评判开发人员时，通过QA的糟糕实现和经过良好测试、架构良好的实现是等价的。这就是明星可以被降至看似平均水平的地方，因为董事会+速度成为评判开发人员的方式，成为他们关注的焦点。
在许多情况下，团队实际上并不是有效的自组织。Scrum喋喋不休地谈论自组织团队。"；我写了另一个关于这个问题的答案。总而言之，团队成员将按照他们喜欢的/受到激励的方式做事，除非这构成了一个有用的团队，否则许多事情都无法完成，团队成员只能继续在混乱中前进。如果团队都有相同的目标和激励，他们可能会自组织起来。问题是，这很少是真的。有一个人想要升职。另一个是在业余时间攻读学位。三分之一的人正在提升技能，准备去另一家公司工作。另一个只是不想有争论，所以什么都同意，让代码库变得一团糟。很多好的设计都需要开发人员坐下来仔细考虑该如何工作。在Scrum中，您需要清单，并且没有对工作质量进行真正的检查，因为"；完成"；或"；未完成"；通常是由非技术性项目所有者决定的。这激励人们进入空白，专注于输出代码。
票证/用户故事迅速成为架构。因为开发人员独立地按顺序处理每个票证，所以体系结构迅速开始镜像这些票证。门票通常是1-2句话的用户故事。票证驱动的体系结构很快变得杂乱无章，原因很简单，因为更多的代码会根据需要堆积起来。
高度的开发人员独立性意味着每个开发人员采取不同的方法。考虑对对象进行排序。您可以在JS的前端、Java的后端或SQL本身中执行此操作，如果时间有限，您可以选择最容易实现的方法。虽然这不一定是错误的，但它使调试变得非常困难，因为需要检查更多的地方。
站立表演是有效的更新管理。认为单口相声是为开发人员服务的想法是荒谬的。有没有人真的等到早上9点才报告问题，或者他们会立即在群聊中询问？实际上，是食物链上更高层的人在密切关注事物的移动速度，这样他们就可以在当天晚些时候询问。
优秀的开发人员通常由他们开发健壮代码的能力来定义。除非产品负责人是技术人员，否则Scrum会大量贬值，因为产品负责人不会评估代码。它是功能驱动的，它运行的是所提供的用户故事的功能标准。
伟大的开发人员通常是由他们编写代码的能力来定义的，这些代码现在和将来都有价值。Scrum项目在两周的时间内考虑到所有事情。没有未来。
伟大的开发人员通常被定义为能够解决棘手问题的人。Scrum鼓励挑选可以轻松完成并以稳定的速度快速完成的工作。一个棘手的问题是开发人员完成票证的速度很慢。
伟大的开发人员经常被寻求建议和第二意见。但是，任何这样做的时间都会减少大量生产门票的时间，因此它们的速度会下降。
即使你遇到的情况是，没有根据完成的分数来正式评判你(如果管理层主要是在Scrum仪式期间互动，因为这是他们关于进展的全部内容)，人们仍然会竞争注意力和奖励。
为了解决这个问题，我会取消个人速度得分，取消单口相声中管理层的存在(否则开发人员会受到强烈的激励，总是有好消息)，并会告诉管理层，他们第二次表扬开发人员或根据票量给他们加薪，他们就会从根本上改变行为。理想情况下，产品所有者也不会是直接经理，因此开发人员在Sprint审查和Sprint计划期间会受到激励，让他们看起来不错。
问题是，您正在与Scrum的本质作斗争，因为它主要关心速度。衡量的是重点关注的是什么，Scrum衡量的是输出速度，用户端的输出只由产品所有者判断。该指标并不重视与伟大的开发人员相关的许多行为。
我没有对此投反对票(我不认为我们应该因为一系列糟糕的经历而受到惩罚)，但你所描述的不是Scrum。然而，这是一种被称为Scrum的足够普遍的体验。我曾多次在伟大的Scrum团队中担任开发人员，在这些团队中，每个人都团结在一起解决困难的问题，并做出了令人惊叹的工作。但后来，我工作的公司确实致力于此。--丹尼尔。
在将您的特定流程和团队中的所有错误归咎于流程框架时，这个答案是一个根本的归因错误。您列出的问题实际上都不是由Scrum引起的。事实上，Scrum为您提供了预防其中许多问题的工具：--Meriton。
无限缺陷方法论的Scrum解毒剂是“完成”的定义。在Scrum中，自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人指挥。如果管理层监控个人贡献者的表现来奖励速度最快的牛仔程序员，这就违反了这一点。Scrum并没有说开发人员独立工作。它说开发团队自行组织，这意味着团队可以决定其成员如何协作。-约翰·梅里顿(Meriton)。
我觉得有必要指出的是，1)在Scrum中不再有承诺的工作，2)Scrum明确地告诉你特定的人没有任务，所有的任务都属于团队3)Scrum不希望开发人员独立，4)根据Scrum的说法，上级不属于站台表演--Erik。
对于人们称之为Scrum的负面体验，我可以理解，但如果你的大部分经历在指南中被明确称为Scrum，而不是Scrum；，你就不能真的把它们归咎于系统。--约翰·埃里克。
通过正确地做这件事。我读过的所有恐怖故事，不管是你的还是其他的答案，只告诉我一件事：那些人做得不对。我明白，这很难。制定一些规则并让他们遵守是非常容易的，但这不是Scrum。Scrum正在组建一个自组织团队。这并不适用于每个人，也不适用于每个星座。但这是基础，你所看到的一切都是实际上不是一个团队的结果。
想象一下，11个人被递给一本足球手册，并被告知每天上午10点左右在5号会议室进行15分钟的训练。你认为这就是一支优秀足球队的标准吗？但是如果这11个人真的是很棒的职业球员呢？还是没有团队吗？不是的。即使是克里斯蒂亚诺·罗纳尔多也迟早会和这样的球队一起拿到平均工资。但这不是足球的错。这不是你如何组建团队的问题。
Scrum建立在你们是一个团队的事实之上。在一个团队里，你昨天是否拿到了一张罚单并不重要。在团队中，你同意你的目标是什么(即完成的定义)，然后努力实现它。在一起。
一个优秀的开发人员如果每天与他们的团队交谈5分钟，也不会有丝毫逊色。如果一个伟大的开发人员被迫进入一个管理不善的流程，每天都要召开会议，向经理报告他们是否完成了票证，那么他们就会变得不感兴趣。
召开每日报告会议，告诉经理你昨天做了什么，并试图融入一些武断的绩效计划，这不是Scrum。这是一种众所周知的反模式。有人可能会称它为Scrum，并说Scrum指南说你们应该每天见面，但这将是真正的Scrum，因为人民民主共和国实际上是一个为人民服务的民主共和国。
就像团队运动一样，Scrum需要参与者成为一个团队。如果他们只是参与者，希望通过炫耀自己做了多少故事点或进了多少球来提高自己的地位，那么他们总是会输给一个合作的团队，而不是毗邻或相互竞争。
那么，如何防止Scrum将优秀的开发人员变成平庸的开发人员呢？雇佣团队成员。很棒，平均水平，这并不重要，因为一个真正的团队随时都会击败随机收集的所谓的优秀参与者。我不是说那很容易。但这就是Scrum的意义所在。
根据我的经验，关于Scrum正在组建一个自组织团队的说法更像是一个谜。--发稿陈秋浪。
@秋浪仅仅做Scrum并不能自动组成团队。当您有一个团队时，Scrum是您可以使用的东西。没有真正的团队，Scrum就会失败。-nvoigt。
这个答案似乎完全没有抓住要点。除了过分依赖于令人厌烦的东西之外，“你就是做得不对！”比方说，它掩盖了在操作中提出的基本问题：当“进度”成为衡量标准时，聚集在一起分配工作并跟踪其进度(几乎以任何形式)的过程开始对团队合作产生不利影响。你可以打赌，如果球员的工资与他们每场比赛的射门次数挂钩，他们会更自私。问题不在于我们做得不对。那就是我们根本就在做这件事。-特大床侧滑梯
@ZachLipton所以如果经理破坏了方法，那么方法就有错吗？你能说出另一种即使经理滥用也能奏效的方法吗？看板、瀑布、V-Model或任何你可能用来开发软件的东西怎么样？如果经理违背了这个方法，那么这个方法还有效吗？因为我还没有遇到过一位顶天立地的经理。-nvoigt。
Scrum是官方Scrum指南中定义的流程框架，其中特别提到了关于日常Scrum的以下内容：
Scrum Master确保开发团队召开会议，但开发团队负责进行每日Scrum。
每日Scrum是开发团队的内部会议。如果其他人在场，Scrum Master会确保他们不会扰乱会议。
每个人都只想从黑板上去掉一些你可以在一天内完成的容易的事情，这样你就可以在明天的每日Scrum上报告一些事情。
向谁报告？参加每日Scrum的人是其他开发人员(以及Scrum大师，但他只关心过程，而不关心进度)。
在实践中，这意味着你应该告诉你的团队成员你在哪里，这样他们就可以和你协调他们的工作。你不应该做报告，因为这意味着在Scrum团队中不应该存在一定程度的等级制度。
如果没有东西穿过，你到底在做什么？你让球队失望了！速度在下降！
这是谁说的？我无法想象一个开发人员同事会说，Scrum大师不应该在意，因为他不负责进度，外部人员(如产品所有者或管理层)不应该扰乱会议！
Scrum指示Scrum主管防止这种情况发生。如果允许这种行为，被举报的任何人都将开始指导团队的工作，这违反了基本的Scrum原则，即。
自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人指挥。
Scrum用户必须经常检查Scrum工件，并朝着Sprint目标前进，以检测不需要的差异。他们的检查不应该太频繁，以至于检查妨碍了工作。检查。
..
