Alguna información de fondo
Soy parte de un equipo interno de desarrollo de software. Consiste en
- 5 desarrolladores (con experiencias que van de 2 a 5 años, soy uno de ellos)
- 3 personal de implementación (realizan la implementación y capacitación del software)
- y 1 gerente de proyecto.
Desarrollamos muchos proyectos pequeños y medianos, y sus líneas de tiempo generalmente se superponen. El desarrollo es así:
- "Cliente" nos da un conjunto de requisitos iniciales
- Desarrollamos el sistema a dicha especificación
- Presente dicho sistema al "cliente"
- "Cliente" nos da requisitos adicionales basados en dicha presentación
- Repita 2-4 hasta que el "cliente" se haya quedado sin nuevos requisitos o la fecha objetivo de implementación esté cerca
- Configurar e implementar el sistema
Esto, junto con el hecho de que es el "cliente" el que maneja los plazos la mayor parte del tiempo (que es una señal de alerta, por lo que veo aquí en Programadores y PM.SE) y no seguimos una metodología de desarrollo definida. a la codificación del vaquero, el código casi imposible de mantener y los errores que pasan por la producción, entre otras cosas. Es por eso que optamos por adoptar una metodología basada en Agile como Scrum.
¿Por qué scrum?
Fue la iniciativa de nuestro gerente, y todos parecen estar de acuerdo, dada nuestra situación actual.
El problema con Scrum
Algunos de los elementos de Scrum tienen conflictos con nuestra configuración actual que no podemos abordar fácilmente, en particular la naturaleza de "Jack-of-All-Trades" de los desarrolladores de Agile. El equipo de implementación no sabe cómo programar, y los desarrolladores tienen habilidades de comunicación y capacitación por debajo del promedio. Y esta alineación realmente no cambiará en el corto plazo.
La pregunta
¿Afectaría la efectividad de Scrum como metodología? ¿Serían necesarios otros cambios para compensar? ¿O sería mejor abandonar el pensamiento por completo y pensar en una metodología diferente?