敏捷方法是否与让承包商担任员工兼容？

一方面，敏捷方法强调了一个紧密的团队，彼此负责，并接受项目的集体所有权。

另一方面，公司使用合同程序员，以便他们可以管理资金的高峰和低谷而无需解雇实际员工。如果资金短缺，则承包商是第一个离开的人，即使他们是团队中完全整合的成员（也没有员工）。公司还只喜欢在有限的时间内保留承包商。一些承包商可以作为正式雇员被雇用的可能性在某种程度上减轻了这种负担。

因此，我的问题是，拥有一个由员工和承包商组成的敏捷团队以及存在极大不同地位的根本矛盾吗？

编辑：答案表明，我可能没有表达我正面临的紧张局势，所以让我再拍一次。

我是固定员工。敏捷方法（至少在这里已实现）鼓励我将团队的所有成员（包括永久雇员和承包商）视为具有凝聚力的团队的平等成员。公司对承包商的态度鼓励我将它们视为消耗性资源，我们不应过度依赖这些资源。

我很好奇其他人如何解决了这种紧张关系。

许多团队仅与敏捷承包商合作。一些公司（例如ThoughtWorks）都基于“出售”敏捷团队的想法。我们是一个由10家承包商组成的团队，他们为一家大型电信公司工作，全部来自同一家承包商公司。

我看到的问题是同一团队中有两家车身租赁公司……一段时间后，该团队出现了问题（无论如何与敏捷无关）。

是的，这绝对可以。诀窍是：

a）合理安排合同安排-如果您要为计件工作付款，那么承包商只愿意将事情打成一片，以减少“件”的工作时间，而对做更多的事情几乎没有兴趣
。b）向您的管理层出售并非他们支付的全部钱直接进入产品-将会进行一些培训/计划/讨论，这将是不间断的，最终将改进所说的产品。这对我来说是最难的部分。
c）选择合适的承包商-如果您可以继续雇用相同的船员，那么整个敏捷的事情就会开始得到回报。

我通常还认为，敏捷实践对这种情况有很大帮助-如果您一直有人员出入团队，能够结账，开火并开始编码，则比起其他情况更为重要。 。

根据您的编辑，有不同的视角来查看情况。因此，为帮助弄清任何潜在的混淆，有助于了解适用哪些观点。

从开发团队的角度来看，承包商和员工之间没有区别。我们都在同一个团队中，我们都有共同的目标。无论是员工还是承包商，添加和删除团队成员都会受到相同的干扰。所有团队成员都有相同的责任。

从管理角度来看，存在差异。该公司正在努力保护其最宝贵的资源-员工。因此，该公司宁愿保留其雇员而不是其承包商。如果承包商对团队证明无价，则公司很可能会尝试将承包商转换为员工。这些类型的决策不在日常开发过程中进行。

敏捷过程更关注日常开发活动，并管理如何交付优质产品。敏捷过程与管理职责（如租赁/解雇/合同决策）的关系较小，而与我们如何使用现有资源的关系较大。

先前的答案

这不是基本矛盾，但确实带来了一些培训挑战。敏捷过程营造了非常自然的指导环境。从本质上讲，程序员最终将始终是经验的代言人，至少与企业文化和团队敏捷度的细节有关。

无论您是否敏捷，拥有定期的合同程序员潮起潮落都会带来同样的挑战。您必须教育合同员工如何开展业务-这包括开发流程和计费。您必须对合同程序员进行系统当前设计的教育，以便他们可以尽快开始做出贡献。的希望是，合同的员工快速学习，并能启动真的很快参与该项目。在职培训（OJT）在这里效果很好。

归结为，当您雇用新的开发人员和承包商直到他们加快工作速度时，您的工作效率就会受到最初的打击。您做得越多，对团队绩效的负面影响就越大。古老的谚语Hense“将更多的开发人员添加到一个已经很晚的项目中会使其变得更晚”。（我相信那是弗雷德·布鲁克斯，除非他引用别人的话）。

作为一个非常关心敏捷并生产出色软件的承包商，我可以保证那里有承包商，如果他们能提供帮助的话，他们将永远不会产生slap-dash代码，并始终全心投入工作中。

诀窍是找到那些承包商。寻找证据表明他们已准备好进一步发展-博客，演讲活动，开源贡献，研讨会，推荐等。询问他们以前的敏捷经验，并寻找证据表明他们喜欢自己的工作。总的来说，我们了解到我们是临时雇员，有些人喜欢这样，他们利用合同之间的时间来磨练我们的技能并扩展我们的知识。

如果您能找到真正优秀的承包商，那么他们会增强团队的凝聚力，而不是削弱团队的凝聚力。在项目进行期间让我们保持在原位，然后在团队逐渐减少时让我们离开。如果您需要我们，我们将休假，并为下一个项目的启动做准备。

当您说临时合同会对团队产生负面影响时，您说的很对。实际上，速度受限于特定的团队配置。任何新的到达或离开都会使您几个月来所做的速度计算无效。

但是，它可以在承包商不是临时工的情况下工作。我参与了一个项目，该团队的团队是由95％具有一两个员工的承包商组成的。承包商在那里待了2到3年，直到项目被释放。放行后，员工进行维护。这种工作方式非常普遍。

总结一下：

敏捷，尤其是Scrum，将在一个稳定的团队中提供所有收益。