No hay duda de que vivimos en una sociedad dominada por el marketing. Hay términos y conceptos que venden. Son como sellos de distinción que muchos intentan poner en su tarjeta de presentación aunque la similitud con la realidad sea, en muchos casos, solo parcial.
Hoy vamos a hablar sobre Scrum, un marco de trabajo que está de moda. Es ágil y moderno (aunque no nuevo). Y está claro que ágil y moderno suena mejor que lento y anticuado. Pero lo cierto es que, aunque Scrum tenga ventajas, también presenta inconvenientes y no se puede utilizar en cualquier tipo de “proyecto”.
De hecho, Scrum no es un marco de trabajo apto para proyectos, sino para productos. No obstante, muchos desarrolladores creen (o al menos aseguran) que están aplicando Scrum. ¿Por qué? Pues porque la palabra Scrum es más sexy que otras alternativas más acordes con la realidad. Pero eso lo veremos más adelante. Vayamos por partes.
De dónde venimos: Desarrollo en cascada
Antes de nada, es interesante recordar de dónde venimos. El desarrollo de software tradicional se realizaba usando la metodología de trabajo en cascada. En pocas palabras se puede resumir de la siguiente manera: El desarrollo se divide en varias fases que se van implementando una detrás de otra en un orden específico:
- Análisis de requerimientos
- Diseño del sistema
- Implementación
- Testeo
- Despliegue.
Esta metodología tiene un gran inconveniente: es de sentido único. El principal problema es que una vez empezada la implementación, no se pueden cambiar los requerimientos. Por desgracia, en el mundo del software, los requerimientos no están totalmente claros desde el principio o éstos pueden querer ser modificados durante el desarrollo, bien porque el cliente cambie de idea o bien porque las necesidades hayan cambiado. Esto sucede especialmente en proyectos largos.
¿Es, por tanto, el desarrollo en cascada una mala metodología? Para nada. Es simplemente una metodología de trabajo que funciona de forma eficaz para proyectos en los que toda la información está definida desde el principio. Hay multitud de industrias donde se aplica el desarrollo en cascada con éxito. Simplemente, presenta limitaciones de flexibilidad, lo cual puede ser un problema para el desarrollo de un proyecto de software.
Introducción a Scrum
Scrum es un marco de trabajo Ágil que se basa en la entrega de incrementos en ciclos de trabajo llamados Sprints. En cada Sprint se realiza la entrega de una parte totalmente funcional del producto. Cada Sprint tiene una fase de Análisis de requerimientos, diseño del sistema, implementación, testeo, despliegue. Una de las ventajas de este marco de trabajo es que los requerimientos se definen (o al menos se discuten) antes de cada sprint. Por lo tanto, el equipo define en cada Sprint qué es lo próximo que se va a implementar. Esto permite reaccionar a posibles cambios en el mercado, o simplemente, en beneficios de los intereses de los usuarios finales del producto.
Proyecto vs. Producto
Habréis notado que en el desarrollo en cascada he hablado de proyecto mientras que en Scrum he hablado de producto. Esto no ha sido casualidad.
La metodología en cascada es un modelo de gestión de proyectos. Un proyecto tiene un presupuesto y una duración determinada. Es decir, cuando se ejecuta un proyecto, se debe conocer cuanto va a costar y cuando va a terminar.
Con el marco de trabajo Scrum se gestiona el desarrollo de un producto y, por tanto, no hay fecha de finalización. Scrum se utiliza para el desarrollo iterativo de productos durante un periodo de tiempo indefinido. Al comenzar el desarrollo no se sabe cuál va a ser el resultado final, pues las funcionalidades a implementar se van definiendo a medida que se va desarrollando y según las decisiones que se vayan tomando para satisfacer las demandas del mercado. Por eso es flexible.
¿Puedo usar Scrum en mi proyecto?
Si hemos leído con atención, la respuesta es sencilla: no. Scrum se puede aplicar para el desarrollo de un producto, no para un proyecto (aunque en los últimos años se están realizando aproximaciones de Scrum aplicadas a proyectos). Y en el desarrollo de software de consultoras, lo que abundan son los proyectos.
Por este motivo, los proyectos desarrollados bajo el marco de trabajo Scrum suelen fallar o bien estos proyectos son en realidad desarrollados usando una metodología de trabajo que recuerda a Scrum pero que no es Scrum realmente, ya que el marco de trabajo no se aplique correctamente (de hecho, en un proyecto no se puede aplicar). En consecuencia, los principios que hacen que Scrum funcione tampoco se pueden cumplir, entre otros motivos.
El Pseudo-Scrum es una aproximación al desarrollo en cascada y Scrum, con las ventajas del uno y del otro. El prefijo Pseudo puede llegar a transmitir la idea de que es una metodología menos válida que Scrum, pero esto no es cierto. A veces también se usa el apelativo híbrido, que suena mejor. Pero lo que importa no es cómo lo llamemos, sino la metodología en sí. Es importante escoger la firma de trabajo que mejor se adapte a las necesidades y no elegirla en base a lo que esté de moda o suene bien. El objetivo final es asegurar el éxito del proyecto o producto y la satisfacción tanto del cliente como del equipo que trabaja internamente.
Resumiendo, llamamos Pseudo-Scrum a un marco de trabajo que parece usar rasgos de Scrum pero que no es Scrum puro. A continuación, vamos a explicar cómo lo hacemos en WATA Factory.
Pseudo-Scrum en WATA Factory
Antes de nada mencionar que en WATA Factory aplicamos la forma de trabajo que mejor se adapta a cada proyecto. Usamos Scrum en el desarrollo de algunos productos, pero este marco de trabajo, por lo general, no se adapta a los requerimientos de nuestros clientes. En la inmensa mayoría de los casos, los clientes necesitan saber qué van a recibir, cuánto va a costar su desarrollo y cuándo va a realizarse la entrega. Esto es, por definición, incompatible con Scrum.
Nuestro Pseudo-Scrum es un híbrido entre el desarrollo en cascada y Scrum, tomando las ventajas de cada uno.
En primer lugar, tenemos una fase de toma y análisis de requerimientos. Posteriormente realizamos un prototipo interactivo, para que el cliente conozca cuál será el producto resultante. Adicionalmente realizamos una oferta que incluye coste de desarrollo y fecha de entrega, a menos que, junto con el cliente podamos trabajar en base a presupuestos de horas para la mejora continua de un producto en cuestión, en cuyo caso aplicaríamos Scrum puro.
Usando el desarrollo en cascada, el equipo técnico ya no volvería a tener contacto con el cliente hasta la fecha de entrega, ya que todo estaría previamente definido. Sin embargo, aquí es donde entra Scrum.
La implementación la realizamos en iteraciones del producto mediante entregas totalmente funcionales. Es decir, el cliente podría utilizar la funcionalidad entregada. Esto tiene dos ventajas. La primera es que el cliente puede hacer uso de su producto antes de la entrega final. La segunda es que el cliente puede ver y probar la funcionalidad. Una vez implementada, el cliente a veces detecta mejoras en la parte del producto desarrollado. Una implementación con Pseudo-Scrum permite al cliente redefinir aquellas funcionalidades que considere oportunas durante el desarrollo.
Por supuesto los cambios deben ser de la misma magnitud que la implementación original para mantener la fecha de entrega y el coste de desarrollo. O bien, se compensa descartando o simplificando otra funcionalidad. Para ello, trabajamos con un Backlog priorizado, en el que el cliente decide el orden de implementación de las funcionalidades.
Usa Pseudo-Scrum con orgullo
Son frecuentes las críticas hacia las formas de trabajo que recuerdan a Scrum o dicen serlo, pero que en realidad no siguen el marco de trabajo fielmente. En parte, es entendible. Si no se está usando Scrum no hay que predicar que se está usando. Lo que no es correcto es decir que la implementación pura es la correcta y cualquier otra opción es tan solo un intento de imitación. Nada más lejos de la realidad.
Usa la metodología que mejor se adapte a cada situación, y defiéndela con la cabeza alta.
