Me suelen hacer esta pregunta: ¿Qué es la metodología ágil? Ágil es una palabra que se usa en la industria de la tecnología de la información para describir un método alternativo de gestión de proyectos. Ágil es una palabra que la industria de la tecnología de la información usa para describir un método alternativo de gestión de proyectos.
El método Ágil es un proceso que permite al equipo dar respuestas rápidas e impredecibles a las valoraciones que reciben sobre su proyecto. Crea oportunidades de evaluar la dirección de un proyecto durante el ciclo de desarrollo. Los equipos evalúan el proyecto en reuniones regulares, llamadas sprints o iteraciones.
El método ágil es un proceso de empoderamiento que ayuda a las empresas a diseñar y crear el producto idóneo.
El proceso de gestión es muy beneficioso para las compañías de software porque les permite analizar y mejorar su producto durante el desarrollo del mismo. Esto da a las empresas la capacidad de fabricar un producto valioso, de manera que se mantengan competitivas en el mercado.
En 2001, un pequeño grupo de personas, cansadas de los modos tradicionales de gestionar proyectos de desarrollo software, crearon el manifiesto ágil. Es un método mejorado de gestionar los proyectos de desarrollo software.
El manifiesto ágil tiene cuatro valoraciones importantes:
El desarrollo ágil de software posee 12 principios:
Hay diferentes métodos ágiles que fomentan los valores y principios del manifiesto. Scrum y XP son dos muy conocidos.
Los mejores desarrolladores de software llevaron a cabo reuniones ágiles. Después de experimentar las limitaciones del modelo de desarrollo en cascada, buscaban un proceso más eficiente para analizar el proceso de desarrollo. El enfoque que utilizaron supera los problemas relacionados con las filosofías y los procesos de los métodos clásicos.
Podemos encontrar muchos beneficios en el desarrollo ágil de software. Entre otros:
La metodología ágil crea muchas oportunidades en cada reunión para conseguir un compromiso sincero entre el equipo y los inversores. Ya que el cliente participa activamente en el proyecto, existe una continua colaboración entre todas las partes. Esto brinda al equipo la oportunidad de entender completamente la visión del cliente.
Al entregar software funcional y de gran calidad con frecuencia, los inversores crean una relación de confianza con el equipo. Esto ayuda también a que se vuelvan a producir acuerdos entre el equipo y el cliente en el futuro.
El método ágil involucra al cliente en el proyecto completo, incluyendo en el planteamiento de la iteración, las sesiones de revisión, y el anuncio de nuevas características en el software. Los clientes, sin embargo, deben entender que, aunque el proyecto sea transparente, están viendo un WIP (trabajo en curso) y no el producto final.
Los sprints se llevan a cabo en un horario fijo durante 1 a 4 semanas. Gracias a este método, la entrega del producto es muy predecible, ya que las nuevas características pueden ser entregadas a los inversores de manera rápida y frecuente. También permite al equipo a probar o lanzar el software antes si tiene suficiente valor empresarial.
Ya que los sprints se realizan en un horario fijo, los costes son limitados y predecibles, y se basan en la cantidad de trabajo finalizada. Combinando los costes estimados antes de cada sprint, el cliente entenderá mejor los costes aproximados de cada característica. Esto ofrece mejores oportunidades para tomar decisiones a la hora de priorizar características o añadir iteraciones.
Las metodologías Scrum permiten una mayor flexibilidad, al priorizar las funciones dirigidas al cliente. El equipo tiene un mayor control sobre las unidades de trabajo que se pueden entregar al final de cada sprint; consiguiendo un progreso continuo hacia el objetivo del producto final. Para obtener con rapidez un RIO del equipo de ingeniería, el trabajo debe ser enviado pronto a los consumidores, de manera que sepan el valor de las funciones del producto.
Aunque el objetivo debería ser entregar el subconjunto acordado de funciones del producto, los procesos Ágiles brindan la oportunidad de cambiar las prioridades y refinar el Backlog del producto. Estos cambios pueden añadirse a la siguiente iteración, de manera que pueden ser introducidos en unas pocas semanas.
El equipo entiende mejor qué es más importante para el negocio del cliente y puede entregar las características que le den el mayor valor posible a dicho negocio.
Las historias de usuario se usan normalmente para definir las funciones del producto, ya que estas se refieren a criterios de aceptación centrados en el negocio. Al centrarse en las necesidades del usuario, cada característica ofrece un valor real y no solamente un componente TI. Otorga una mejor oportunidad para ganar buenas valoraciones a través de pruebas beta del software al finalizar cada Sprint. Esto genera un feedback crucial, ya que a partir del mismo se pueden realizar los cambios necesarios.
Los proyectos se dividen en unidades manejables, permitiendo al equipo centrarse en el desarrollo de alta calidad, en el testeo y en la colaboración. Al crear compilaciones y realizar pruebas o revisiones a lo largo de la iteración, se pueden encontrar errores y defectos y solucionarlos pronto, mejorando la calidad general del producto.
La mayoría de los procesos ágiles se centran en crear un sentimiento compartido de propiedad y objetivos para todos los miembros del equipo. Esto le pone metas a tu equipo, en lugar de crear una falsa sensación de urgencia. Los equipos que tienen metas son más productivos y se desafían a ellos mismos para ser más rápidos y eficientes.
La gestión Ágil reduce los riesgos comunes asociados a la entrega, el alcance, y el presupuesto del proyecto.
Favorece la colaboración entre el cliente y el equipo; ofreciendo beneficios mutuos en la mitigación de los grandes riesgos que surgen durante el desarrollo del software.
En 2009, el Dr. David F Rico comparó el método Ágil con los métodos tradicionales de gestión de proyectos software. Durante la investigación y la síntesis, analizó 23 procesos Ágiles, comparándolos con 7.500 proyectos tradicionales.
Encontró 20 beneficios en los proyectos Ágiles:
Hay bastantes metodologías ágiles; todas comparten filosofías, características y prácticas similares. Sin embargo, tras ser implementada, cada metodología tiene sus propias prácticas, terminología y tácticas. Algunas de las principales metodologías de desarrollo ágil de software son:
Scrum es un framework de gestión con grandes posibilidades de control y gestión de las iteraciones y los incrementos en todo tipo de proyectos. Las tácticas Scrum son ligeras y se pueden combinar con otras metodologías ágiles. Su popularidad ha crecido dentro de la comunidad de desarrollo ágil, ya que son sencillas y tienen una probada productividad.
El desarrollo de software lean es una metodología iterativa originalmente desarrollada por Mary y Tom Poppendieck. Muchos de los principios y prácticas de esta metodología vienen de la tendencia de iniciativas lean y fueron usadas por primera vez en grandes compañías, como Toyota. Este método basado en el valor se centra en entregar al cliente un eficiente mecanismo de “Flujo de Valor” que define el valor del proyecto.
Los principios esenciales de esta metodología son:
Al escoger solo las características que tienen valor real para el sistema, priorizándolas y entregándolas en pequeñas tandas, se hace desaparecer el despilfarro. En cambio, la metodología lean pone el énfasis en la velocidad y la eficiencia; dependiendo del feedback entre los clientes y los programadores. Se centra en la idea de que las peticiones de los clientes “tiran” del producto.
El foco se pone más sobre la habilidad de las personas o de pequeños equipos de tomar decisiones más rápida y eficientemente, en lugar de un método jerárquico. Esta metodología se concentra en la eficiencia de su equipo, asegurando que todo el mundo es siempre tan productivo como puede.
Las organizaciones utilizan el método Kanban para gestionar la creación del proyecto a la vez que se pone el énfasis en la entrega continua y en no sobrecargar al equipo de desarrollo. Como el método Scrum, los procesos Kanban están diseñados para ayudar a los equipos a trabajar juntos de manera más eficiente.
Tiene tres principios:
El método Kanban promueve la colaboración continua entre el cliente y el equipo. Incentiva el continuo aprendizaje y las mejoras para dar al equipo el mejor flujo de trabajo posible
El método Programación Extrema (XP) fue originalmente descrito por Kent Beck. Es una de las metodologías ágiles más populares y controvertidas. XP es un método de mucha disciplina que consiste en entregar continuamente software de alta calidad con rapidez. El cliente se involucra activamente con el equipo para realizar la planificación, el testeo y dar feedback, consiguiendo entregar software funcional con frecuencia. El software debería ser entregado por intervalos, cada tres semanas.
El método XP original está basado en cuatro simples valores:
Tiene 12 prácticas de apoyo:
La metodología Crystal es una de las menos pesadas y más adaptables en el mundo del desarrollo software. Está compuesta de varios procesos ágiles, que incluyen el Clear, Crystal Yellow, Crystal Orange, y otros métodos. Hay muchos factores que impulsan estos procesos, incluyendo: el tamaño del equipo y del sistema, y las prioridades del proyecto.
La familia de Crystal se centra en el hecho de que cada proyecto tiene características únicas, por tanto, las políticas y prácticas tienen que adaptarse a estas características.
El método Crystal tiene varios principios fundamentales, incluyendo:
Este proceso ágil, como otras metodologías, promueve la entrega temprana y frecuente de software funcional. Incentiva la adaptación e involucración del usuario, eliminando las distracciones y la burocracia.
El Método de Desarrollo de Sistemas Dinámicos (DSDM) se creó en 1994 para proveer un framework estándar para la entrega de proyectos, y por entonces se llamó Desarrollo Rápido de Aplicaciones (DRA). Aunque era muy popular en los 90, el modelo DRA se desarrolló de manera no estructurada.
Desde sus inicios, el DSDM ha evolucionado y madurado; ahora proporciona una base para la planificación, la gestión, la ejecución y el escalado del proceso ágil y los proyectos iterativos.
El método DSDM tiene seis principios fundamentales:
El DSDM utiliza un enfoque “de propósito comercial” para la entrega y los criterios de aceptación. Se centra en la fórmula: lanzamiento del 80% del sistema en el 20% del tiempo.
Jeff De Luca, junto a los colaboradores A.m. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern y Stehen Palmer desarrollaron el método de Desarrollo Basado en Funcionalidades (FDD). Es un proceso iterativo que comienza estableciendo la forma del modelo ágil. Las iteraciones del “diseño basado en las funcionalidades, build basada en las funcionalidades” duran dos semanas. Las funcionalidades gustan a los clientes porque son pequeñas y útiles.
El diseño y desarrollo FDD se basa en estas ocho prácticas:
En el proceso de desarrollo ágil, la metodología Scrum define perfectamente qué es el método ágil en la gestión de proyectos.
Hay tres roles en un proyecto Scrum: el Dueño del Producto, el Scrum Master y los miembros del equipo.
El Product Owner supervisa todas las condiciones comerciales del proyecto para asegurarse de que se está desarrollando el producto correcto y en el orden establecido. Un buen dueño de producto equilibra las prioridades competitivas, está disponible para el equipo, y toma decisiones sobre el proyecto.
El Scrum Master es el coach del equipo; ayudan al equipo a trabajar juntos con efectividad. Los Scrum Masters rompen las barreras que impiden el progreso, facilitando reuniones y grupos de discusión, monitorizando los progresos, solucionando problemas, y realizando otras tareas de gestión del proyecto.
El equipo trabaja conjuntamente para determinar la mejor manera de conseguir los objetivos establecidos por el dueño del producto. El equipo decide qué miembros realizarán tareas específicas, y subraya las prácticas técnicas requeridas para alcanzar los objetivos.
En la gestión ágil de un proyecto, el Scrum Master es la versión del siglo XXI del director del proyecto. Sin embargo, a diferencia de los directores de proyecto tradicionales, el Scrum Master no se apunta el tanto ni acusa a nadie del éxito o fracaso de un proyecto.
Su autoridad solo se extiende al proceso. La experiencia del Scrum Master motiva y guía al equipo a trabajar a su máximo nivel. Otros roles tradicionales de dirección, como el alcance del producto, el coste, el personal, y la gestión del riesgo son todavía responsabilidad del director del proyecto.
Sorpresa: ¡Las Organizaciones Ágiles están Jerarquizadas!
Una de las ideas equivocadas sobre las organizaciones Ágiles es que no son jerárquicas. Nada podría ser menos verídico. Los más altos directos todavía definen la dirección y el tono del resto de la organización y las personas todavía son despedidas si no hacen su trabajo. La búsqueda del mayor rendimiento es aún más implacable que en las organizaciones tradicionales y burocráticas.
En una burocracia, el personal que no rinda a su máximo potencial puede esconderse en los recovecos del sistema. Pero en una organización ágil, hay una trasparencia radical que hace a todos los compañeros responsables de sus acciones.
La jerarquía en una organización ágil es muy diferente de la existente en una burocrática. La jerarquía ágil está basada en la competencia, no en la autoridad. El rendimiento no está basado en complacer al jefe, sino en añadir valor al consumidor. La organización utiliza una comunicación horizontal y vertical, que es muy interactiva. Las ideas pueden venir de cualquier persona, incluyendo al cliente.
Es una red que crece continuamente, aprendiendo y adaptándose al constante flujo; añade nuevo valor a los consumidores al explotar las oportunidades que se presentan. Si se hace de manera correcta, la continua entrega de valor a los clientes con menos trabajo resultará en un aumento de los beneficios de la organización.
El método ágil distingue claramente las diferencias entre la explotación y la exploración. En una organización ágil, todos los miembros están explorando continuamente formas de añadir más valor al consumidor.
Durante los primeros años del Método Ágil de Gestión, los críticos pensaban que equipos pequeños nunca podrían manejar grandes y complejos problemas. Pero estaban equivocados. Todos los equipos son parte de una red que está basada en las conversaciones entre todos los grupos que buscan objetivos comunes. Los ritmos constantes y comunes de estos grupos dan lugar a una sólida plataforma que permite a los equipos pequeños enfrentarse a problemas complejos. Esto es, de largo, un sistema mucho mejor que el burocrático.
El proceso ágil divide un proyecto de software en pequeñas partes, que pueden ser desarrolladas en incrementos o iteraciones. Varios estudios han probado que hay una correlación negativa entre el tamaño del proyecto y el éxito del mismo (en otras palabras: cuanto más pequeño el proyecto, más alta la probabilidad de tener éxito)
El método ágil reduce el tamaño del proyecto, creando muchos proyectos pequeños. Este método iterativo distingue al método Ágil de los demás.
A diferencia de otros métodos, el método Ágil utiliza iteraciones durante la planificación y las fases de desarrollo. Cada iteración dura, por norma general, una semana. Durante estas sesiones, el equipo del proyecto y el equipo de clientes colaboran para priorizar las necesidades que se añadirán a la iteración. El resultado final es un programa de software que se entrega rápidamente al cliente.
Los clientes pueden probar su programa y hacer cambios si son necesarios. Se realizan muchos lanzamientos durante el proceso, a la par que se hacen algunos cambios al programa. El proceso iterativo se repite hasta que el proyecto está finalizado.
La programación de software es un componente esencial de casi cualquier empresa hoy en día. Esto significa que el método Ágil es fundamental para cualquier tipo de organización y forma de trabajo.
Las metodologías Ágiles que incorporan nuevos valores, prácticas, principios y beneficios son una mejor alternativa ante el estilo tradicional de mando y control en la gestión de proyectos. El método Ágil se está extendiendo incluso a otras industrias y funciones, incluyendo los C-Suites.
Sin embargo, aunque muchas empresas están optando por algunos procesos Ágiles, todavía trabajan bajo un método burocrático en su base. En la economía de hoy día, donde domina lo digital, es vital para las compañías desarrollar prácticas de gestión ágil. Pero muchas compañías todavía tienen problemas con esta transición y siguen operando bajo la cultura del mando. Esto se refleja en la mentalidad y las habilidades de la dirección y es el mayor obstáculo al que se enfrentan las empresas hoy en día.
Hay muchas prácticas ágiles diferentes; muchas no son utilizadas por profesionales ágiles. Aquellos que quieran realizar la transición al modelo ágil, deberán comprender las diferentes prácticas para saber cómo aplicarlas en su entorno. Los siguientes ejemplos ilustran cómo se pueden aplicar las prácticas Ágiles.
A las reuniones diarias también se las conoce como reuniones diarias de Scrum. Estas sesiones de Scrum se llevan a cabo cada día y en ellas participa todo el equipo, de manera que puedan compartir información importante entre ellos. Estas reuniones tienen como objetivo mantener a todos los miembros del equipo informados y actualizados sobre el estado del proyecto. La clave de estas reuniones es la brevedad.
Durante las reuniones diarias de scrum, cada miembro del equipo debería responder a tres cuestiones:
Una historia de usuario es una breve descripción de la función que requiere el usuario. Contiene tres elementos, que son:
Las historias están escritas desde la perspectiva del usuario final y usa un lenguaje que el usuario pueda entender. Las historias actúan como una moneda entre los desarrolladores y los clientes; ambas partes se entienden perfectamente. Puedes leer más acerca de las 4 razones por las que no se “finalizan” Historias de Usuario.
Implementar un riguroso y formal sistema de pruebas automatizadas es vital en el proceso ágil. Las pruebas encuentran y eliminan defectos del código para asegurar que se entrega al cliente un software funcional. Los desarrolladores pueden crear el código de las pruebas bajo una red de seguridad usando una variedad de los frameworks disponibles mientras que desarrollan el código del software. Este método protege otras funciones mientras se realizan cambios en el software. Es además una manera más rápida y eficiente de encontrar errores en el programa.
Un principio fundamental en las metodologías Ágiles es poseer un software funcional en todo momento. En la práctica, la única manera de hacer esto es asegurando que todo el desarrollo de software se compila, lanza y testea regular y automáticamente. Esto se realiza normalmente muchas veces al día y al menos una vez cada vez que un desarrollador “ingresa” código como parte de la rama principal de desarrollo.
to be done. Encontramos tres niveles en la planificación Ágil del desarrollo: release, iteration y task. En las primeras etapas del desarrollo, los desarrolladores y clientes se reúnen para discutir las historias de usuario que se necesitan para el software. Esta reunión inicial se centra en las funciones que deben aparecer, de manera que se pueda estimar y priorizar todo lo que se necesita hacer.
La planificación de la Release (lanzamiento, en español) es una sesión de planificación dirigida al cliente. Tanto los clientes como los desarrolladores eligen un día para el primer lanzamiento del producto. Colaboran en decidir qué historias incorporar en cada release. Los desarrolladores se centran en los esfuerzos estimados de cada historia, mientras que los clientes se centran en la selección de historias. Hay varias formas de estimar esfuerzos, que están determinados por las necesidades y deseos del cliente y los equipos de desarrollo.
La planificación de Iteraciones requiere esfuerzos conjuntos entre los clientes y los desarrolladores para impulsar parte del plan de release. Durante las iteraciones, el cliente define y prioriza las historias de usuario, mientras que los desarrolladores estiman cuánto esfuerzo es necesario para desarrollar cada historia de usuario. La línea de tiempo es mucho menor en las iteraciones, durando solo semanas, en lugar de meses.
La planificación de Tareas ocurre tras la planificación de la iteración. Las historias se dividen en una serie de pasos realizables por el equipo de desarrollo. Se hacen las listas de tareas y se publican en la sala de proyecto de manera que todos los miembros del equipo puedan verlas. Las herramientas que se utilizan comúnmente en este proceso son los post-it y las pizarras. Cada desarrollador elige voluntariamente una tarea y asigna un tiempo estimado para realizarla.
Gracias al pair programming, dos desarrolladores trabajan como un equipo en una tarea. Una persona es la Conductora, la persona que ingresa el código, mientras que la segunda persona es la navegadora, la que planea los siguientes pasos mientras que adecúa el código al conjunto.
Una de las quejas más comunes sobre el pair programming es que se malgastan recursos humanos para realizar la tarea. No se debería utilizar dos personas para un trabajo que puede hacer una sola. Aun así, aunque la programación gasta más energía humana, el resultado final justifica el coste. Un estudio reciente afirma que el pair programming utiliza un 15% más de esfuerzo humano, pero da lugar a un 15% menos de defectos. Aunque los resultados pueden variar en cada caso, los desarrolladores suelen afirmar que la reducción de errores hace que los recursos extra utilizados merezcan la pena.
Otro beneficio es que el pairing (emparejamiento, en español) no se requiere a tiempo completo. Los equipos pueden establecer sus propias reglas y horario al decidir si es mejor hacer parejas.
Durante la integración continua, los equipos de desarrollo integran su código en el sistema varias veces al día. Se realizan una serie de pruebas antes de ingresar el código para asegurarse de que no dañará otras funciones del sistema. El desarrollador debe ejecutar primero todas las pruebas del sistema y solucionar cualquier error que surja antes de integrar los demás códigos. Cuanto más a menudo se integra un código en el software, más fácil y rápido es detectar errores.
Las Retrospectivas son reuniones que se llevan a cabo al final de cada proyecto o cerca de él. Dan a todos los equipos envueltos en el proyecto la oportunidad de echar la vista atrás y reflexionar sobre el trabajo hecho durante el proceso. Todo el equipo puede ver qué funciono bien, qué no, qué se puede mejorar y, más importante, cómo pueden convertir las lecciones adquiridas en cambios sustanciales.
La gestión Ágil es un fascinante y excitante método de desarrollo de software. Al integrar los desarrolladores del producto y los clientes en los procesos de planificación e implementación, el resultado es una experiencia más gratificante para todo el mundo.
Cuando la programación Ágil se realiza correctamente, las organizaciones pueden encontrar continuamente caminos para incrementar el valor para sus clientes. Da más significado a aquellos que están trabajando en el proyecto y crea una experiencia más positiva para el cliente, produciendo beneficios mayores para la compañía.