Alguna información de fondo
Soy parte de un equipo de desarrollo de software interno. Se compone de
- 5 desarrolladores (con experiencias que van de 2 a 5 años, yo soy uno de ellos)
- 3 personal de implementación (hacen el despliegue y la 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 "cliente" se haya quedado sin nuevos requisitos o la fecha de destino de la implementación esté cerca
- Configurar y desplegar el sistema
Esto, junto con el hecho de que es el "cliente" el que maneja los plazos la mayoría del tiempo (que es una bandera roja, por lo que veo aquí en Programadores y PM.SE) y no seguimos una definición definitiva. La metodología de desarrollo lleva a la codificación de vaqueros, código casi inexistente y errores que pasan a través de 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 con ella, 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 "todo el mundo" de los desarrolladores 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á pronto.
La pregunta
¿Afectaría la efectividad de Scrum como metodología? ¿Se deberían hacer otros cambios para compensar? ¿O sería mejor abandonar el pensamiento por completo y pensar en una metodología diferente?