Scrum是毁了伟大的工程师，还是你做错了？

Scrum框架的思想是组织一个开发过程，以便更快地通过不同的项目周期。但是，这样做是否总是激励正确的行为呢？许多加入了关于堆栈溢出问题的辩论的用户都有类似的故事，比如开发人员如何走捷径，如何被门票上的高分分心，甚至是假装经理的工作效率。怎样才能避免这些陷阱呢？

这个问题已经从我们的工作场所交流转移到了软件工程方面，这表明开发人员对Scrum及其有效性的担忧大于标准软件开发生命周期；他们感觉到它对他们工作场所的整体影响。用户秋浪在他们的问题中提出了一个大胆的主张：Scrum正在把优秀的开发人员变成平庸的开发人员。

很多辩论都试图解决Scrum对任何给定团队或个人的影响和限制。虽然许多人认为Scrum是团队失败的原因，但其他人认为这是一个归因错误，并表示开发团队的功能障碍要严重得多。

Scrum的捍卫者认为管理不善是原因。卢埃林在他的结束语中写道：“如果管理层实质上忽视了开发人员，在预定的范围内有固定的最后期限需要完成，或者这是一个你死我活的环境，而不是一个专注于实现相同目标的团队，如果不欣赏提前计划和跳出框框的思考，那么是的，最终你会放弃，求助于只做分配的任务。”我去过那里。但不要把这归咎于Scrum。

用户DJClayworth呼应了许多评论的观点，他说：“认为自己有压力的开发人员在任何开发方法上都会做得很糟糕。”

用户马丁·马特(Martin Maat)对反对意见进行了最好的总结，他指出：“这么多人觉得有必要对此发表意见，这一事实本身就表明了Scrum造成的挫折感。”

让我们解开讨论中的一些要点。不管你是赞成还是反对，我们都可以看看讨论，看看Scrum在哪里让开发人员失望，在哪里帮助他们出类拔萃。

不管人们是做错了，还是Scrum框架中的固有bug，一些常见的开发人员陷阱都会出现在评论中。以下是十个突出给我们的建议：

第一个批评是关于在单口相声中如何发生意想不到的动态。一种说法是，它们可以退化为仅仅是一种生产力的展示，特别是当经理们在场的时候。这就是用户马修·盖泽(Matthew Gaiser)在他的回答中将单口相声重新标记为“更新管理”的原因。在他看来，签到只会邀请经理们密切关注正在以无益的方式进行的工作。对于异步工作的分布式团队来说更是如此。(全面披露：马太以前曾为我们写过信。但我们偶然发现了Scrum问题)。

提出的另一个观点是，任何划分工作并跟踪进度的流程都会导致新的进度度量(无论是有意还是无意)。仅仅通过引入指标，这就会影响对其做出贡献的人的行为。

许多评论者建议，这意味着开发人员可能会偷工减料，以便在当前的冲刺中完成承诺完成的工作。Gaiser和其他人指出的问题是，在冲刺过程中正在处理并移动到“完成”的个人票证是一个黑匣子。它与速度指示器的计数相同。“一个糟糕的实现，”盖塞写道，“通过QA的”和一个经过良好测试、架构良好的实现是等价的。这是一个衡量生产力的错误指标。

另一个帖子仔细考虑了伟大的个人和伟大的团队之间的差异。由于每个人都遵循Scrum方法论，你可能会得到一些效率很高的开发人员，但你没有团队。盖泽认为，如果没有正确的激励措施，自我组织是一个无法实现的目标：

“团队成员将按照他们喜欢的/受到激励的方式做事，除非这构成了一个有用的团队，否则很多事情都无法完成，团队成员只能继续在混乱中前进。”

此外，Gaiser说，让每个开发人员选择他们解决问题的方法会在调试过程中增加更多的工作。

同样，盖泽进一步批评了生产力的错觉--人们关注的是拿到“完成”的入场券，而深入思考看起来并不是很有成效。因此，开发人员可能会选择容易摘到的果实，而跳过难以解决的问题。盖泽又说：“Scrum鼓励挑选那些容易完成并以稳定的速度快速完成的工作。”其结果是：每天的追赶和签到鼓励挑选可以在一天内完成的任务。

盖泽认为，质量将受到影响。“伟大的开发人员通常由他们开发健壮代码的能力来定义。除非产品负责人是技术人员，否则Scrum会大幅贬值，因为产品负责人没有评估代码。在这一点上，他强调“完成票据”通常是一个功能决定，而不是对正在编写的代码的检查。

当速度是唯一的衡量标准时，团队不再有时间咨询，不再给出第二个意见，不再有时间让某人提出一个概念-所有这些让一个团队成为一个团队的东西。用盖泽的话说：“伟大的开发人员经常被寻求建议和第二意见。但任何时候这样做都会减少大量生产门票的时间，因此它们的速度会下降。

Scrum的另一个不良行为是“在冲刺之后发现错误，因此被算作新工作”。它鼓励开发人员可能发布有缺陷的代码的行为，因为新的工作不能包含在当前的Sprint中。

开发人员不仅根据工单系统选择工作内容，Gaiser还建议Scrum无意中创建混乱的体系结构，开发人员按顺序独立地工作工单，因为“体系结构迅速开始镜像工单”。

通读讨论，您会发现有些人认为没有充分遵循Scrum规则是所有问题的根本原因。然而，盖塞反对Scrum过程的最强点可能是它成为凌驾于其他一切之上的过程，这样可能会破坏一个获胜的团队：“(Scrum)向它弯曲并打破所有其他过程，成为这个最重要的过程，在这个过程中，你除了Scrum例行公事之外什么都不做，让这些Scrum例行公事看起来很成功。”

这是一长串问题，不管它们是严格地由Scrum引起的，还是仅仅是由Scrum引起的。然而，同样多的是关于如何让开发人员在Scrum规则下不负众望的建议。

对Gaiser的回答--目前得票率最高的--的很多回应都是关于他的过程为什么不是Scrum。斯蒂芬·伯恩(Stephen Byrne)写道：“我认为这是一个很好的答案，有一些很棒的想法，但我必须同意大多数其他评论员的观点，这里描述的过程绝对不是它应该是的Scrum。”但有足够多的人要么厌恶Scrum，要么对Gaiser的回答产生共鸣，即Scrum的实现方式必须打破某些东西。

许多辩论表明，每天的单口相声会给每天送一张关闭的门票带来压力。但正如用户DJClayworth指出的那样，任务的优先顺序仍然应该发生，如果这不是自然发生的，这是Scrum大师的工作：“你应该在冲刺过程中对任务进行优先排序，应该把大任务排在最高优先级，所以应该在第一天就有人来接大而难的任务。无论如何，如果在冲刺的第二天，还没有人开始这项复杂的大任务，那么Scrum主管应该说‘我发现还没有人开始数据库压缩任务--这是一项大任务，如果我们要在这次冲刺中完成它，就需要立即开始。’“。

是的，您应该把冲刺中的所有东西都分解成小块，但是Scrum并没有说您应该沉迷于进度--当然不是让开发人员相互竞争。盖泽建议完全停止追踪个人的分数。他还指出，许多经理人可能需要重新学习他们的流程。“告诉管理层，一旦他们表扬一名开发人员或根据票量给他们加薪，他们就会从根本上改变行为。”

用户DJClayworth同意，主动忽略单个票证指标应该是一个很好的Scrum主管的工作：“重点应该是团队是否完成了作为一个团队的承诺。Scrum大师应该强调这一点，避免对每个人移动了多少故事进行任何讨论或衡量。

另一个关于将任务分成块的注意事项：拿起一小块拼图并不意味着忽视这个拼图。Llewell yn强调，Scrum过程不能成为完全忘记好的软件开发的借口。

“您应该对项目的发展方向有一个很好的了解，即使是在当前的冲刺阶段，您也可以在规划体系结构时使用这些知识。”Scrum并不能免除人们作为有经验的软件开发人员的本职工作，所以卢埃林的请求是向读者中的同龄人提出的。“你已经参加了计划会议，你可以检查积压的工作，你知道总体愿景是什么。你会希望避免在遥远的未来投入大量时间，但为一个可扩展的、模块化的系统奠定基础是没有错的，它能很好地满足你目前的需要，并将支持计划中的未来增加。“。

弹出的一件事是Done或DoD的定义，以及这如何有助于保持对个人的标准和期望。最紧迫的问题是谁创造了它，什么时候？至于“何时？”：尽快或在冲刺计划期间似乎是常见的建议。

对于“谁？”SpoonerNZ写这篇文章是为了回答另一个关于软件工程的问题。“完成的定义是由团队创建的，但如果团队没有明确的开发标准，则可能需要Scrum主管实施质量约束。例如，团队可能不想要代码审查或单元测试，但Scrum主管可能需要强制执行它们，以确保保持质量。在理想的情况下，团队看到了好处，想要这样的质量约束，但现实世界并不总是理想的。“。

谁需要共享国防部？嗯，当然，(困难的)目标是让每个人都在同一个团队中就这一点达成一致。不过，有充分的理由将其扩展到几支球队。甚至是一个组织。艾伦·拉里默对此表示：“如果没有对产品‘完成’的共同定义，质量和透明度将受到负面影响。组织级别的DOE定义应该是最低限度的、技术性的，有时由组织提供，这样才能得到普遍应用。该组织可以提供编码标准。组织可能需要自动构建，同时为每个产品提供创建和维护它的资源。‘完成’定义的任何部分，无论是由组织还是由个人开发团队创建的，都必须带来价值。“。

尽管它已经是Scrum指南的一部分，但可悲的是，讨论似乎表明，许多人都经历了经理在场的日常单口相声。正因为如此，他们觉得他们需要解释为什么门票比他们在与同龄人开会时花费的时间要长。所以重申一下：单口相声就是团队会议。正如最初的框架指南中所述：“每日Scrum是开发团队的内部会议。如果其他人在场，Scrum主管会确保他们不会扰乱会议。

如果您想要一个关于如何在Scrum框架中应用规则集的规则，Frank Hopkins用经典的格言“人重于流程”进行了评论，并详细说明，“一个好的团队应该定义它的流程，僵化的流程不会形成一个好的团队。”

另一位用户Meriton指出，Scrum取决于个人。“Scrum并没有说开发人员独立工作。它说，开发团队会自行组织起来，这意味着团队可以决定其成员如何协作。

nvoigt指出，Scrum中的团队之所以自组织，是因为他们来到一个项目时已经有了明确的任务。“Scrum建立在你们是一个团队的事实之上。在一个团队里，你昨天是否办好了“罚单”并不重要。在团队中，你同意你的目标是什么(即完成的定义)，然后努力实现它。在一起。“。

构建一个团队来做Scrum，不要指望Scrum来构建您的团队。

用户nvoigt用了一个体育比喻：“想象一下，11个人拿到一本足球手册，被告知每天上午10点左右在5号会议室进行15分钟的训练。你认为这就是一支优秀足球队的标准吗？”但是如果这11个人真的是很棒的职业球员呢？还是没有团队吗？不是的。只是这不是你组建团队的方式。就像团队运动一样，Scrum需要参与者成为一个团队。如果他们只是参与者，希望通过炫耀自己做了多少故事点或进了多少球来提高自己的地位，那么他们总是会输给一个共同合作的团队，而不是毗邻或相互竞争。“。

n Voigt准备承认Scrum“并不适用于每个人，也不是在每个星座都适用”，而且正如围绕这个问题的参与者所显示的那样，Scrum的一套规则可能会导致与预期相去甚远的现实。

有许多声音跳到Scrum的辩护上，重申这是将团队提升为伟大的团队，并赋予团队超越个人的能力。

临别的想法来自Seth R，他说，一般来说，敏捷的仪式没有什么可以期待的奇迹。要求他们魔术般地修复一支球队是要求太高了。相反，他的解释是：“这一切都是关于收紧反馈循环，这样团队就可以自我检查，自己找出如何变得更好。Scrum不会帮助您构建更好的产品，但如果您认真地进行自我检查，它可能会帮助您构建更好的团队。这反过来又会带来更好的产品。“。

不止一个人将这个框架比作民主。那么，除了所有其他开发过程之外，Scrum可能是最糟糕的开发过程形式吗？

或者，正如Scrum指南所述，它是一个简单易懂但难以掌握的框架吗？

标签：公告、Scrum、堆栈溢出