应如何通过团队分配能力？

看完这个，我看到对于在具有不同能力的一组开发人员（又称几乎所有团队）中如何构建敏捷团队似乎存在很多分歧。是否应该将所有最好的开发人员放在自己的团队中，并给予最高优先级的工作？这几乎可以确保完成最重要的任务。同时，您剩下的地方是“不够完美”的团队，他们承担着技术债务，即使只是在低优先级任务上。另一方面，分布均匀的团队可以使落后的开发人员更好一些，但有可能挫败最沉重的打击者。另外，如果您将一堆好的设计模式与一堆糟糕的反模式混合在一起，那么您最终可能会得到一堆反模式。

A-Team有一些已知的风险，但是如果动态是正确的，那么我认为是的，我会将最有才能的人与最有潜力的初级开发人员一起放在最重要的项目上。对于优先级较低的项目，如果可能的话，您需要一位优秀的团队负责人来阻止他们偏离正常轨道。无论如何，技术债务都会发生。并非所有技术债务都是平等的。技术债务的成本/负债首先与项目的业务价值成正比，因此，虽然优先级较低的项目可能有更多的疣，但这些费用仍然比高优先级项目上的重大问题少得多是。

我记得我上大学时，有一位教授告诉我们关于团队结构的轶事（我看过他刚才在谈论的论文，但我似乎找不到）。

基本上，故事如下：

根据能力将一组程序员分成几组，其中最差的x个程序员被分组在一起，接下来的x个程序员被分组等等，而最好的程序员被分组在一起。

他们都被分配了相同的任务，并为其设定了完成任务的时间表。

在时间表结束时，组织者查看了任务的解决方案，令他们惊讶的是，他们发现性能最佳的解决方案来自由普通人组成的团队。相比之下，由A *程序员组成的团队则是最糟糕的解决方案之一，因为他们一直在争论什么是最佳解决方案。

如果您需要一支能够完成工作的团队，那么可以得到一堆普通人和一个可以领导的主导人物（这是研究的结论）（如果我没记错的话），否则，主导地位更高的成员将花费更多的时间进行战斗东西完成了！

绝大多数没有经验的开发人员可能无法独自提出健壮，优雅的设计，但是当他们看到一个时，他们可以识别并理解它。如果他们做不到，那么他们通常缺乏才干或准备工作的准备。

还有一些经验丰富的开发人员，他们能够理解非常复杂的软件设计，但缺乏判断何时能使简单的东西变得更好的判断力。

以我的经验，如果混合团队包含准备不足的成员，不必要的复杂成员或同时包含这两者，则通常只会遇到永久性问题。否则，如果您的团队遇到问题，通常可以通过更好的沟通或分配适当的角色来解决。

将最佳人才归为一个团队可能看起来是一个不错的短期解决方案，但长期来看这是失败的，并且会产生额外的成本。例如，当人们向技能更高的同事学习时，我的公司更愿意支付培训费用。如果您将最好的人分开，他们将无法将知识转移给技术水平较低的人。在短期内，您最好的团队可以表现出色，但是由于缺乏知识转移，熟练人员的数量不会增加。最好是一开始就没有表现良好的团队，随着人们技能的提高，在所有团队中提高绩效。

此外，如果技术人员决定离开该怎么办？谁来承担他们的项目？

还有一点是，团队应该由具有不同技能的人组成。您将始终拥有简单的任务（和无聊的任务），而这些任务却过于昂贵，无法由最高级的开发人员完成。

那些无法教书的人...

我认为还有更多因素需要考虑。

通过分配可以作为团队领导者教书的人，您将获得最大的价值。他们可以教团队的其他成员，并帮助提高他们的工作质量。

并非所有的高级程序员都会带来好的领导。交流信息的能力本身就是一项技能。这种技能不是通过编程经验来发展的。它通过教学和解释而发展。

分配“ A”团队有两个重要问题。首先是兼容性。拥有相处融洽的团队，比他们的“能力”重要得多。现在，这可能是两个“高”技能程序员，两个“低”技能程序员或混合使用。他们可以很好地合作，这意味着他们将提高生产力。

第二个问题涉及增长。除了不良习惯，两个“低”技能的程序员不会互相学习很多。同样，两个“高”技能的程序员不会互相学习很多。但是，将“低”和“高”技能水平相结合将有助于提高“低”技能的能力，也将提高“高”技能的能力。在您可以将其教给其他人之前，我不会将其视为“熟练”的技能。

从硬币的另一面来看，我认为保持能够“保持一致”的团队是有意义的。您的A团队类型的程序员不想等待B团队类型来完成自己的工作。您的B团队类型可能是A团队风格的工作流程所暗示的。