Ejecutar programas ágiles (sin perder la razón)

Algunos pensarán que la transición a lo ágil implica perder de vista el panorama general. No podríamos estar menos de acuerdo.

Dan Radigan Dan Radigan

Los primeros en adoptar el desarrollo ágil fueron pequeños equipos independientes que trabajaban en pequeños proyectos independientes. Demostraron que el modelo ágil funciona, para regocijo de los creadores de software en todo el mundo y mejora de sus condiciones. Recientemente, las organizaciones más grandes están ampliando la metodología ágil más allá de equipos y proyectos, buscando maneras de aplicarla a programas enteros. 

This is not without its challenges. But that doesn't mean it can't be done! 

Cascada o ágil

Empecemos por lo básico: qué distingue a lo ágil. 

Los estilos tradicionales de gestión de proyectos, como la cascada, se elaboran en fases. A continuación, una ilustración de un proyecto en cascada típico. Este estilo de desarrollo de producto lo pliega todo en una sola publicación "big bang" de alto riesgo. Cuando un proyecto pasa una fase, cuesta volver a visitarla, porque los equipos siempre hacen presión para avanzar a la etapa siguiente.

Ejemplo de publicación en cascada | Orientador ágil de Atlassian

Los estilos tradicionales de gestión de proyectos suelen crear "rutas críticas" en las que el proyecto no puede avanzar hasta que se resuelva una incidencia que lo bloquea. Por si fuera poco, el cliente final no puede interactuar con el producto hasta que no esté del todo completo. Así, las incidencias importantes en el diseño del producto y en el código no se descubren hasta la publicación.

Ahora comparemos esto con un estilo de gestión de proyectos ágil, que adopta un planteamiento iterativo del desarrollo con intervalos periódicos de feedback. Estas iteraciones permiten que el equipo se derive (y que sea productivo) a otra área del proyecto mientras se resuelve el problema que lo está bloqueando.

Ejemplo de gestión de proyectos ágil | Orientador ágil de Atlassian

Aparte de eliminar rutas críticas, las iteraciones permiten interactuar con el producto durante el desarrollo.

Todo esto, a su vez, brinda oportunidades constantes al equipo de compilar, entregar, aprender y ajustar. Los cambios del mercado no te pillan desprevenido y los equipos están preparados para adaptarse rápidamente a requisitos nuevos.

Una ventaja aún mayor es que los conjuntos de aptitudes se comparten en el equipo de software. Los conjuntos de aptitudes coincidentes del equipo añaden flexibilidad al trabajo en todas las partes de la base de código del equipo. De este modo, no se malgasta tiempo ni esfuerzo si cambia el sentido del proyecto. (Para saber más acerca de esto, lee nuestro artículo sobre la creación de grandes equipos ágiles).

Cómo crear un gran programa ágil

Cuando un programa pasa de una gestión de proyectos tradicional a ágil, el equipo y las partes interesadas deben abordar dos conceptos importantes:

  • La atención del propietario del producto se centra en optimizar el valor de los resultados del equipo de desarrollo. El equipo de desarrollo depende del propietario del producto para priorizar el trabajo más importante.
  • El equipo de desarrollo solo puede aceptar trabajo si tiene la capacidad de hacerlo. El propietario del producto no presiona para que el equipo trabaje o se comprometa con plazos arbitrarios. El equipo de desarrollo saca trabajo del backlog del programa si puede aceptar más trabajo.

Descubramos los mecanismos que usan los programas ágiles para organizar, ejecutar y estructurar el trabajo de forma iterativa.

Hojas de ruta

La hoja de ruta describe cómo se desarrolla en el tiempo un producto o solución. Las hojas de ruta están formadas por iniciativas, que son grandes áreas de funcionalidad, e incluyen plazos que indican cuándo estará disponible una funcionalidad. Según se desarrolla el programa, está aceptado que la hoja de ruta cambiará; a veces, ligeramente, y otras, ampliamente. El objetivo es que la hoja de ruta siga centrada en las condiciones del mercado actual y en objetivos a largo plazo. 

Requisitos

Las iniciativas de la hoja de ruta se dividen en una serie de requisitos. Los requisitos ágiles son descripciones breves de la funcionalidad necesaria, en lugar de los documentos de 100 páginas que se asocian con los proyectos tradicionales. Evolucionan con el tiempo y aprovechan el entendimiento común que el equipo tiene del cliente y del producto deseado. Los requisitos ágiles siguen siendo austeros mientras todo el equipo desarrolla un entendimiento común mediante la conversación y la colaboración constantes. Únicamente cuando la implementación está a punto de empezar, se concretan los pormenores con todo detalle. 

Backlog

El backlog define las prioridades del programa ágil. El equipo incluye todos los elementos de trabajo en el backlog: funcionalidades nuevas, bugs, mejoras, tareas técnicas o arquitectónicas, etc. El propietario del producto prioriza el trabajo del backlog para el equipo de ingenieros. Más adelante, el equipo de desarrollo utiliza el backlog priorizado como única fuente fiable para saber qué trabajo hay que hacer. 

Sistemas de entrega ágiles

Agile se puede implementar con distintos marcos (como scrum y kanban) para entregar software. Los equipos de scrum utilizan sprints para guiar el desarrollo, y los de kanban suelen trabajar sin intervalos fijos de trabajo. Ambos marcos, no obstante, emplean grandes sistemas vectores, como épicas y versiones para estructurar el desarrollo de una cadencia de publicación sincronizada en la producción.

Métricas ágiles

Los equipos ágiles progresan gracias a las métricas. Los límites del trabajo en curso hacen que el equipo, y la empresa, sigan concentrados en entregar el trabajo de la más alta prioridad. Gráficos como el de evolución y control ayudan a que el equipo prevea su cadencia de entrega, y los diagramas de flujo continuo ayudan a identificar obstáculos. Estas métricas y objetos hacen que todos se centren en los grandes objetivos e infunden confianza en la habilidad del equipo para entregar futuros trabajos. 

Agile se basa en la confianza

Un programa ágil no puede funcionar si no hay un alto nivel de confianza entre los miembros del equipo. Hace falta sinceridad para mantener conversaciones difíciles sobre lo que es conveniente para el programa y el producto. Puesto que las conversaciones tienen lugar a intervalos periódicos, las ideas y preocupaciones se expresan con regularidad. Esto significa que los miembros del equipo también tienen que confiar en las habilidades (y la disposición) de los demás para llevar a efecto las decisiones que se tomen durante esas conversaciones.

En definitiva, el desarrollo ágil es un método estructurado e iterativo de hacer software. Te da la capacidad de responder a los cambios sin descarrilar. Y esa es una buena noticia para cualquier programa. 

Up Next
Workflow