如何防止Scrum将优秀的开发人员变成普通开发人员？

我发现这也发生在我的团队里，尽管他可能有点夸大了情况。

Scrum是一种将低于平均水平或较差的开发人员转变为一般开发人员的方法。它还擅长将优秀的开发人员转变为一般的开发人员。

每个人都只想从黑板上去掉一些你可以在一天内完成的容易的事情，这样你就可以在明天的每日Scrum上报告一些事情。每个人都在努力采摘低垂的果实。如果什么都没有发生，你又在做什么呢？你没有动力去做聪明的事情，也没有花时间去思考解决方案的动机。你让球队失望了！速度在下降！

我认为，如果你有困难要解决的问题，你可以把它们交给聪明人，然后让他们自己去解决。你不要每天不停地骚扰他们，要求知道他们昨天做了什么，今天又计划做什么。每天都在更新，聪明人解决难题的动力在哪里？他们现在有了与初级开发人员相同的激励，找到最容易的门票来全面转移。

有时候我只想一个人呆几天，想个办法。如果我这么做了，我在Scrum上就没什么可说的了。所以取而代之的是，我会选择前端的颜色是错误的绿色或拼写错误的用户故事！你看，在午饭前，我一天就完成了两层楼！跟我走！

我不完全同意他的话，例如，我同意有一条评论说，不是他们(经理)不信任他们，而是他们在没有持续监督的情况下不能把事情做好。

当一个伟大的开发人员变成一个普通的开发人员时，总是有多种原因，但我确实发现日常Scrum可能是原因之一。那么，我如何防止Scrum会议的这种副作用呢？

我也意识到说起来容易做起来难，但我喜欢看看别人怎么看这个问题。

你引用的文本的第三和第四段谈到了这个问题，并提出了一种绕过它的方法。-你是在排除那个解决方案吗？-一个Flater。

@菲利普，我同意！但我已经得到了答案，所以我不能把我的问题移到那里，对吗？--陈秋浪。

主持人可以将问题和答案一起迁移到不同的Stack Exchange站点。如果您希望他们这样做，请将您的问题标记为需要版主干预，并告诉他们您希望将其迁移到何处。-大卫·菲利普(Philipp)。

我和我的朋友都是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的所有不喜欢之处。9~10成熟。--格雷戈里·柯里(Gregory Currie)。

我没有对此投反对票(我不认为我们应该因为一系列糟糕的经历而受到惩罚)，但你所描述的不是Scrum。然而，这是一种被称为Scrum的足够普遍的体验。我曾多次在伟大的Scrum团队中担任开发人员，在这些团队中，每个人都团结在一起解决困难的问题，并做出了令人惊叹的工作。但后来，我工作的公司确实致力于此。--丹尼尔。

无限缺陷方法论的Scrum解毒剂是“完成”的定义。在Scrum中，自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人指挥。如果管理层监控个人贡献者的表现来奖励速度最快的牛仔程序员，这就违反了这一点。Scrum并没有说开发人员独立工作。它说开发团队自行组织，这意味着团队可以决定其成员如何协作。-约翰·梅里顿(Meriton)。

我觉得有必要指出的是，1)在Scrum中不再有承诺的工作，2)Scrum明确地告诉你特定的人没有任务，所有的任务都属于团队3)Scrum不希望开发人员独立，4)根据Scrum的说法，上级不属于站台表演--Erik。

对于人们称之为Scrum的负面体验，我可以理解，但如果你的大部分经历在指南中被明确称为Scrum，而不是Scrum；，你就不能真的把它们归咎于系统。--约翰·埃里克。

我认为你的情况和你引用的文本的问题是，每天的Scrum不知何故变成了一场谁完成了最多门票的比赛。您的开发人员交付的票证数量是判断/评估票证的最重要指标吗？而不考虑票证的难度/工作量？

每天的Scrum不应该是一场比赛，而应该是一个(简短的)会议，在那里每个人都会讲述他们目前正在做的事情，他们遇到的问题，以及他们是否可以相互帮助的看法/讨论。

除此之外，Scrum不应该被视为经文。经理将某些任务/票证分配给最高级/最合适的人并没有什么错。

通过正确地做这件事。我读过的所有恐怖故事，不管是你的还是其他的答案，只告诉我一件事：那些人做得不对。我明白，这很难。制定一些规则并让他们遵守是非常容易的，但这不是Scrum。Scrum正在组建一个自组织团队。这并不适用于每个人，也不适用于每个星座。但这是基础，你所看到的一切都是实际上不是一个团队的结果。

想象一下，11个人被递给一本足球手册，并被告知每天上午10点左右在5号会议室进行15分钟的训练。你认为这就是一支优秀足球队的标准吗？但是如果这11个人真的是很棒的职业球员呢？还是没有团队吗？不是的。即使是克里斯蒂亚诺·罗纳尔多也迟早会和这样的球队一起拿到平均工资。但这不是足球的错。这不是你如何组建团队的问题。

Scrum建立在你们是一个团队的事实之上。在一个团队里，你昨天是否拿到了一张罚单并不重要。在团队中，你同意你的目标是什么(即完成的定义)，然后努力实现它。在一起。

一个优秀的开发人员如果每天与他们的团队交谈5分钟，也不会有丝毫逊色。如果一个伟大的开发人员被迫进入一个管理不善的流程，每天都要召开会议，向经理报告他们是否完成了票证，那么他们就会变得不感兴趣。

召开每日报告会议，告诉经理你昨天做了什么，并试图融入一些武断的绩效计划，这不是Scrum。这是一种众所周知的反模式。有人可能会称它为Scrum，并说Scrum指南说你们应该每天见面，但这将是真正的Scrum，因为人民民主共和国实际上是一个为人民服务的民主共和国。

就像团队运动一样，Scrum需要参与者成为一个团队。如果他们只是参与者，希望通过炫耀自己做了多少故事点或进了多少球来提高自己的地位，那么他们总是会输给一个合作的团队，而不是毗邻或相互竞争。

那么，如何防止Scrum将优秀的开发人员变成平庸的开发人员呢？雇佣团队成员。很棒，平均水平，这并不重要，因为一个真正的团队随时都会击败随机收集的所谓的优秀参与者。我不是说那很容易。但这就是Scrum的意义所在。

根据我的经验，关于Scrum正在组建一个自组织团队的说法更像是一个谜。--发稿陈秋浪。

+1，团队经常采用像Scrum这样的敏捷过程，认为所涉及的仪式会神奇地让他们构建更好的软件。但这不是敏捷的意义所在。当你归结敏捷的时候，它就是关于收紧反馈循环，这样团队就可以自我检查，自己找出如何变得更好。Scrum不会帮助您构建更好的产品，但如果您认真地进行自我检查，它可能会帮助您构建更好的团队。这反过来又会带来更好的产品。--塞斯·R(Seth R)。

团队并不是凭空形成的。这是它的功劳。而且许多公司不想投资这项工作。甚至不理解这个事实。所以，是的，我看到失败的团队比工作团队更多。我见过它工作，如果做得正确，如果做得不对，就会失败。但我认为指责Scrum失败是不公平的，因为Scrum做得不对。咖啡如果用废水冲泡，味道真的很不好。但你不能为此责怪咖啡。那不是你做这件事的方式。如果世界上大多数人用废水煮咖啡.。咖啡对此还是无能为力。-nvoigt。

@秋浪仅仅做Scrum并不能自动组成团队。当您有一个团队时，Scrum是您可以使用的东西。没有真正的团队，Scrum就会失败。-nvoigt。

Scrum大约在两周内构建。对于开发人员来说，除了这段时间之外，没有做任何考虑。

几乎任何两周的产品都可以由初级工程师成功地制造出来。高级工程师的价值在于发现陷阱、开发面向未来的体系结构、确保健壮性和捕捉边缘情况。Scrum认为所有这些都无关紧要，就像喷洒代码一样。

在Scrum中，您可以完成大量工作。然后你来处理它。然后，您会根据您在冲刺过程中完成的堆栈数量进行评分。正式来说，你没有得分，所有的工作都属于团队，但没有人，至少是管理层，会相信这一点。该框架构建在微观管理中，频繁检查Scrum工件，其中工件表示您所做的任何事情和每件事。

单口相声通过每24小时带来一次检查，让你的老板检查来强调这种资历。

我在两个Scrum团队工作过。我的第一份工作是大学毕业后的第一份工作，所以保持低调，报告无穷无尽的工作是很容易的。我可以及时拼凑出一些东西，即使它不稳定。

然后，在我的第三份工作中，那家公司把它带来了，我被期望做更大的工作，但仍然有进展要报告。在编码之前，我通常甚至没有时间阅读需求文档，所以我可以在第二天报告站立表演的代码。

Scrum是如何让我变得平庸的？我开始讨厌我的工作，所以除了再次静静地在我的格子间代码中大量生产之外，我再也没有做出过有意义的贡献。

顺便说一句，我记得看了辛德勒的名单后，我想，这家工厂很可能是在Scrum的管理下进行的，甚至到了神经质地关心日常生产率，以及惩罚可怜的工人在单口相声中出现生产缺陷的地步。

很遗憾看到您有一个如此糟糕的老板，现在却责怪一个相当好的流程框架。您可能希望实际阅读一些关于Scrum的内容。官方的Scrum指南可能是一个很好的起点。在其中，你会了解到，检查是由团队完成的，而不是由管理层完成的。事实上，在Scrum中没有老板(或者如果他们有，那么产品负责人和Scrum大师应该保护您不受他们的影响，所以您在评审会议上每个Sprint最多只能看到他们一次)。-约翰·梅里顿(Meriton)。

即使从这个简短的描述中也可以清楚地看出，Scrum在这里做得很糟糕，效率也很低。-DJClayworth。

@DJClayworth：没错，但是Scrum确实有一个问题，它很容易被误解。这不是Scrum发明者的错，但这是Scrum的一个问题，正如你从这里的许多类似帖子(不幸被否决)中看到的那样。-宾客。

我是一个被Scrum转变为平庸的体面开发人员，主要是因为Scrum给了我一条逃脱惩罚的途径，让我没有理由去关心它，并强烈鼓励我玩弄系统。

Scrum进行了15分钟的单口相声表演，在这里你可以影响你的老板，也可以让你的老板评估你的表现。一整天都围绕着在你的1分钟简介中报告成功。因此，做任何复杂的事情都意味着它永远不会进入报告层次结构，因为复杂的想法需要一分钟以上的时间。

因为我需要做的就是犹豫不决，保持我的速度很快，我和我的同事们可以把我的很多时间重新分配到其他事情上。我正在攻读硕士学位。另一名团队成员正在创建自己的初创公司。我的质检人员有一半时间在织布。

Scrum假设员工关心一家公司或项目的成功或失败，但我们不关心，因为我们是展出的斑马，而不是动物园饲养员。动物园只需要赚足够的钱，我们就不会挨饿了。主人是否吃东西无关紧要。另一个答案是，一群人会输给一支队伍。不过，作为一名员工，失败是完全没有问题的。如果我的项目一年后就夭折了，我又何必在乎呢？

我是一个专业的Scrum开发人员，但最主要的原因是它让我几乎全职攻读硕士课程就能获得报酬。

管理层中的任何人都不应该对此感到高兴，因为我们的团队的产量可能只有9月份的三分之一。但是，只要我们保持较高的速度，管理层就会被Scrum蒙蔽了双眼，无法分辨出点数生成和实际工作之间的区别。

防止这种情况需要关心个人表现，而不仅仅是单口相声和票速。Scrum强调报告速度，没有其他内容，所以提交垃圾，然后把时间用在自己身上是绝对有意义的。

Scrum会在15分钟内进行单口相声，在这段时间里，你会影响你的老板，你的老板也会评价你的表现。那么，你就不是在做Scrum了。单口相声是为了让团队相互了解最新情况，并检查完成工作是否存在障碍，这样就可以消除这些障碍。它是关于也许可以与你的团队成员中的一员联系起来，一起做一些事情。这绝对不是要影响你的老板。如果这就是你的工作方式，你应该不邀请你的男朋友。

..