El proceso de desarrollo SCRUM y las Cuatro Leyes

¿Por qué el proceso de desarrollo SCRUM es más eficiente que las metodologías tradicionales Waterfall?

En este primer artículo de la serie que dedicamos a Scrum, vamos a explicaros la relación entre el proceso de desarrollo Scrum y los principios básicos de gestión de proyectos.

Nuestro objetivo es que entendáis por qué motivos Scrum es más eficiente que las metodologías tradicionales waterfall.

El proceso de desarrollo SCRUM es una implementación de las Cuatro Leyes

Los beneficios de Scrum se derivan de que cumple las Cuatro Leyes Básicas de la gestión de proyectos tecnológicos. Por eso es más eficiente que las metodologías clásicas de desarrollo en cascada o Waterfall, que no cumplen ninguna de ellas.

Recuerda que hay otras implementaciones de las Cuatro Leyes como XP (extreme programming), que aportan mejoras de productividad similares.

SCRUM cumple la 1ª ley.

Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley nos advierte tres cosas:

– Que el tiempo empleado en especificar es, en general, tiempo perdido

– Que la única interpretación válida de la especificación es la del cliente.

– Que no es posible finalizar los trabajos.

¿Como responde Scrum a estos tres desafíos?

– En Scrum el diseño es muy liviano; los principales requisitos se capturan en Epics y Features, cuya extensión es de un párrafo. Epics y Features se descomponen en Historias de Usuario cuya extensión es de una sola línea. El tiempo que se ahorra en la especificación se dedica a desarrollar código, asumiendo que tendremos que modificarlo cuando se lo presentemos al cliente.

– Se incorpora al squad un representante del cliente, el Product Owner, cuya misión es ayudar a los programadores a interpretar las historias de usuario.

– El cliente asume que no se concluirán los desarrollos, pero el Product Owner se asegura de que el software construido resuelva sus principales necesidades.

SCRUM cumple la 2ª ley.

One Project, One Team, One Site.

La segunda ley nos instruye sobre la importancia de construir vínculos emocionales y relaciones de confianza.

Y la mejor forma de construir vínculos y relaciones es mediante el contacto diario y la dedicación exclusiva.

¿Cómo construye Scrum vínculos y relaciones?

En Scrum los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí.

El grupo es autosuficiente para hacer sus tareas e incluye a programadores, testers y en caso necesario arquitectos de sistemas o administradores de BBDD.

El Product Owner es un miembro más del equipo, y está junto a ellos toda la jornada para ayudarles a interpretar las historias de usuario.

SCRUM cumple la 3ª ley.

Presión x Talento = Constante.

La tercera ley nos recuerda que la velocidad de avance de los desarrollos sólo depende del número de ideas que aporten los consultores del equipo, y no del número de integrantes ni del número de horas de su jornada.

Para que florezca el talento es necesario rebajar la presión. Se ha demostrado que incrementos de la jornada de trabajo producen retrasos en los desarrollos y, por el contrario, reducir la jornada a cinco horas diarias mejora la productividad un 30%.

¿Cómo elimina Scrum la presión?

En Scrum no es obligatorio completar todas las Historias planificadas para el sprint.

Aunque buena parte de los desarrollos pasan sus test, algunos pueden quedar a medias o no superar las pruebas. Estas Historias vuelven al team backlog y se abordan (o no) en siguientes sprints.

SCRUM cumple la 4º ley.

El triángulo de Acero.

La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero necesariamente se degrada.

Como cliente debes elegir entre

– Sacrificar el Alcance y entender que ciertas funcionalidades no se construirán.

– Sacrificar el Plazo (y multiplicar el coste) y asumir que el sistema siempre estará en desarrollo.

– Sacrificar la Calidad, y aceptar que obtendrás un sistema con errores en producción y complejo de operar.

Habitualmente en los contratos se fijan Alcance, Plazo y Calidad. ¿El resultado? En el 80% de los proyectos se sacrifican las tres variables simultáneamente. ¿Es posible elegir peor metodología?

¿Qué variable se degrada en el proceso de desarrollo SCRUM?

La metodología SCRUM se asegura que la única variable sacrificada sea el Alcance.

– El Plazo, y por consiguiente el presupuesto, se establecen en el contrato. El Alcance se deja abierto.

– Para garantizar la Calidad, no se permite entregar desarrollos que no hayan superado sus correspondientes pruebas unitarias.

– Para maximizar el retorno de la inversión, el cliente desplaza un Product Owner a los squads para priorizar aquellos desarrollos que aporten más valor a la empresa.

¿Puedo mejorar la eficiencia sin usar Scrum?

Como hemos visto, las ventajas de Scrum se derivan de que cumple los principios básicos de la gestión de proyectos.

Es frecuente que las organizaciones se obsesionen con la puntual observancia de sus rituales, lo que les lleva a cometer una y otra vez los mismos errores en su implementación, sin encontrar las prometidas mejoras de productividad.

Pero también es posible el caso opuesto. Puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin  implementar el proceso de desarrollo de Scrum.

Recuerdo mis primeras experiencias de trabajo a comienzos de los años 90, antes de la fundación de novanotio, donde usábamos una metodología que cariñosamente llamábamos ASDM (A Salto De Mata).

Nunca invertimos mucho tiempo en especificar, los compañeros éramos uña y carne, teníamos una fantástica relación con el cliente y nunca nos pidieron trabajar un fin de semana. ASDM se podía resumir en la frase ‘Trata bien a tus consultores y estos harán un gran trabajo’.

La productividad fue excelente hasta que la organización apostó por CMMI, una metodología más preocupadas por la especificación que por las personas.

Emplea con sabiduría los principios de la gestión de proyectos y cualquier metodología será la adecuada.