问易失性极限编程小组

EN

我建议首先解决团队波动的问题。如果你的办公室首先有一个旋转门，那么任何过程都不会有很好的效果--我要说，如果有可能的话，使用一个更依赖于个人的表现和贡献的过程，会比“机器中的可更换的齿轮”更依赖于个人的表现和贡献。

在这种情况下，对对编程可能有效，前提是您可以让一些人在这里工作足够长的时间，以便他们能够向团队中的新成员传授他们的知识。然而，问题的一部分在于，您不能真正练习成对编程中的“对等于”部分，您最终会出现一个隐含的高级/初级情况，仅仅因为其中一半的人对代码不太了解。

大多数开发过程都依赖于一个相对稳定的团队，该团队对代码库非常了解。如果您没有这方面的知识，您需要围绕这样一个事实来设计一个过程:您将与那些试图在他们努力提高生产力的同时掌握代码基的开发人员打交道。

程序员配对是必须的，工程师实践(XP)和管理实践(SCRUM)能够以可持续的速度交付。对于一个工作团队来说，首先要强调的事情之一就是保持团队团结一致。如果这是不可能的，编程配对就更重要了！

对于瀑布，一个项目开始，人们聚集，然后他们必须通过形式，风暴，诺姆然后执行。一旦团队学会了如何一起工作，项目就结束了，工作组就解散了。然后再重复这个过程。你看到问题了吗？谁有这么多的钱，他们可以继续为球队的组建，风暴，诺姆支付成本，然后一次又一次的表演？

话虽如此，每个团队都会看到团队成员来来去去。通过程序员配对，您可以为团队带来新的人员，他们将几乎立即生效。通过配对，他们将非常迅速地学习业务领域、应用程序代码和工程实践。

我们带了一个4对的团队，并增加了3对新的团队。我们将所有新开发人员与经验丰富的团队成员配对。我们给了自己30天的时间让新成员跟上进度。小组完成了所有的任务。你能想象在瀑布团队中增加6个开发人员到一个由8个开发人员组成的团队吗？这支队伍几乎要停止吸收新队员了。

底线是，让一个功能团队团结起来。如果这是不可能的，有效地利用配对，使新的人很快上船。

当团队组成不稳定时，什么过程会起作用？至少在使用XP时，使用对编程，您可以希望超过一个团队成员对代码的所有部分都有一定的了解。FWIW，我不练习XP，我只是不明白使用XP是如何加剧这个问题的。