Scrum可以与平庸的开发人员合作吗？

Question

有人试图将Scrum吸收到大多数开发人员只是平庸的团队吗？ 我的意思是那些不是最精通技术的开发人员，他们的时间管理技能很差，但最重要的是缺乏个人责任感和承诺感。

你认为可以工作吗？或者你会尝试不同的方法吗？

Answer 1

我已经与这样的团队实施了Scrum。

他们需要花费一些时间才能加入，但他们发现Scrum让他们成为更好的开发人员。他们赞赏能够影响这个过程。在每次迭代的回顾中，我们检查了成功因素和挑战，作为一个团队，我们努力消除挑战所带来的障碍。

在那一年的员工表彰晚宴上，我的团队提名我获得一项成就奖：不是因为我的成就，而是因为团队在转向Scrum后所取得的成就。

由于他们在这个过程中没有发言权，所以很多球队都被击败并失去动力。缺乏个人责任和承诺可能是当前开发过程中的一个工件，Scrum可能会帮助您的团队克服这一点。

Answer 2

Agile Manifesto免责声明告诉您的问题。在第一点：

'个人和流程与工具之间的互动'

我认为如果个人遇到问题，那么方法论是徒劳的。

Answer 3

我有使用类似Scrum的方法与不那么理想的团队合作的“特权”，并且发现它比传统的瀑布式方法更成功，原因包括：< / p>

• 以较小的块完成工作（并测量进度），因此如果您的团队搞砸或错过了截止日期，您就会更快地知道并且可以更快地进行调整。让人们对一天工作项目与长达一个月的工作项目的问题负责也更容易。

• Scrum对团队内部的透明度抱有更高的期望，因此如果出现问题（因为他们肯定会遇到动力不足和/或动力不足的团队），您将更容易发现问题。在传统的瀑布式方法中，开发人员在数周内“变暗”会更容易接受 - 而对于糟糕的团队而言，这是可能发生的最糟糕的事情。

• 具有良好基本技能但邋and和/或没有动力的开发人员可以特别受益于Scrum的高接触，渐进式方法。

• 每日站立意味着每个团队成员必须至少每天出现在工作中并想出一些可以说他们一直在做的事情。这可以增加一些可能是懒惰或分心但又不想在同龄人面前尴尬的开发者的动机。立场提供至少最低限度的透明度和问责制，而不会让脾气暴躁的团队成员获得书面状态报告。

• Scrum对团队（业务所有者等）之外的外部透明度的期望也更高，因此更多人有机会看到您的开发团队有多糟糕，因此您更有可能获得贵公司的支持来升级您的团队。

• 如果您的团队中有好的和不太好的开发人员，Scrum（对透明度的期望更高，对个人所有权的期望更低而没有反馈）使得优秀的开发人员更容易帮助保持团队在轨道上。

请注意，我同意其他答案，理想的情况是建立一个更好的团队。但肯定有一些情况你没有选择，例如在运输前几个月救出一个项目出错，在那里更换团队是不可行的，你需要与你们的人一起做到最好。

Answer 4

许多敏捷评论家（和权威人士）都表示，敏捷只适用于优秀的开发人员。我倾向于同意。如果您相信我，那么Scrum将无法与平庸的开发人员合作。 ： - ）

为什么会这样？好吧，因为敏捷假设开发人员编写代码时会自动出现这么多东西。例如，建筑很少计划用于;随着代码的重复添加和重构，它应该会出现。聪明的开发人员可以实现这一点，但平庸的开发人员不能。

Answer 5

1. 大多数开发人员都是 平definition。大多数 那些认为自己很出色的人 比他们更多的工作 使每个问题和解决方案过于复杂。 真正优秀的开发人员很少见。
2. 许多团队成功使用敏捷方法。
3. 因此，敏捷方法非常适合平庸的开发人员。

Q.E.D。

Answer 6

您可以根据自己的情况使用SCRUM：

• 每日会议有助于让人们保持正常和负责任。
• 短冲刺让团队专注于特定任务，而不是迷路兔子
• 构建之间移动部件的减少意味着更少的重大错误。
• 拥有产品负责人意味着一支没有纪律的团队无法像在让他们狂奔一样轻松地焚烧飞行的资金。
• SCRUM通过实施惯例和短期目标教授纪律......类似于军事训练。

Answer 7

如果你在scrum框架中包含一些XP想法，你也可以将“弱”开发人员带到一点点。可能最好的例子是实现结对编程。起初我对此持怀疑态度，但现在完全被这个想法卖掉了。虽然它在某种程度上不属于Scrum方法，但您必须从所有敏捷方法中挑选出适合您的方法，而不是仅限于单个租户。

Answer 8

我没有亲自尝试过，但我看到一个项目在这个有问题的情况下下线。

敏捷开发需要开发人员的纪律。许多人认为敏捷意味着，没有文档，没有计划，没有规范......所以你不需要纪律。

但要成功使用敏捷方法需要承诺和责任。

如果您必须在这样的环境中工作，那么您更有可能通过使用更具指导性的方法取得成功。 不要忘记：只是因为你没有使用纯粹的敏捷方法（“完全按照他们在CSM课程中告诉我们的那样做”）并不意味着你不接受把时间盒迭代，配对编程等的好处带回家。你可以做很多好的实践而不使用scrum - 严格来说。

Answer 9

我喜欢Scrum的是： 团队对错误的团队成员施加压力。不是scrum大师，不是团队领导（scrum中没有这样的东西），甚至不是管理层。

这使得解决承诺和责任问题变得更加容易。

Answer 10

我很遗憾地说Jamie Ide的三分论点存在缺陷。它假设许多成功使用敏捷方法的团队（第2点）由第1点中描述的平庸的开发人员组成。但是，我们没有证据证明这一点。这些团队可能主要由高于平均水平的开发人员组成。这将为他们成功的原因提供另一种解释。

Answer 11

这取决于您对work的定义。

Ken Schwaber实际上在他的Google Talk中说，使用绝望工具并互相讨厌的垃圾开发者肯定会遵循Scrum规则并按时和预算生成垃圾软件的增量。

...所以我认为具有行业标准（即平均工具）的平庸开发人员和团队合作的平均水平很可能会按时和预算产生平庸软件的增量。

如果这就是你所追求的那么好 - 但这里有问题：

• 以后提高产品标准将非常困难。 （你可能会得到一个“设计死”的产品。）
• 通过聘请优秀的开发人员来改善事情，你将度过一段美好的时光。他们不想用bargepole触碰你的团队......

Answer 12

简短回答：是的，无论团队成员的天生能力如何，Scrum都能与团队合作。

答案很长：软件开发团队将拥有自然最佳的功能实现率。大多数球队都没有以最佳速度跑，因为他们正在对抗隐藏的障碍。 Scrum暴露了那些隐藏的障碍，因此可以解决和删除它们。一旦与流程相关的问题消失，团队就可以专注于技能提升，作为提高速度的下一步。

所以，也许一个协作平庸的开发者团队不会像协作超级巨星团队一样快，但是一个以最高效率工作的平庸开发人员的协作团队将比一个由主要人员组成的功能失调的团队更高效。超级巨星各自独自逃跑。事实上，一个由大多数普通开发人员和一位超级巨星组成的协作团队，可以指导团队成员并介入帮助解决他们的问题，这确实是一个非常富有成效的团队。

Answer 13

当然，它适用于这样的团队。它的工作方式是你和他们自己更快地理解他们必须培养一些技能。通过传统的项目管理，您可以在项目结束时找到它。

Answer 14

没有任何保证，但您可以使用Scrum实践来改进团队。

正如@Justin Grant所说，Scrum更高的知名度和透明度可能有助于平庸的开发者激励自己提高绩效。

将整个团队放在一个空间中以进行大量沟通。

使用结对编程 - 它可以传播知识并帮助人们避免被困在墙上。另外，people naturally spend less time on non-work if there's someone sitting next to them。

保持短跑的速度（尝试从1周开始），正如@richardtallent所说，让球队不会迷失在兔子的踪迹上。

从一个传统的3问题站立会议开始：我昨天做了什么，今天要做什么，以及我的方式。将那些可以提供帮助的团队成员配对。离线进行任何其他讨论。

注意将故事分成小块。如果报告听起来像“我正在继续使用GiantDatabaseControllerManagerFactory”而不是“昨天我已经为主要报告完成了打印预览。今天我将开始打印部分 - 它应该需要2几天或更短。“打破故事是一种技巧。研究故事分裂技术。

您需要一个好的产品负责人，他可以优先处理故事，以尽可能确保所执行的工作提供商业价值。

您将需要一个好的 Scrum Master，一个可以识别团队进度障碍并建议删除它们的步骤的人。您的组织需要赋予Scrum Master足够的权力来采取行动。

Sprint回顾展非常重要。问团队：什么有用？什么不能很好地工作？我们还需要什么？我们需要什么？我们应该为我们的流程添加什么？

并非每个人都能幸免于过渡到scrum / agile。

准备让一些团队成员抵抗。如果你无法说服他们尝试一些短跑，他们可能会离开，或者你可能需要给他们一个推出门。

对于平庸的团队来说，一些重要的事情可能会立即开始。

尽管我认为测试驱动设计（TDD）和持续集成（CI）很有价值，但它们并非易于学习，特别是如果团队不愿意这样做的话。如果您可以获得一些相当成功的冲刺，也许在其中一个回顾中，您可以通过提出TDD和CI来解决错误问题。如果你对团队感兴趣，看看你是否可以带一个教练和/或派一些团队成员上课。

Answer 15

是。 Scrum实际上非常擅长为那些没有自我驾驶，承诺和对工作充满热情的团队提高生产力。另一方面，从高度创新和专注的工程师那里听到scrum实际上减慢他们的速度并不罕见。

Answer 16

无论采用何种方法，良好团队合作的标志是能够与普通人取得优异成绩的能力。它非常关注动机，沟通和合作。如果你没有这些东西，那么个人的辉煌程度并不重要。

Answer 17

只是那些没有承诺/缺乏动力的开发团队，或者是组织内部的普遍感觉，即他们的态度只是更大的制度问题的症状？

在这种情况下，Scrum可以在这里更多有益（正如其他评论者所指出的那样）只要你有足够的影响力就可以让他们自由地完成任务。

Answer 18

我认为敏捷最重要的事情是你应该在小团队中工作。超过6人，你的团队太大了。我个人认为4是一个很好的数字。奖金是，对于规模小得多的团队，人们更乐意接受他们所做的事情并面对他们的错误后果（如果团队的其他成员乐于介入并帮助处理任何计划单，即不要坐下来责怪所有问题都犯了错误的人。很快人们就会学习如何安排好，因为他们正在安排这么小的任务。几个月后，他们会知道任何特定任务可能需要多长时间，系统将具有无可估量的价值。

如果他们在几个月后仍然受苦，那么它将永远不会起作用，而且，不太可能有任何东西让它们起作用。恕我直言，此时它值得承认它们毫无用处。有些人可能不同意，但如果你给人们机会并且他们不接受它们，你可以花费你的全部时间试图让它们变得有用，将它们移动到他们可以做的事情，或者摆脱它们。我没有看到很多其他选择......

Answer 19

一方面，在短时间内进行详细规划可以很好地进行。另一方面，如果让这些开发人员真正致力于在sprint中完成计划的工作，那么你将遇到问题。

我认为它可能比不做得更好，但我祝你好运。 ：）

Answer 20

我已经看到它使用普通编码器完成并且它有效。关于scrum的好处是，在每次迭代（sprint）中你可以用一些时间来提高他们的技能（书籍，视频......），将旧代码放入测试中 - 也许目标可能是放置1％的旧代码在每个冲刺中进行测试 - 清理混乱，进行一些编程，以便彼此学习......

Answer 21

平庸的开发人员绝对可以遵循Scrum并成功应用它。但这不是目的，最终是生产软件。他们会生产出好的软件吗？我不这么认为，或者至少没有这么高的速度。寻找创新的解决方案，编码，持久性，orm，软件设计和架构，单元测试，重构，代码审查，验收测试，构建，自动化等需要一些技能。为此，你需要有才能的人，或者至少需要几个alpha开发人员。

Answer 22

最重要的是他们的学习意志力。如果他们准备好学习和进步，那么Scrum可以指导他们。如果他们对所描述的事情感到满意，那么......

此外，还有Scrum 团队将更快地了解他们的工作方式，这可能会对他们构成挑战。

如果可能的话，添加经验丰富的开发人员以示例为导向。