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

#1 楼

不要让Scrum成为淹没其他一切的过程
我和我的朋友（属于Scrum团队的成员）都不喜欢它。原因是，作为一个拥有专用流程管理器的流程，它通常会将其他所有流程弯腰折断，并成为这个总体流程，在此流程中，您除了Scrum仪式之外一无所获，并使这些Scrum仪式看起来很成功。 > Scrum的问题是：


冲刺（两个星期的部分）首先出现。由于在两周结束时有人询问我们是否已完成承诺的工作，因此优先考虑“完成”票。这就意味着要切工把车票弄完。冲刺结束时，我的团队不进行单元测试或代码审查。在我朋友的团队中，他抛出了if语句来处理QA发现的错误，而不是真正找到错误的根本原因来完成故障单。这个为期两周的重点可以导致无限缺陷方法论。显然，在Scrum中，它需要让产品负责人通过，但是除非他们迷恋边缘情况，否则很容易漏掉很多东西，因此不鼓励开发人员对此进行深入考虑。 Scrum和无数缺陷可以成为好朋友，因为无数缺陷方法可以使人为地提高速度，只要在冲刺后发现bug，就算是新工作。通过不断生成新的错误，您可能会以更高的速度。

每个人每天都能看到您的生产率，它成为一种简单的评估指标。拥有公共任务委员会意味着每个人都可以看到您在做事的速度，包括管理。我组织中的一些关键人员认为我的工作效率很高，主要是因为我相对于其他人移动了机票有多快。当以此为基础对开发人员进行判断时，通过QA的糟糕实施与经过良好测试，结构良好的实施是等效的。这就是星星可以减少到看起来平均水平的地方，因为该板+速度成为判断开发人员并变为他们关注的重点的方式。 Scrum继续讨论“自组织团队”。我为此写了另一个答案。总而言之，团队成员将按照他们喜欢的/被激励的方式去做事情，除非这加起来会成为一个有用的团队，否则很多事情不会完成，而团队成员只会继续前进乱七八糟。如果团队都有相同的目标和动机，他们可能会自我组织。问题是，这很少是真的。一个人想升职。另一个正在攻读学位。第三是提高去另一家公司的技能。另一个人只是不想拥有参数，因此同意任何东西，并让代码库变得一团糟。很多好的设计都需要开发人员坐下来，弄清楚事物应该如何工作。在Scrum中，您需要清除票证，并且对于工作质量没有真正的检查，因为“完成”或“未完成”是通常由非技术项目所有者决定的。这会激励人们陷入空白，专注于输出代码。

票证/用户故事迅速成为建筑。由于开发人员正在依次独立地处理每张票证，因此体系结构迅速开始镜像票证。门票通常是1-2句话的用户故事。票证驱动的体系结构迅速变得混乱，仅仅是因为需要根据需要堆积更多的代码。

开发人员的高度独立性意味着每个开发人员都采用不同的方法。考虑对对象进行排序。您可以在JS的前端，Java的后端或SQL本身中执行此操作，如果时间有限，则可以选择最容易实现的方法。尽管不一定是错误的，但是由于需要检查更多的地方，因此调试起来非常困难。

Standup实际上是“更新管理”。站起来是给开发人员的想法是荒谬的。有人真的等到9AM才报告问题吗？还是要立即在群聊中问？实际上，它是食物链中较高级别的人，它关注事物的移动速度，以便他们可以在当天晚些时候询问它。 。除非产品负责人是技术人员，否则Scrum会严重贬低它，因为产品负责人不会评估代码。它是功能驱动的，“运行”是所提供的用户故事的功能标准。 Scrum项目在两周内考虑了所有问题。没有前途。
优秀的开发人员通常被定义为能够解决难题的人员。 Scrum鼓励可以轻松完成并快速稳定地进行挑选的采摘工作。一个棘手的问题是开发人员在完成票证方面很慢。
经常会寻求伟大的开发商寻求建议和第二意见。但是任何时候这样做都会减少花费在制作票证上的时间，因此票证的速度会下降。
即使您遇到无法对完成的点进行正式判断的情况（如果在Scrum期间管理层主要是进行互动的情况下，也不会发生这种情况）仪式，因为这是他们在进度方面所需要查看的全部内容），人们仍将争夺注意力和回报。
要解决此问题，我将消除两个单独的速度得分，即消除站立时出现的管理层（否则开发人员强烈激励他们总是拥有好消息），并告诉管理层他们第二次称赞开发人员或根据门票数量给他们加薪，从而从根本上改变了行为。理想情况下，产品所有者也不是直接经理，因此激励开发人员在冲刺审阅和冲刺计划中表现出色的人。速度。测量的是关注的焦点，Scrum的测量的是输出速度，只有产品所有者从用户方判断输出。该指标不重视与优秀开发人员相关的许多行为。

#2 楼

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


正确地做到这一点。我读过的所有恐怖故事，不管是您的还是其他答案，都只告诉我一件事：那些人没有正确地做过。我明白了，这很难。制定一些规则并遵守这些规则非常容易，但这不是Scrum。 Scrum正在组建一个自组织团队。这并不适用于每个人，也不适用于每个星座。但这是基础，您所看到的一切实际上都不是成为团队的结果。 5号会议室。您认为这就是一支优秀的足球队的原因吗？但是，如果那11个人真的是非常棒的职业球员呢？还是没有团队？不会。甚至克里斯蒂安诺·罗纳尔多（Christiano Ronaldo）迟早都会得到这种“团队”的“平均”。但这不是足球的错。这不是建立团队的方式。

Scrum建立在您是团队的事实之上。在团队中，昨天是否完成“票证”并不重要。在团队中，您同意目标是什么（即完成的定义），然后努力实现目标。在一起。

如果一个优秀的开发人员每天与他们的团队交谈5分钟，那么他们的成就不会降低一点。如果一个优秀的开发人员被迫进入一个日常会议的管理不善的流程，他们会向经理报告他们是否完成了票务，那么他们将变得不感兴趣。

召开每日报告会议，您可以告诉经理您昨天的工作并尝试采用某种任意的绩效计划，这不是Scrum。这是众所周知的反模式。有人可能会称其为Scrum，并说Scrum指南说您应该每天见面，但这与真正的Scrum一样，实际上是人民民主共和国是人民的民主共和国。

正如团队运动一样，Scrum需要参与者成为一个团队。如果他们只是希望通过炫耀自己完成的故事点数或进球数来提高自己的地位的参与者，那么他们总是会把一天的时间输给一支相互协作而不是彼此毗邻或对抗的团队。

那么，如何防止Scrum将优秀的开发人员变成普通开发人员呢？雇用团队成员。一般情况下，平均水平并不重要，因为一个真正的团队每天都会击败随机收集的所谓“伟大”参与者。我并不是说那很容易。但这就是Scrum的目的。

#3 楼

Scrum是官方Scrum指南中定义的流程框架，其中除其他事项外，还说明了有关每日Scrum的以下内容：




每日Scrum是一个15-开发团队的分钟限时活动。


会议的结构由开发团队确定。


Scrum Master确保开发团队开会，但是开发团队负责进行每日Scrum。


每日Scrum是开发团队的内部会议。如果有其他人在场，Scrum Master可以确保他们不会打扰会议。每个人都只是想轻松地完成一天可以完成的事情，因此您可以在明天的日常工作中报告一些内容。

向谁报告？参加日常Scrum的人是其他开发人员（和Scrum主管，但他只关心过程，而不是进度）。
在实践中，这意味着您要向团队成员告知您的位置。这样他们就可以与您协调工作。您不应该进行报告，因为这意味着Scrum团队中不应该存在一定程度的等级。

如果什么都没有发生，您甚至在做什么？你让团队失望了！速度在下降！

谁在说？我无法想象开发人员会说，Scrum主管不应该在乎，因为他对进度不负责任，外部人员（例如产品所有者或管理层）也不应破坏会议！
无论如何是的，它不是Scrum。
Scrum指示Scrum管理员阻止这种情况的发生。如果允许这种行为，则据报导的任何人都将开始指导团队的工作，这违反了基本的Scrum原则，即

自组织团队选择如何最好地完成工作，而不是由团队外部的其他人指挥。

scrum坚持认为的原因如下：

Scrum用户必须经常检查Scrum工件，并朝Sprint目标迈进，以发现不希望的差异。他们的检查不应过于频繁，以免妨碍检查工作。在工作现场由熟练的检查员勤奋地进行检查时，检查是最有益的。

，Scrum承认在项目的所有参与人员中，开发团队最了解开发软件，并且礼貌地对待。请管理人员让专家工作。
所以当你说： >
Scrum表示衷心的同意，并竭尽全力赋予团队这种自治权。而且，由于“敏捷”听起来很酷，因此许多公司都会这样做，从而给Scrum取了一个不好的名字。
总而言之，防止Scrum功能失调的最佳方法是阅读Scrum指南，并按其指示去做。
/>

#4 楼

我想提出一个对大多数答案的对策。作为软件开发人员，我在敏捷团队中蒸蒸日上。我用这种理解来向管理层解释为什么现在需要修复一个错误，而另一个不那么重要，为什么我们需要在开始实现所需功能之前重构旧代码，或者公司将从中受益更好的测试覆盖率。另一方面，有时候，您确实需要一个快速且肮脏的原型，但是如果您不了解请求的来源，就很难做出决定。
参与项目计划（会议或待办事项梳理）使我有机会提出技术问题和/或提出一些小的修改，这些修改将以略有不同（例如风险较小）的方式实现相同的目标（或足够接近）。
获取频繁的更新同事的工作方式使我有机会帮助/指导初级开发人员并向经验丰富的同事学习。我们将需要进行一些更改，而不必在稍后的时间重新构建所有内容。频繁的测试意味着漏洞和未记录在案的边缘案例很早就被发现，并且更容易修复。关于满足效率，文档编制或缺少工具和培训的问题。

Scrum是一个可以缩短项目周期的框架，因此可以根据不断变化的需求调整产品。在任何给定的时刻，您都将专注于整个产品的一小部分，理想情况下可以单独运输。但是，这一切都不能免除您作为经验丰富的软件开发人员的职责。您已经参加了计划会议，可以查看待办事项列表，并且知道总体目标是什么。所有这些意味着您应该很好地了解项目的发展方向，并且即使在当前Sprint计划架构时，也可以使用此知识。您将希望避免在未来的遥遥领先上花费大量时间，但是为可扩展的模块化系统奠定基础并没有什么错，该模块化系统可以很好地满足您当前的需求，并且还将支持计划中的未来扩展。
我承认，只有在管理层配合的情况下，所有这些方法才有效。如果管理层本质上无视开发人员，则可以使用预定义的范围来确定固定的截止日期，或者，如果提前计划并进行开阔的思考，那么这是一个吃不完的环境，而不是专注于实现同一目标的团队不赞赏，那么，是的，最终您会放弃并诉诸于完成分配的任务。我去过那儿。但是，不要把这归咎于Scrum。
有了合适的团队和信任他们聘请的专家的经理，Scrum可以做出额外的努力，将一支好的团队提升为一支优秀的团队。

#5 楼

您的问题是：

如何防止Scrum将优秀的开发人员转变为普通的开发人员？您列出了团队所遇到的许多问题，尽管它们不一定是由Scrum引起的，但是不幸的是，这些问题是Scrum容易发生的。幸运的是，鉴于团队和有能力的管理层的善意，在Scrum框架中没有一个是无法解决的。团队中的单个开发人员不会自己解决问题，但这对于大多数团队问题都是如此。


每个人都只是想轻松地做一些事情，您可以
一天做完，所以您明天每天都有事情要报告。


这里有两个问题。团队以某种方式使他们想起了一个站立会议，以便团队以外的人可以每天检查他们的进度。那不是站起来的重点。站起来是团队内部的沟通。

要解决此问题，请以站起来简单地说出自己在做什么为准则。给出一个独立的报告是完全可以的，它说：“我正在研究导出到PDF功能，我希望明天继续。”如果该任务预计需要几天的时间，那可以肯定是所有这些天的报告。还可以说“我正在设计要导出为PDF的功能。我应该完成那个tommorow的工作，然后我开始编码。”每个人完成。重点应该放在团队是否完成团队承诺上。 Scrummaster应该强调这一点，避免对每个人移动多少故事进行任何讨论或衡量。

（顺便说一句，有人应该与经理们核实，如果他们不是每天都在讲故事，是否真的在被判断？开发人员认为他们需要在管理过程中每天都要做一些事情，这并不是未知数。实际上是希望他们做正确的事。）

第二个问题是如何捡到低挂的水果。如果每个人的目标都是善于站起来而不是完成良好的工作，这是自然而然的事情。但这不是Scrum应该起作用的方式。您应该对sprint中的任务进行优先级划分，并且应该对大型任务进行最高优先级的划分，因此，某人应该在第1天就接管较大的困难任务。无论如何，如果到sprint的第2天，没有人选择了复杂的大任务，那么scrummaster应该说：“我看不到有人开始数据库压缩任务-这是一项艰巨的任务，如果我们要完成本次冲刺，就必须立即启动它”。如果没有人提供您最好的开发人员，然后说“ Cecil，请问您能选一个。”不要忘了在冲刺结束时祝贺塞西尔（Cecil）表现出色。不理他们。您不会每天都在不断骚扰他们，要求他们知道昨天的工作以及今天打算做的事情。


非常正确。但是，如果管理层想要这样做，则无论是否正在使用Scrum，他们都会这样做。将此问题提交管理部门。他们可能对Scrum的想法不正确，或者他们可能认为日常骚扰实际上会使人们的工作更好（我没有，但是我遇到了有工作经验的经理）。无论如何，Scrum仅仅是这个问题的一个促成因素。如果有人拥有权限，请从团队成员中排除团队之外的人员，包括经理。 Scrum规则规定只有团队成员才能站起来发言。


有时候我会想一个人呆着，想一想几天的解决方案。


在一定程度上还可以，您应该（如上所述）自由地报告您“仍在思考问题”：然而，在2周的冲刺中，几天是很长的时间。可能会过分考虑问题，而敏捷方法通常旨在防止这一问题。如果您认为问题需要几天的设计，则应该在开始设计之前就要求设计高峰。如果您认为需要更多的考虑，请提前说。

您没有说一件事，但我怀疑这是相关的：保持代码质量是开发团队的责任。如果开发人员在做一件活泼的工作，请找到使他们做得更好的方法-但请记住，Scrum最多是这里的一个促成因素。懒惰的开发人员（或认为自己承受压力的开发人员）在任何开发方法中都会做得很糟糕。不信任[开发人员]，这是因为他们在没有持续监督的情况下无法完成工作。做得好。如果您的开发团队确实如此，那么请猜测-您没有优秀的开发人员。你们有一堆普通的开发人员，我真诚地怀疑Scrum对他们有很多负面影响。如果他们正在执行Waterfall或Kanban或非结构化的牛仔编程，他们将做同样的事情。

最后，如果您要放弃Scrum，将用它替换什么？瀑布？ BDUF？牛仔编程，每个人都可以做自己想做的事？

#6 楼

我认为您的情况和所引用的文字都存在问题，就是每天的混乱都以某种方式变成了完成最多门票的比赛。开发人员提供的票证数量是否是对其进行评判/评估时最重要的指标？不考虑门票的难度/工作量？

每天的聚会不应该是一场比赛，而应该是一个（简短的）会议，每个人都可以告诉他们他们现在在做什么，什么问题。他们遇到并看到/讨论他们是否可以互相帮助。

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

#7 楼

我还是一个与Scrum斗争的优秀开发人员（我认为）。我个人不但缺乏定义的过程，而且还因为以下原因而导致整体上无意识的绝望：

没有任何等级制度，所以与初中一样值得
一项任务必须在两周之内完成，所以没有时间进行有意义的单调循环了，
每天都在解释你在做什么（与谁无关）
每一个成功都是为了“团队”，但错误是你的错。
由于“需求改变”，完全缺乏长期目标。那不是真正的Scrum”，但这听起来很像没有真正的苏格兰谬论，所以我不会去那里。
我会尝试给您八年后得出的答案：


所有权：何时您有责任使某些事情完美地工作，您开始关心代码质量和体系结构，而当您什么都不是时，您实际上并不关心它会发生什么。


使他们成为一个团队：您不能强迫人们成为朋友，但可以提供帮助。下班后，进行各种活动，甚至让他们一起吃午饭都将有所帮助。


使错误成为每个人的敌人：没有什么能比一个共同的敌人更迅速更好地团结人们。当有一个虫子阻止所有人回家或搞砸他们的正常工作时，人们往往会团结在一起直到死去，尤其是当对杀人的人表示赞赏和感激之时。让虫子感觉像是敌人阻止他们从一个和平的工作日停下来。


让团队进行有组织的组织：没有人喜欢每天或提供报告，但是当某件事行不通时，请写下您的名字，并且需要您帮助解决该问题，在解决问题之前，您会打电话询问同事的意见。甚至那些将事情留给自己的人最终也会这样做或面临被解雇的威胁。最终，人们仅仅因为他们也处于这个位置而对彼此有所帮助。


开发人员将他们的项目视为自己的孩子。加以利用：没有什么比看到孩子的bug少或成功地承受意外行为更能使开发人员感觉更好了；同时，除了看到他/她的创作失败之外，没有什么比让他们感到烦恼的了。如果您平衡得足够好，您会发现他们的自尊心/羞耻度指标变得更有动力去改善他们的工作并争取时间做正确的事。这里要注意的一点是，大多数开发人员都讨厌使用遗留代码，因此耻辱不会奏效，但是当事情变得更好时，引以为豪。给他们一些时间：如果有人认为他们可以替换一段有缺陷的旧代码，并在短期/长期范围内将事情做得更好，请让他们尝试做为非约束性尝试。如果可行，那就太好了。如果不是这样，无论如何他们都会学到很多东西。但是不要指望人们会在空闲时间这样做。甚至Google都给员工留出时间进行副项目


更改指标：如果您的指标是“完成了许多用户故事”，您最终将让他们尝试所有简单的事情，但是，如果您的指标是“完成的最大复杂度平均数”，则最终，当他们认为有能力/愿意做到时，他们将与大型企业竞争。如果您还量化“ x模块每月的错误数量”，则可以极大地提高他们的信心，使他们尝试更多/不同的事情。


作为Scrum管理员，您的工作应该是在阴影中为他们工作。保持@nvoigt与足球的比喻，您的角色是担任裁判/现场工作人员：

确保他们拥有发挥最佳状态所需的一切
帮助解决人际关系问题，所以球队不会受苦
让他们发挥自己的优势，但要确保他们不要让守门员一个人呆着

我希望这个答案对您有所帮助。

#8 楼

如果您的公司正在滥用Scrum尝试使更多的工作从人中撤出，那么这种失灵将绝对导致您提到的这种行为。实际上，有很多组织心理学理论都支持这一观点。

Scrum以及几乎所有其他经验过程都旨在解决复杂的适应性问题，而不是在工厂生产票证或功能请求。冲刺目标应该是业务成果，而不是工作量目标。业务成果应该是最有价值的产品增量。我的经验是，在与我合作的95％的团队中，良好的冲刺目标可以最大程度地改变行为。

您必须查看您的情况并确定情况。在一个极端情况下，我见过团队成员重新执行他们说讨厌的所有做法的情况，唯一需要改变的是让一个团队成员带头并做一些不同的事情。另一方面，我看到过压抑性的公司文化，团队成员没有直接领导就无法做任何事情。而且我已经看到了介于两者之间的所有内容。

我可以告诉你，我曾在Scrum具有完全相反效果的团队工作。它提升了所有人的素质，并让伟大的开发人员大放异彩-不仅是个人，而且是领导者。现在，作为一个人，如果您在自己的环境中看不到它，那么您需要问自己的问题是：

1）您是否看到机会可以影响行为？ br /> 2）值得您付出努力吗？

这些问题的答案可以为您的下一步行动提供信息。尽管在很多（也许是大多数）情况下，Scrum肯定有可能创造出一个伟大的环境来激励人们去创造令人惊奇的事物，但参与人员需要付出大量的工作。如果您对自己所处的位置不满意，是否值得花大力气进行改善？还是您合适的人？而且，如果其中一个答案是否定的，那么您可能需要考虑这是否是您合适的地方。

#9 楼

已经有很多答案，但是我无法抗拒。如此之多的人感到有必要说些简单的事实，这表明Scrum令人沮丧。从管理层那里感觉到它正在失去控制。然后，他们通常从书中挑选一些概念，并将其植入团队。立即错误地开始。

正如Scrum的创建者所说的那样：遵循书中的Scrum规则可以使您的团队摆脱困境，但是随着您的进步，您不应虔诚地坚持下去。这在大多数团队中都是丢失的，因为将有一个通常不是最有能力的开发人员的Scrum主管，并且他只会及时认真对待流程，因为他终于找到了自己擅长的东西。 >因此，平均水平的提高在多个层面上起作用：不仅在单个层面上，而且在团队层面上。这不是不可能，但是环境正在对付它，大多数团队都会以一种消极的方式受到影响。

#10 楼

我所参与过的最成功的Scrum团队专注于产品负责人。这似乎是倒退的，因为Scrum应该与团队有关，但是如果您遇到了描述的问题，这种以产品所有者为中心的方法可能会有所帮助。最好的软件。这是在业务环境中制作最佳软件的框架。 Scrum最强大的方面是产品负责人负责使客户满意。它们是其他团队不受政治官僚主义影响的盾牌。

这当然不是Scrum独有的。任何值得一提的开发模式都会使企业远离开发人员所需的开发人员。使Scrum独特的是它选择放置在产品负责人手中的工具集。 PO可以期望团队提供的可见性和响应性与开发人员期望的自主权之间存在一个契约。最糟糕的是，每个人都知道我们可以依靠这套规则。但是在最好的情况下，这些团队并不害怕改变争执规则。 Scrum只是为PO和团队成员之间的谈判提供了一个框架：这是团队成员需要提供的，以便PO继续保持公司的其他成员不受阻碍。

我Scrum是由4人组成的团队进行的。我们要做的第一件事是放弃日常站立姿势。该团队已经开始紧密合作。站起来没有什么新的消息。但是每个人都知道，如果产品由于断开而开始受苦，那么这种立起来就可以依靠。

冲刺可能是Scrum用这种方式处理的最棘手的元素。我了解到的最重要的事情是“最小可行产品”一词。每个冲刺计划基本上都说：“作为采购订单，如果团队可以生产此产品，我可以向领导层证明团队正在做自己的工作，应该继续获得报酬。” MVP的性质随时间变化。在业务截止日期附近（敏捷可能会说这些不存在，但确实存在），MVP变得更加专注于可测试的生产力。在两次构建之间，MVP转向证明我们正在朝正确的方向发展。 PO和Scrum Master明确表示，由我们来决定每次MVP应该是多少。如果您的开发人员正在逐渐趋于平均，那么他们可能对此没有太多发言权。

我在Scrum中发现的最大的失败是，它使人们想要过度规划。如果您的速度为500点/周，则人们希望提前执行500点/周的任务。这导致了很多其他人提到的失败，人们只是为了完成工作而拥挤。预算要做的事情少得多（也许是200-300点），并使用MVP的概念指导中期开发。短跑。如果您发现必须对所有500点进行预算，那么您的结构将很脆弱，并且会阻止创新。如果我在冲刺结束时接了一个13点的任务，但尚未完成，又没有完成，我应该将其分解为5点和8点的任务，并完成其中的一项MVP的心态。如果5分任务的结果不是一个完整的单元，那么我会质疑这种情况的敏捷性。

但是应该怎么做？无论如何，PO都会出售团队正在正确完成工作的事实。

真实的故事：我曾在一个使用Scrum来控制一些失控的内部客户的团队中工作。这对我们来说是盔甲。我们发现他们的许多任务确实太敏捷了，无法适应混乱。等到下一个冲刺是不合理的。我们的解决方案是在两个并行过程中进行开发。我们让Scrum进行可以预见的事情，并为困扰开发的弹出窗口开发了自己的过程。我们的本土成长过程围绕着与客户的持续联系-如果他们不想与我们共舞，则应将任务放到Scrum中。

这对我们非常有用，因为我们的采购员发现他可以适当出售。如果我们花太多时间直接与客户合作，他们往往会意识到那是花费时间的方式，因此，当故事减少时，他们就可以了。每当他们只是想要“解雇”解决方案时，他们都会通过Scrum。每个人都在这里了解Scrum的力量：如果他们不采用我们自己开发的方法与开发团队合作，那么他们就必须在Scrum流程中“取得成功”。因此，对我们而言，这很有用。是每个人的解决方案吗？不。但这是产品负责人可以使用的东西。对于Scrum而言，产品负责人比大多数人更重要！

#11 楼

我不想将引用的每一部分分开，而是只关注您强调的一件事：


不是他们（经理）不信任他们，而是他们没有持续的监督就无法完成工作。


这是一个人的问题。 Scrum与此无关。这种微观管理可能是您和本文描述的所有其他问题的原因。解决方案是弄清管理层为什么认为团队需要微观管理，并解决该问题。弄清楚这一点，然后您的团队就可以按计划开始练习Scrum。在此之前，您将拥有一个有害的工作环境，管理层在团队成员之间竖起人造墙，每个团队成员都乐于接受这些墙，以希望与其他团队成员隔离开。输了没有团队。

#12 楼

我是一个由Scrum转变为平庸的体面的开发人员，主要是因为Scrum为我提供了摆脱它的途径，也没有理由理会，并强烈鼓励我玩这个系统。

Scrum在15分钟的站立时间中影响您的老板，并由老板评估您的表现。整整一天都围绕着1分钟的报告成功报告而建立。因此，做复杂的事情意味着它永远不会进入报告层次结构，因为复杂的想法需要一分钟以上的时间。

因为我要做的就是打滑并保持高速度。我和我的同事可以将很多时间重新分配给其他事情。我正在攻读硕士学位。另一个团队成员正在建立自己的创业公司。我的质量检查人员整整花了一半的时间进行编织。

Scrum假定员工关心公司或项目的成败，但我们不是因为我们是斑马，而不是动物园管理员。动物园只需要为我们赚够钱就不会饿死。主人是否吃饭无关紧要。另一个答案是一群人将输给一个团队。作为一名员工，输掉是完全可以的。如果我的项目一年结束，我为什么要关心呢？

我是一名专业Scrum开发人员，但主要是因为它使我几乎全职攻读硕士学位而获得报酬。

管理层中没有人对此感到满意，因为我们的团队的产量可能是9月份的1/3。但是，只要我们保持较高的速度，Scrum便对管理人员视而不见，无法了解积分生成和实际工作之间的区别。

要防止这种情况，需要关注个人表现，不仅仅是站起来和提高票速。 Scrum强调报告速度而不是其他任何事情，因此提交垃圾然后为自己使用时间是绝对有意义的。

自从我写了这个答案以来就出现了混乱：

一位开发人员急于在每日站立之前完成if语句。他跳过了最后一张支票，将其送交质量检查部门进行了8次检查，因此他们可以在9点之前对其进行检查。该支票仍然不存在，基本上将等待客户投诉。

产品负责人从高位撤回新订单时，大量任务中途放弃，剩下一半的工单需要宣布完成，以便进行前期生产。

生成30张票证以更改标题大小（仅CSS更改一项）。

#13 楼

奥斯陆大学发表了一篇关于每日站立的话题的论文。 https://www.uio.no/studier/emner/matnat/ifi/IN1030/v20/undervisningsmateriale/foiler-forelesninger/daily-stand-up-meetings-start-breaking-the-rules-stray-moe-sjoberg- ieee-software.pdf
他们提到了以下问题：

共享的信息被认为无关紧要，尤其是由于角色，任务和资历的多样性。 br />经理或Scrum管理员主要使用会议来接收状态信息。
由于白天休息，生产率降低。

他们的建议是：减少频率。午餐前见面。他们说，讨论自上次会议以来所做的事情对大多数参与者而言意义不大，因此可以省略。 Scrum非常适合咨询业务，在这些业务中，您需要与利益相关者进行定期跟进，而这些利益相关者很少从系统中了解他们的实际需求/需求。因此，您逐步向他们展示了自己所走的路，以便如果您设置了错误的路线，他们可以在早期阶段发出提示音。但是，如果您开发收缩包装的产品，则通常您的公司内都有专门知识，他们知道什么是什么，并且可以更频繁地咨询他们。您的开发人员可以俯身在办公桌上，随时获得输入。将其与CI / CD结合起来，您便会准备就绪。杀死冲刺。

#14 楼

Scrum（本身）并不能确保提供出色的软件

Daniel Pink认为优秀的团队具有三个特征：自治，精通和目标。有效地实践Scrum可以直接支持自治。它不能直接解决优秀团队的其他两个特征。

目的主要是由领导层建立的。正如亨利·Cloud（Henry Cloud）在《领导者的界限：结果，关系和可笑地负责》中所写，领导者得到了他们创造或允许的东西。目的明确性使团队始终专注于团队存在的全局，这使团队有效（即以正确的顺序做正确的事情）。

精通主要是个人行为/动机的函数。不受任何其他影响，我可以决定追求卓越并编写无缺陷的软件。

话虽如此，一个不好的过程会挫败一个人建立主人翁的动机。正如Geary Rummler和Alan Brache在“提高绩效：如何在组织结构图上管理空白”中所写的那样，如果您将一个出色的绩效人员与一个糟糕的系统相提并论，则该系统几乎每次都会获胜。

如何做我回应吗？

作为Scrum团队的开发人员，我可以决定在工作中追求自治，精通和目标。

要确立目标，我可以与我的经理了解我正在编写的软件如何为客户和公司创造价值。我可以利用这些知识来帮助团队专注于通过提高效率来最大化团队实现其目标的能力的工作。

为了建立精通，我个人可以致力于编写高质量的代码。当我学习出色的代码，实施个人和团队工程学科（例如，结对编程，测试驱动的开发等）时，将承诺转化为现实的事情就发生了，除非编写出具有生产质量的代码，否则决不要编写一行代码。

为了建立自主权，我可以与团队成员合作，了解我们如何允许逃逸缺陷来降低生产力。我可以使用这些信息来帮助产品负责人将工作纳入积压工作中，从而改善我们的工程纪律，以便团队可以将更多的时间用于实现目标，而减少返工/非增值活动。

#15 楼

把优秀的开发人员变成普通的开发人员也很不错。
每个人都只是想轻松完成一天即可完成的事情，以便在明天的日常工作中有所作为。

没有一个伟大的（甚至是非常好的）开发人员会这样做。在我参与过的所有拥有优秀开发人员的Scrum团队中，他们几乎都是专门选择最有趣且通常是最困难的任务，或者只是将下一个项目放在要做的事情的顶部。 >您问过如何阻止优秀的开发人员通过Scrum变得优秀。答案是正确进行混乱。您必须了解，目标不仅是要在站立状态中报告某些内容，还需要在冲刺和项目结束时开发出一款出色的产品。这就是目标。句号找到了解这一点的Scrum管理员和产品所有者，然后聘请也了解这一点的真正优秀的程序员。为他们提供完成工作所需的工具，然后摆脱它们。

#16 楼

原始帖子听起来好像出了三件事：
1。 Scrum团队不是团队
2。站立会议用于报告进度，而不是协调工作。
3。无法解决困难的问题。

日常Scrum会议的目的不是向经理或产品负责人报告进度，而日常Scrum会议是为了让团队成员之间相互协调。
由于在一个工作良好的Scrum团队中，您的主要受众是开发人员，所以每个人通常都知道您正在完成任务的难度，如果您选择了sprint中最困难的任务并报告了部分进度，那么没人会认为

如果您还没有这样做，我建议您使用故事点来估计故事的复杂性，这样可以使局外人清楚您的工作有多艰辛：确实完成了1个故事，B完成了5个故事，这与B完成5个1点故事和A完成1个13点故事是不同的图片。作为个人开发人员处理自己的故事。
以我的经验，Scrum的工作效果最好，当团队以团队的形式致力于冲刺积压工作时，以团队的形式工作，并以团队的形式共同实现冲刺的目标。团队，您不会等到最后一个人了解sprint的最复杂故事时，可以在团队日常讨论中讨论它：
A：“嘿，故事X看起来真的很重要，我们应该先这样做？谁来处理？”
B：“哦，我可以做到，但是除了可以管理之外，我从未做过Y。”
C：“我知道如何做Y ，我可以为您提供帮助。“

#17 楼

Scrum是一种敏捷方法论，但与敏捷并没有脱离。

敏捷宣言的第一个原则是这样说的：以及流程和工具之间的交互




Scrum方法论规定了一组流程和工具；如果这些流程和工具不适用于您组织中的人员，那么您需要放弃这些流程和工具或对其进行调整，直到它起作用为止。

人们是敏捷的中心，而不是流程和工具。尽管许多Scrum流程和工具都是构建工作流的理想起点，但遵循这些流程和工具并不是目标。一天之内就可以完成，这样就可以在明天的每日Scrum中报告一些事情。这是每个人都在尝试摘下的低挂水果。低挂水果和不难买票。这意味着您需要激励那些能够拿到更强硬门票的人，并且需要消除那些导致那些拿来更强硬门票的人感觉不到他们被低估的障碍。如果您的日常站立状态中出现了经理，那么请从日常站立状态中删除经理。

如果您的故事点估计不能正确反映出这些困难点的复杂性，那么请确保按比例反映这些点（尽管谨慎使用故事点来衡量个人的贡献） 。

如果滥用分数测量来衡量绩效，则在计划冲刺后从票证中删除故事分数。如果滥用您的票证的大小和数量来衡量绩效，则请删除进行这些衡量的人员，如果Scrum仪式的出现对团队造成不良影响，则从Scrum仪式中删除高层管理人员。

如果每天的站立导致摩擦，请重新考虑如何做这些站立。

我无法告诉您在每种情况下该怎么做。每个敏捷/ Scrum团队和公司都有独特的团队动态，这些动态不能用一些简单的规则来概括。找出对您的员工有效的方法，而不是Scrum理论告诉您的方法。最终，一切都应遵循第一条原则：“流程和工具上的个人和交互”。

#18 楼

TLDR

您应该使用回顾来解决流程中的问题，并使其与良好的业务成果（而不是教条）保持一致。

所以...


回顾时要坦诚相待。
不要忘记：任何业务流程的目的都是保持业务盈利。 （在此过程中确保自己的工作并促进职业发展通常是加分的。）首先，如果您担心流程无法有效利用团队资源，则需要在回顾中提到它。 “敏捷”流程具有准确的回顾，可以解决您当前流程中的问题。如果您的团队成员没有得到有效利用，则不同地使用它们可能对企业有利，因此提出了问题。也许您需要更长的冲刺才能将更复杂的项目纳入冲刺中。也许您需要通过冲刺项目来放弃“承诺”心态。也许您需要10％的时间，而高级或领导级别的成员最多需要20％或40％的时间。等等。

其次，不要忘记目的。敏捷性的目的是有效且可预测地利用程序员。并不是主要要让开发人员感到良好或发展自己的职业。只有在这些与业务成果保持一致的程度上，才值得追求它们。 ...如果他们与业务成果不一致，那么这些“伟大的开发人员”就需要在那些真正从“伟大的开发人员”中受益的公司找到工作。我们中的许多人都在为“伟大的开发人员”对业务产生严重，长期，积极影响的公司工作。在那些公司中，有效地使用这些人是团队内外的讨论的一部分。这通常意味着冲刺的结果通常是文档或POC而不是功能。这意味着他们要进行大量的代码审查和指导。等等...如果我实话实说，当我们团队内外真正出色的开发人员做出为期两周的承诺来提供复杂功能时，他们不会抱怨；他们完成了。我们明确地适应了我们需要交付的团队组成和业务成果。例如，与我合作过的大多数合同商店通过淘汰其他项目的副本而取得了更好的效果。其他人，拥有真正聪明的团队，一直在努力满足基本功能的最后期限，因为“伟大的开发人员”花了太多的时间来编写漂亮的代码和优雅的架构。但是，实际上，这种工作的必要性要比您想象的要少得多。当工作根本不复杂时，“伟大的开发人员”并不适合。如果他们找不到适合自己的创意才能与业务成果相结合的方式，那么它们实际上对业务是不利的。

#19 楼

引用的引用反映了对Scrum如何在一个健康的团队中工作的根本误解。争论的重点是“我们如何才能最好地发挥团队作用？”绝对不是“我们如何互相竞争才能看起来最好？”相互竞争以达到最佳状态并不是团队的一部分-这恰恰相反。严重出错。最主要的是您是否按时完成了在sprint中承诺的工作，以及是否有任何障碍要这样做。我希望人们每天都会报告站立时的某种进步，但是如果唯一的重点是“关闭很多东西以使我们的速度看起来不错”，那是错误的方法。换句话说，您实际上关心的是-看起来好还是实际上好？
事实正在发生，这也表明冲刺计划进展不佳。如果人们互相绊倒，试图获得低垂的果实并避免繁琐的任务，那么这就是一个严重的问题。产品负责人为什么不正确安排故事的优先顺序？当然，您的低垂果实不能比复杂的任务都具有更高的优先级。故事应该反映出一些可以为最终客户增加价值的可交付成果，而不仅仅是那些为开发人员每天关闭提供难得的成果的东西。再说一次，哪个更重要-看起来好还是实际上好？
最后，为什么人们不根据自己的能力进行工作？比起初级工程师，一个更有经验/技能的工程师应该承担更多的工作，并且工作更加复杂。如果不是，则Scrum管理员应对此进行回退。

#20 楼

考虑谁介绍了Scrum以及这些人引起的所有其他问题。
我只遇到了一位倡导Scrum的工程师。其他所有时间都是由MBA学员将开发人员强加给开发人员的，就像谷物被注入鹅一样。
在那个工程师的情况下，他的举止基本上像经理一样，信念与这样的Scrum，例如：


“聘请普通开发人员。好的开发人员就离开了。”使开发人员变得更懒惰。“ > Scrum导致medicore工程师出现的原因与中层管理者每小时敲击您的肩膀，举行无休止的会议，不为进行任何计划或准备而烦恼，然后大喊大叫会降低生产率。
最终，工作不再像您一样愉快日常的站立姿势，始终可见的Scrum板以及个人主动性与您的职业完全无关，这已经变成了苏联的无人驾驶飞机。 “团队”的东西）。
是否曾经看到过中层经理无视他们的工作而使某人沮丧？ Scrum将其构建到框架中。 Scrum项目的经理（产品所有者和Scrum Master）通常在技术上都非常愚蠢。 Scrum只用了两个星期的时间就取消了计划。有没有看到工程师在警告管理人员之后就停止关心他们了？ Scrum将工程师完全排除在决策室之外。
是否曾经见过工程师对项目的这一小部分感到自豪？在Scrum中，您没有分区。您注定是可替换的小部件。关心来自所有权，但是如果我什么都没拥有，我不妨只是胡扯，花我的所有权努力去做一个开源项目。
对于工程师而言，Scrum将工作变成了薪水。 Scrum还为工程师提供了很多方法来使薪水容易得多，例如夸大估计，只是盲目地执行规范中所说的任何事情，并产生更多需要修复的错误。至少可以逃避Scrum使得工程师无法胜任工作的艰苦工作。我曾经为那些被开除的人工作的最好的公司，这些人提出了糟糕的要求，因为这超出了预算。这使得他们在指定所需内容时非常谨慎。 Scrum使用票证，票证通常只是一个单词。
我实际上很喜欢瀑布，因为它是我的盾牌，可以防止人们胡思乱想。我不需要卷入外向型的争论。我不会因为糟糕的结果而受到指责。我什至可以拒绝进行有意义的对话。只要他们想要什么，我就可以指向页面和行。

#21 楼

在我所实践的敏捷中，每天开会是发信号通知您是否需要帮助的时间，特别是如果您的任务受阻时。每天召开一次会议是完全可以的，没有人要说什么有趣的话（然后意识到这一点并停止会议...）。现在不是时候报告您第二天完成的事情了。坦率地说，没有人应该关心您所做的事情，此信息已经存在于董事会中，并且仅与想要执行新任务的人有关。虽然通常会提出一个涉及经理的行动项目作为讨论的结果，但这当然不是一个存在等级的会议。回顾性会议。

处理任务的正式方法的重点是在需要努力的地方分配努力。您必须要求产品负责人清楚地确定工作的优先级，并尽可能少地更改优先级。半途而废的事情没有任何价值，因此完成大任务也是完全正常的。如果将大任务分解成较小的，冲刺大小的碎片（甚至更糟，分解为白天的碎片），则您进行中途做某事的风险会更大，尤其是如果分解任务的方式涉及将其分解为传统开发过程的步骤（通常是开发和测试）。

如果Scrum要求所有开发人员避免执行复杂的任务，则可能意味着产品所有者没有将这些任务分配给他们应有的优先级。冲刺的目标是达到明确定义的功能点和错误修复点，而不是无差别地“为点做事”。实际上，这意味着您有待完成的任务，并且在冲刺开始时，产品所有者和团队从该待办事项中协商出一部分任务，这些任务的子集将在冲刺结束时完成。处理不在该子集中但仍有剩余任务的任务是功能障碍。始终选择比团队在冲刺中可以处理的任务更多的任务也是功能失调。

#22 楼

数据则相反。 Scrum确实提高了团队的生产力和幸福感（我已经收集了过去十年来我执教的所有团队的数据）。
幸福一直是Scrum指南的一部分

“ Scrum Master鼓励Scrum团队在
Scrum流程框架内改进其开发流程和实践，以使其对于下一个Sprint更加有效和愉快。” >我所教练的大多数团队都说他们已经在做Scrum了，或者他们知道Scrum。几个月后，管理层允许的所有团队实际上都进行了混乱工作，他们一致认为他们一直在做的事情以及他们认为混乱的原因不是混乱。因此，简短的答案就像一些人已经说过的：“做对了”。正确做事与召开正确的会议无关。这是关于理解团队合作，是关于建立信任和增强团队能力（还有很多，但其他基础）