Scrum框架的主要思想是组织开发过程，以便在项目生命周期的各个阶段更快地执行工作。但是，这种方法是否总是将开发人员推向正确的行为？许多参加了上述问题讨论的用户在Stack Overflow上，开发人员偷工减料，过分强调分配给门票的高分，甚至假装在经理面前表现出色的员工时，也会经历类似的事情。如何避免这些危险？ 有问题的问题已经从workshop.stackexchange.com移至softwareengineering.stackexchange.com。这表明程序员认为围绕Scrum及其有效性的考虑已经足够严重，已经超出了管理软件开发周期的范围。他们感到这种项目管理方法对整体工作环境的影响。
Scrum是导致不良开发实践的原因，还是仅仅是这个问题的借口？
许多争议引发了关于Scrum对团队和个人开发人员的影响以及该框架对使用它的人员的限制的猜测。许多人将团队失败归咎于Scrum，但其他人则认为这是归因错误，并且开发团队中问题的根源更加深远。
Scrum的拥护者认为管理不善是问题的根源。这是用户Llewellyn所说的总结：“管理本质上忽略了开发人员。为了达到预定的结果，必须满足固定的期限。这项工作不是由专注于实现同一目标的团队完成的，而是由每个人都只关心自己的一群人完成的。不鼓励事先计划和跳出框框思考。结果，在这种情况下，程序员屈从于环境并在简单执行分配给他的任务中找到了救赎。我在这种条件下工作。但是不要为此责怪Scrum。”
用户DJClayworth表示了许多评论，表示认为自己承受压力的程序员在任何开发管理方法论下的表现都会很差。
用户马丁·马特（Martin Maat）最好地表达了对这一问题的相反意见，他提请观众注意这样一个事实，即许多人认为需要对此问题发表意见，这说明Scrum使他们感到沮丧。
使用Scrum的常见麻烦是什么？
评论中出现了一些常见的Scrum陷阱，这可能是因为该框架被滥用或实际上是Scrum固有的问题。这里有将近十二种此类问题引起了我们的注意。
▍1。日常会议适合经理
对Scrum的第一个批评与这样的事实有关，即在日常会议（站立）中出现了不必要的趋势。支持这种想法的一个论据是，站立式会降级为事件的状态，事件的参与者只会按照他们对生产率的看法行事。特别是如果经理出席此类活动。因此，用户Matthew Gaiser（他已经为我们写过书，但我们偶然发现了他的评论）被称为站立事件，旨在向管理人员告知当前情况（更新管理）。）。他认为，此类事件中的开发人员演示只会鼓励管理者观察他们正在做的事情，但这没有用。当每个团队成员都以自己的模式工作时，对于分布式团队来说更是如此。
▍2。完成任务起着重要作用
评论中提出的另一个想法是，任何将大型任务划分为较小任务并监视这些任务的进度的开发方法，都会（无论有意还是无意）导致评估工作的新方法。如果您只是开始应用一些指标，它将影响根据这些指标对其绩效进行评估的人员的行为。
许多评论者说，这意味着开发人员可以“偷工减料”以完成当前sprint中需要完成的工作。用户盖瑟指出的问题和其他用户使用的是正在处理的单独的票证，在冲刺期间将其转移到“就绪”类别中，这就是“黑匣子”。无论此“黑匣子”内部是什么，都不会影响评估工作速度的结果。用户盖瑟（User Gaiser）写道，通过质量检查部门进行的低质量实施与经过完美测试和设计的实施没有区别。结果，证明了关闭票的数量是劳动生产率的不可靠指标。
▍3。不团队合作的高效率开发人员
另一个主题讨论了优秀的程序员和优秀团队之间的紧张关系。当每个人都遵循Scrum方法论时，一些开发人员可能会非常有生产力，但是“团队”却会被遗忘。Gaiser用户说，没有适当的激励措施，自组织是无法实现的目标：“团队成员将按照他们认为合适或有针对性的方式解决问题。如果没有建立团队，那么将会剩下很多，团队成员只会混乱地前进。”
他继续说：“此外，允许每个开发人员选择自己的方法来解决问题，这意味着调试代码更加困难。”
▍4。困难的任务推迟到以后
同样，Gaiser继续批评生产力的幻想。他说，在应用Scrum时，主要重点在于使票证进入“就绪”状态。同时深思熟虑该任务似乎没有多大用处。因此，开发人员可能倾向于执行简单的任务，而避免执行更复杂的任务。用户盖瑟（Gaiser）再说一遍：“ Scrum鼓励开发人员执行一些简单的任务，而这些任务需要花费一些时间来解决，这使开发人员能够始终如一地表现出高性能。” 结果，事实证明，日常任务选择和日常工作报告推动了需要一天完成的任务的选择。
5英镑 产品功能比代码质量更重要
Gaiser始终认为，使用Scrum框架会导致产品质量下降：“开发人员的出色程度通常取决于其开发可靠代码的能力。除非产品所有者理解编程并审查代码，否则Scrum会严重贬低项目的这一特征。'' 他在这里强调，票证的“准备就绪”通常不是在检查代码质量之后确定的，而是仅在实现相应功能之后才确定的。
▍6。缺乏时间与同事讨论工作问题
如果发展速度是团队效力的唯一指标，则意味着团队成员不再有时间互相讨论某些问题，征求他人的意见或检验他们的想法，谈论他们。这正是使团队成为团队的原因。用户盖瑟（Gaiser）在这里再次说：“优秀的开发人员经常会与其他开发人员进行磋商，并寻求意见的替代方案。但是，此类课程占用了关闭票证的时间，这减慢了开发速度。”
7英镑 最近发现的错误必须等待
Scrum的另一个不良行为是“在冲刺之后发现了错误，并认为它们是新任务”。由于当前的Sprint中无法包含其他任务，因此这可能会迫使开发人员发布低质量的代码。
8英镑 票务驱动架构
票务系统不仅基于开发人员为自己选择的任务。Gaiser用户还说，由于开发人员按票证出现的顺序并彼此独立地工作，因此疏忽地使用Scrum会导致混乱的项目体系结构。结果，“架构很快成为票证的反映”。
9英镑。影响到所有事物的开发管理方法论
阅读讨论内容时，您可以留意评论，作者的评论指出，所有问题的根源在于缺乏对Scrum规则的严格遵守。但是，盖瑟（Gaiser）最强烈的反Scrum主张是该框架取代了其他一切。这可能会破坏强大的团队。 “ [Scrum]扭曲并破坏了任何其他开发管理机制，该框架变成了一个无所不包的现象，其中除了统一执行仪式外，什么也没有做，而执行这些仪式会产生成功的幻觉。”
我们已经讨论了很长的问题列表，这些问题可能由使用Scrum引起，也许由于使用此框架而变得更加明显。但是，在我们正在研究的讨论中，您可以遵循Scrum规则找到与开发人员如何和平与和谐生活有关的想法。
如何充分利用Scrum？
对盖泽尔评论的许多回应都获得了很多正面评价，这些评论是他所说的不是Scrum。这是用户Stephen Byrne关于此问题的内容：“我认为这是一个很好的答案，并提供了一些有价值的见解，但是我必须同意许多其他评论者的意见，这里所描述的绝对不是Scrum，并以Scrum的名义进行查看。” 但是许多人要么公开讨厌Scrum，要么同意Gaiser用户的意见，即如果使用Scrum时出现问题，则意味着该框架的使用不正确。
如何正确使用Scrum？
▍1。日常会议与每天捡新票不同
许多人说，每天的会议迫使开发商每天关闭门票。但是，正如DJClayworth指出的那样，您不能不对任务进行优先级排序。如果优先级不是自然设定的，那么此任务应由Scrum Master接管：“我们需要在sprint中确定任务的优先级，较大的任务需要被赋予更高的优先级，因此，某人必须在sprint的第一天承担艰巨的任务。无论如何，如果到第二天没有人完成一项大型而复杂的任务，Scrum Master应该说：“我没有人承担过压缩数据库的任务。这是一项艰巨的任务。如果要完成冲刺，我们需要立即开始执行此任务。”
▍2. ,
在sprint中解决的所有任务都应细分为小部分。这是不可否认的。但是Scrum框架并不是说开发人员应该痴迷于指示结果的指标。 Scrum不建议让开发人员互相竞争。用户Gaiser建议完全放弃对程序员个人要点的考虑。他指出，许多管理人员可能需要重新检查Scrum的规则：“告诉管理人员，他们称赞开发人员或基于封闭门票给予晋升的那一刻，就成为他们从根本上改变团队行为的那一刻。 ”。
用户DJClayworth同意故意忽略与单个票证相关的度量标准应该是优秀的Scrum Master的任务之一：“应将注意力集中在确保团队实现团队目标上。Scrum Master应该坚持这一行为，并避免基于团队中每个成员提升了多少用户故事而进行任何讨论或度量。”
▍3。您需要为实现大目标而采取一些小步骤，但是采用这种方法，您不会忘记这些目标。
这是将大问题分解成小块的另一个想法：“如果您正在研究一个难题的一小部分，这并不意味着您就不必忘记整个难题。”
用户Llewellyn指出，使用Scrum并不是完全忽略高质量软件开发原理的借口：``您必须对项目的去向有一个很好的了解。这些知识可以用来计划项目的架构，甚至可以在当前的sprint中参与计划。”
Scrum并不能使程序员从工作中解放出来，而将他们所有的知识和经验投入到工作中。因此，Llewellyn的电话是给评论的读者中的程序员：“您正在开会，可以查看积压的产品，您知道组织中项目的总体愿景是什么。您要努力避免在遥远的未来上花费大量时间。但是为可扩展的模块化系统奠定基础并没有什么错，该系统将适合于解决当前的问题，并使您能够创造已经计划好的其他机会，而将来不会出现任何问题。”
▍4。有必要确定“完成”是什么意思
我们正在讨论的讨论中提出的主题之一是“完成定义（DoD）”标准，以及定义这些标准如何帮助单个程序员遵守某些质量标准并了解对它们的期望。这里最紧迫的问题是谁以及何时制定这些标准。对于“何时”，通常要么是关于尽快制定标准，要么是关于在冲刺计划中应如何制定标准。
谁产生国防部的问题的答案由用户SpoonerNZ以另一个问题的答案的形式编写在软件工程网站上。 “准备标准是由团队创建的，但是此过程可能需要Scrum Master的存在。如果团队没有明确的开发标准，这对于设置质量限制很有必要。例如，一个团队可能不想弄乱代码审查或单元测试，这将导致ScrumMaster将所有这些都添加到DoD中以确保高质量的开发。在理想的情况下，了解了所提供功能的团队会很乐意接受它，但是现实世界并不总是理想的。”
谁应该遵守国防部工作？一个自然的（且具有挑战性的）目标是确保国防部概述的规定适用于一个团队，并确保得到该团队所有成员的支持。但是有充分的理由将国防部的影响力扩展到多个团队。甚至整个组织。这是用户Alan Larimer所写的内容：“缺乏针对产品的普遍认可的国防部定义会对工作的质量和透明度产生负面影响。国防部的组织水平应该是最低限度的，技术性的，有时是特定于组织的，这可以提供防备标准的普遍应用。组织可以提出编码标准。组织可能需要自动创建程序集，从而为创建和维护每个产品的程序集提供资源。国防部的任何部分，无论是由组织还是由单个开发人员创建的，都必须为准备标准带来一些有价值的东西。”
5英镑 管理者必须扮演沉默的观察者的角色
尽管本节标题中的内容已经包含在官方的Scrum手册中，但是对讨论的分析表明，不幸的是，在经理参加的日常会议中经常违反该规则。因此，程序员感到有必要解释为什么票务工作比计划花费的时间更长。如果只有程序员参加会议，则几乎不需要这种解释。这是Scrum手册对此所说的：“每日Scrum是开发团队的内部会议。如果其他人在场，Scrum Master会确保他们不会干扰会议。”
▍6。人比流程更重要
有关如何应用Scrum规则的指导，请阅读用户Frank Hopkins所写的文字，以提醒您一个经典的原则：“人比过程更重要。”为此，他补充说：“一个好的团队应该定义其流程，严格定义的流程不会有助于一个好的团队的形成。”
另一个用户meriton指出，Scrum的使用取决于各个程序员：“ Scrum并未规定开发人员彼此独立工作。 Scrum规定开发团队是自组织的，也就是说，团队要对其成员之间的交互方式做出决定。”
用户nvoigt笔记Scrum中的团队进行自组织是因为他们来到了一个已定义任务的项目：“ Scrum框架基于您是团队这一事实。团队中的门票是否由特定程序员昨天关闭并不重要。在团队中工作的任何人都了解目标（即国防部），并努力与团队其他成员一起实现这一目标。”
7英镑 建立像Scrum一样工作的团队，但不要指望Scrum能够创建团队
用户nvoigt运用体育比喻：“想象一下11个人收到了一份印刷的足球手册。他们被告知每天需要在上午5点在5号会议室练习15分钟。您认为结果将是一支好的足球队吗？如果这11个人是优秀的职业足球运动员，该怎么办？该命令仍然无法正常工作吗？是的，不会。只是足球队不是这样创建的。像任何团队运动一样，Scrum需要那些使用此框架的人成为团队。如果只是一群人，每个人都只想通过显示他们在用户故事中涵盖的点数或实现的目标数来为自己赚取积分，那么这组人将永远输给一个成员团结在一起，而不是彼此相邻的团队。朋友，或彼此对抗。”
结果
nvoigt 用户愿意承认Scrum“并不适合所有的人或团队。” 而且，正如社区对我们在此讨论的问题的兴趣所表明的那样，应用Scrum可能推动开发的一组规则可能导致工作环境与它想要构建的环境相去甚远。
我们想用用户Seth R的话来总结此材料。...他说，没有必要指望敏捷仪式带来奇迹。那些寻求帮助的人（就像是魔术师）想要太多，以纠正开发团队的缺点。他是这样看待这种情况的：“这一切都是为了加快反馈速度。结果，团队有机会进行自我审查，并就如何工作以获得最佳结果做出决策。 Scrum不会帮助您创建更好的产品，但是如果您认真对待自我测试，它可以帮助您建立更好的团队。反过来，这导致了更好的产品的开发。”
许多人将此框架与民主相提并论。因此，除了其他所有人以外，也许Scrum是最糟糕的开发管理形式？
或如官方指南所述，它可能是一个易于理解但难以完美掌握的框架。
您将如何回答本文标题中的问题？
