Desarrollo ágil y comunicación. SCRUM

Desarrollo ágil y comunicación.

En la gestión de versiones tradicional, uno de los grandes problemas era la comunicación: cadenas de personas que transmiten mensajes e información, como hemos visto, nunca termina bien.

Agile fomenta cadenas de comunicación más cortas: se supone que las partes interesadas deben estar involucradas en la gestión del desarrollo de software, desde la definición de requisitos para la verificación (prueba) del mismo software. 

Esto tiene un enorme ventaja: los equipos nunca crean características que no son necesarias. Si los plazos deben ser cumplidos, el equipo de ingeniería reduce el tamaño del producto final sacrificando la funcionalidad pero no calidad.

Entregar temprano y entregar a menudo es el mantra de ágil, que básicamente significa definir un producto mínimo viable (MVP) y entregarlo tan pronto como esté listo para para entregar valor a los clientes de su aplicación y luego entregar nuevas características según sea necesario. Con este método, estamos entregando valor desde el primer lanzamiento y recibimos comentarios muy pronto en la vida del producto.

Para articular esta forma de trabajo, se introdujo un nuevo concepto: el sprint.

Un sprint es un período de tiempo (generalmente 2 semanas) con un conjunto de funcionalidades que se supone que debe entregarse al final de la producción para que podamos lograr diferentes efectos:

• Los clientes pueden obtener valor muy a menudo
• La retroalimentación llega al equipo de desarrollo cada 2 semanas para que la corrección, las acciones puedan llevarse a cabo.
• El equipo se vuelve predecible y conocedor de las estimaciones.

Este último punto es muy importante: si nuestras estimaciones se reducen en un 10% en una publicación trimestral, significa que estamos fuera por dos semanas, mientras que en un sprint de dos semanas, estamos fuera solo por 1 día, que, con el tiempo, con el conocimiento ganado sprint tras sprint,significa  el equipo podrá ajustarse debido a que el equipo construye una base de datos de características y tiempo dedicado a ellas para que podamos comparar nuevas características contra los ya desarrollados.

Estas características no se llaman características. Se llaman historias. Una historia es, por definición, una funcionalidad bien definida con toda la   información para el equipo de desarrollo capturado antes de que comience el sprint, así que una vez que comenzamos el desarrollo del sprint, los desarrolladores pueden centrarse en actividades técnicas en lugar de centrarse en resolver incógnitas en estas características.

No todas las historias tienen el mismo tamaño, por lo que necesitamos una unidad de medida: los puntos de la historia, Por lo general, estos no se relacionan con un marco de tiempo sino con su complejidad.

Esto le permite al equipo calcular cuántos puntos de historia se pueden entregar al final del sprint, así que con el tiempo, mejoran en las estimaciones y todos obtienen su expectativas satisfechas.

Al final de cada sprint, se supone que el equipo lanzará las características desarrolladas, probado e integrado en la producción para pasar al siguiente sprint.

El contenido de los sprints se selecciona de una cartera de pedidos que el equipo también manteniendo y preparando a medida que avanzan.

El objetivo principal es cumplir con las expectativas de todos manteniendo la comunicación abierta y poder predecir qué se está entregando y cuándo y qué se necesita para eso.

Hay varias formas de implementar las metodologías ágiles en nuestro software

producto. El que se acaba de explicar anteriormente se llama Scrum, pero si observa otras Metodologías de desarrollo, verá que todas se centran en el mismo concepto: mejorar la comunicación entre diferentes actores del mismo equipo.