Por un lado, el enfoque ágil hace hincapié en un equipo muy unido que se responsabiliza mutuamente y acepta la propiedad colectiva del proyecto.
Por otro lado, las empresas utilizan programadores por contrato para que puedan gestionar los picos y valles de financiación sin despedir a los empleados reales. Si hay un déficit en la financiación, los contratistas son los primeros en irse, incluso si son miembros completamente integrados del equipo (y hay empleados que no lo son). A las empresas también les gusta mantener a los contratistas cerca por un tiempo limitado. Esto está algo mitigado por la posibilidad de que algunos contratistas puedan ser contratados como empleados regulares.
Por lo tanto, mi pregunta sobre si existe una contradicción fundamental de tener un equipo ágil con una mezcla de empleados y contratistas, y los estados muy diferentes que conlleva.
EDITAR: Las respuestas indican que es posible que no haya expresado la tensión que estoy enfrentando bien, así que déjame tomar otra oportunidad.
Soy un empleado permanente El enfoque ágil (al menos como se implementa aquí) me anima a ver a todos los miembros del equipo, tanto empleados permanentes como contratistas, como miembros iguales de un equipo cohesionado. El enfoque corporativo de los contratistas me alienta a verlos como recursos prescindibles a los que no debemos apegarnos demasiado.
Tengo curiosidad por cómo otros han resuelto esta tensión.
fuente
Respuestas:
Muchos equipos trabajan solo con contratistas ágiles. Algunas compañías como ThoughtWorks se basan en la idea de "vender" equipos ágiles. Somos un equipo de 10 contratistas que trabajan para una gran empresa de telecomunicaciones, todos de la misma empresa contratante.
Donde vi problemas fue cuando había 2 compañías de alquiler de cuerpos en el mismo equipo ... después de un tiempo, el equipo se volvió problemático (de todos modos, nada que ver con ágil).
fuente
Sí, esto definitivamente puede funcionar. El truco es:
a) Estructurar el acuerdo de contratación correctamente: si está pagando por trabajo a destajo, entonces los contratistas tienen poco interés en hacer mucho más que juntar las cosas para poner menos horas en la "pieza"
b) Vender a su gerencia por lo que no pagan cada centavo entra directamente en el producto: habrá algo de capacitación / planificación / discusión en curso que estará en el reloj y, en última instancia, mejorará dicho producto. Esta fue la parte más difícil para mí.
c) Elija los contratistas adecuados: todo lo ágil comienza a dar sus frutos si puede contratar continuamente al mismo equipo.
En general, también afirmaría que este tipo de escenario se ve muy ayudado por las prácticas ágiles: si hay personas que vienen y salen del equipo todo el tiempo, poder verificar, disparar y comenzar a codificar es aún más importante de lo que es .
fuente
En respuesta a su edición, hay diferentes pares de ojos para observar la situación. Por lo tanto, para ayudar a aclarar cualquier posible confusión, es útil comprender qué perspectivas se aplican.
Desde la perspectiva del equipo de desarrollo, no hay diferencia entre el contratista y el empleado. Todos estamos en el mismo equipo y todos tenemos el mismo objetivo. Agregar y eliminar miembros del equipo tendrá la misma interrupción, ya sean empleados o contratistas. Todos los miembros del equipo tienen las mismas responsabilidades.
Desde una perspectiva de gestión, hay una diferencia. La compañía está tratando de proteger su recurso más preciado: los empleados. Por esa razón, la compañía preferirá mantener a sus empleados sobre sus contratistas. Si un contratista resulta invaluable para el equipo, es probable que la compañía intente convertir al contratista en empleado. Este tipo de decisiones viven fuera del proceso de desarrollo diario.
Los procesos ágiles están más interesados en las actividades de desarrollo del día a día y en la gestión de cómo entregar un producto de calidad. Los procesos ágiles están menos preocupados por las responsabilidades de gestión, como las decisiones de contratación / despido / contrato y más preocupados por cómo usamos los recursos disponibles.
Respuesta anterior
No es una contradicción fundamental, pero presenta algunos desafíos de capacitación. Los procesos ágiles fomentan un entorno de tutoría muy natural. Esencialmente, los programadores del personal terminarían siendo siempre la voz de la experiencia, al menos en lo que respecta a la cultura corporativa y los detalles de cómo el equipo es ágil.
Tener un flujo y reflujo regular de programadores por contrato presentará los mismos desafíos, ya sea ágil o no. Debe educar al empleado contratado sobre cómo hacer negocios, esto incluye procesos de desarrollo y facturación. Debe educar al programador contratado sobre el diseño actual del sistema para que pueda comenzar a contribuir lo más rápido posible. La esperanza es que los empleados contratados sean estudios rápidos y puedan comenzar a contribuir al proyecto realmente rápido. On-the-Job-Training (OJT) funciona bastante bien aquí.
Todo se reduce a que tendrá un impacto inicial en la productividad cuando contrate nuevos desarrolladores y contratistas hasta que se pongan al día. Cuanto más lo hagas, más afectará negativamente el rendimiento de tu equipo. Hense, el viejo adagio "Agregar más desarrolladores a un proyecto ya avanzado lo hace más tarde". (Creo que fue Fred Brooks, a menos que él citara a alguien más).
fuente
Como contratista que se preocupa mucho por Agile y produce un excelente software, puedo prometer que hay contratistas que nunca producirán código slap-dash si pueden evitarlo, y siempre ponen su corazón en lo que sea que estén trabajando.
El truco es encontrar esos contratistas. Busque evidencia de que están preparados para ir un poco más allá: blogs, charlas, contribuciones de código abierto, talleres, recomendaciones, etc. Pregunte sobre su experiencia ágil anterior y busque evidencia de que aman su trabajo. En general, entendemos que somos contrataciones temporales, y a algunos de nosotros nos gusta esto, usando nuestro tiempo entre contratos para perfeccionar nuestras habilidades y ampliar nuestro conocimiento.
Si puede encontrar contratistas realmente excelentes, mejorarán la cohesión de su equipo en lugar de restarle valor. Manténganos en su lugar durante la duración del proyecto, luego déjenos ir a medida que el equipo se desmorona. Nos tomaremos unas vacaciones y estaremos cerca para el inicio del próximo proyecto, si nos necesita.
fuente
Tiene toda la razón cuando dijo que los contratos temporales afectan negativamente al equipo. De hecho, la velocidad está vinculada a una configuración particular del equipo. Cualquier nueva llegada o salida invalida el cálculo de velocidad que hizo durante meses.
Sin embargo, puede funcionar cuando los contratistas no son temporales. Trabajé en un proyecto en el que el equipo estaba formado por un 95% de contratistas con uno o dos empleados. Los contratistas estuvieron allí durante 2 o 3 años hasta que se lanzó el proyecto. Después de la liberación, los empleados hacen el mantenimiento. Esta forma de trabajar es muy común.
Para resumir:
fuente