1 ScrumBut
La siguiente imagen muestra el ciclo de vida del marco de trabajo conocido como SCRUM. Se dará un repaso para recordar el ciclo de vida.
Figura 1.1: Ciclo de vida de SCRUM
Los principales elementos de la metodología SCRUM son lo siguientes:
- El Equipo Scrum
- El propietario del producto (Product Owner)
- El Equipo de Desarrollo (Developers)
- El Scrum Master
- Eventos de SCRUM
- La iteración (Sprint)
- Planificación de la iteración (Sprint Planning)
- Reunión diaria de SCRUM (Daily Scrum)
- Revisión de la iteración (Sprint Review)
- Retrospectiva del Sprint (Sprint)
- Artefactos de Scrum
- Product Backlog
- Sprint Backlog
- Incremento
- Transparencia de Artefacto
- Definición de “Hecho” (Done)
El hecho de que un equipo de trabajo desarrolle software haciendo uso de algunos de los elementos de SCRUM no significa que lo esté llevando a cabo correctamente, es ese el momento en el que lo que realmente se hace es un SCRUM-But. Scrum-But se refiere a las razones por las cuáles el equipo no puede sacar el máximo provecho de SCRUM para resolver sus problemas y hacer realidad los beneficios del desarrollo ágil de software utilizando Scrum, tal y como lo refieren la Scrum Alliance y Scrum.org.
Algunas de las justifiaciones que sulen escucharse en los equipos de desarrollo que hacen SCRUM-But son:
- “Nosotros utilizamos Scrum, pero…¿Quien tiene un Daily Scrum todos los días? es demasiado!. Tan sólo tenemos uno por semana.”
- “Nosotros utilizamos Scrum, pero… Las retrospectivas son una pérdida de tiempo. Por lo que no hacemos.”
- “Nosotros utilizamos Scrum, pero… No podemos construir una pieza de funcionalidad en un mes. Nuestros Sprints son 6 semanas de duración.”
- “Nosotros utilizamos Scrum, pero… A veces nuestros gerentes nos dan tareas especiales. Por lo que no siempre tenemos tiempo para cumplir con nuestra definición de “Done”.”
1.1 ¿Vale la pena utilizar SCRUM?
Según los indicadores del Chaos Report 2012 de Standish Group, el 86% de los proyectos desarrollados bajo los metodos tradicionales son modificados o fracasan.
En contraste el mismo estudio recalca que con el uso de métodos ágiles, tan solo el 58% de los proyectos desarrollados son modificados o fracasan tal y como se puede observar en la siguiente gráfica.
Figura 1.2: Comparativa entre el procentaje de éxito y fracaso del método en cascada y los métodos ágiles
El métdo de cascada es un malentendido desde el principio. Fue supuestamente “inventado” por el diario “Gestion de desarrollo de sistemas de Software grandes” por el Dr. Winston W. Royce en 1970, pero la implementación que se ha descrito anteriormente es riesgoso e invita al fracaso.
En este punto cabe hacerle cierta justia al método de cascada, el cuál fue formalmente presentado por primera vez en 1970 por el Dr. Winston W. Roice, quien en su artículo “Managing the Development of Large Software Systems” aclara que lo que presenta es un modelo erróneo y no necesariamente funcional, sin embargo, fue tomado por la industria del software como un estándar de facto, lo cuál, ha provocado los altos porcentajes de fallo y fracaso en proyectos de software presentados anteriormente.
1.2 Discrepancia entre el modelo y el problema
¿Es un bebé una versión más pequeña de un adulto?, la respuesta es no, ya que un bebé no es un adulto pequeño, un bebé es un ser independiente. Por lo tanto creer que un bebé es un adulto en forma pequeña o de menor tamaño es algo erróneo. Las empresas como la NASA, IBM del departamento de la defensa crearon sus propios modelos de calidad como CMM para sus empresas, las cuáles, están constituidas por un gran equipo de trabajo, manejan al rededor de 800 mil trabajadores, por lo cuál se cataloga como una empresa grandes, al igual que IBM.
Figura 1.3: Pintura renacentista de un bebé con forma de adulto.
Entonces ¿porqué se pretende adaptar procesos que fueron desarrollados para manejar grandes organizaciones a empresas mucho más pequeñas? segun datos oficiales cenrca del 90% del desarrollo de software en países como México y España se lleva a cabo por pequeñas y medianas empresas (PyMEs) o incluse micro-pymes de dos o tres personas, las cuáles, no cuentan ni con la mitad de los trabajadores pertenecientes a las ya mencionadas, es lo mismo que creer que un bebé es un adulto pequeño. Es por ello que estas empresas necesitan adaptar “macro procesos” a sus necesidades y no las “empresas a los procesos”. Es aquí donde el uso de métodos ágiles puede marcar una diferencia.