¿Por qué Agile?

Hasta mediada la década de los 90, la gestión de proyectos estaba dominada por el ciclo en cascada. En ella, cada proyecto debe pasar por una serie de etapas ejecutadas una detrás de otra: análisis, diseño, construcción, pruebas e implantación. Sin embargo, esta forma de gestión, en el mundo del software, comenzó a colapsar detrás de planes que nunca se cumplían, presupuestos desorbitados, altísimos cambios de alcance…

Durante varias décadas, la gestión de proyectos de software ha estado dominada por el ciclo en cascada. Cuando comenzaba un proyecto, se fijaba el presupuesto, el tiempo para terminar el proyecto y el alcance. Esto es lo que conocemos como el triángulo de hierro.

Triángulo de hierro

A partir de ahí, los analistas y jefes de proyecto dedicaban mucho tiempo a analizar el problema y diseñar un plan que permitiera entregar en plazo la solución. Sin embargo, cuando comenzaban a construirla se encontraban con casuísticas o problemas que no habían tenido en cuenta al analizar o diseñar. Esta situación provocaba retrasos en la construcción, dejando menos tiempo para las pruebas y la implantación, lo que provocaba errores que frustraban a los usuarios.

De forma paralela, durante años varios programadores con amplia experiencia en el desarrollo de software comenzaron a probar diferentes prácticas para poner solución a estos problemas. Uno de ellos, Kent Beck, en 1999 reunió todas las prácticas exitosas que había desarrollado en su libro Extreme Programming Explained: Embrace Change, dando lugar a la metodología de Extreme Programming (XP). Estas prácticas forman un método adaptativo en el que se minimiza el impacto de añadir nuevas funcionalidades al producto y eran útiles para los proyectos que requerían cambios frecuentes y que incluían equipos no muy grandes.

Ciclo en cascada vs Agile

Lejos de querer colocar un enfoque por encima del otro, vamos a descubrir cuáles son algunas características del enfoque Agile que le hacen muy útil para alguna tipología de proyectos.

Entregas completas frecuentes

Con el ciclo en cascada se produce una única entrega al completar todas las fases; mientras que en Agile se realizan frecuentes entregas más pequeñas que han completado todas las fases.

Ciclo en cascada
Entregas Agile

Reducción del impacto de retrasos

En el ciclo en cascada los retrasos suponen un producto incompleto, con frecuentes errores. En Agile, los retrasos afectan a la cantidad de entregas, pero si lo tenemos priorizado, tendremos las que más aportan al usuario.

Ciclo cascada con retrasos
Ciclo Agile con retrasos

Asegura la calidad del producto

Cada entrega en Agile ya ha pasado por todas las fases del ciclo, incluso cuando hay retrasos respecto al plan inicial. Sin embargo, ante retrasos en las fases iniciales del ciclo en cascada es probable que entreguemos funcionalidad que no ha sido probada correctamente.

Ciclo en cascada sin pruebas
Ciclo Agile

Incorporación del feedback en etapas tempranas

La entrega continua de funcionalidades más pequeñas nos permite obtener feedback de los usuarios que incorporamos al resto de producto que nos queda por construir.

Ciclo en cascada
Retroalimentación Agile

Un poco de historia de Agile

Aunque la llegada de Agile se produce a principios del siglo XX en el mundo del desarrollo de software, tenemos que remontarnos a la década de los 60 para descubrir algunos de sus fundamentos. Concretamente en Japón, donde después de la Segunda Guerra Mundial necesitan renovar su industria para volverla competitiva. Será en la fábrica de automóviles Toyota donde crearon el Toyota Production System (TPS). Este método de fabricación está basado en tres pilares:

Just in Time

Produce sólo aquello que va a ser consumido.

Jidoka

Establece que cada proceso tenga su propio autocontrol de calidad.

Kaizen

La mejora continua es un proceso continuo. Todos los procesos son susceptibles de mejora.

Este sistema hizo que la producción, la innovación y calidad de los productos de las fábricas japonesas aumentase durante las siguientes décadas. Por ello, el sistema se comenzó a implantar en empresas y factorías de diferentes sectores.

En 1990, James Womak, Daniel T. Jones y Daniel Roos recogieron en su libro “La máquina que cambió el mundo” los principios de un nuevo sistema de producción, basado en la aplicación del Toyota Production System en diferentes industrias. Lo denominaron Lean Manufacturing.
Y estos principios también saltaron a la industria del software, donde buscaban romper con el ciclo tradicional en cascada que no encajaba en el proceso de desarrollo de productos software. En 2003, Mary y Tom Poppendieck publican su libro “Desarrollo de software Lean” donde presentan los 7 principios Lean aplicados al desarrollo de software y algunos instrumentos y herramientas para su aplicación.

El Agile Manifesto

El 12 de febrero de 2001, 17 desarrolladores de software que habían empezado a crear diferentes prácticas para la creación de software bajo los principios Lean, se reunieron en la estación de esquí de Snowbird (EEUU) para la creación de un manifiesto sobre nuevas formas de crear software. El Agile Manifesto es el resultado de esta reunión.

Agile Manifesto ELL

También te puede interesar.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies