1. Scrum Extreme Programming Test Driven Development Sinceridad Como Valor Agil Juegos Agiles Behavior Driven Development
2. El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparaciones con las metodologías tradicionales. Además se describe con mayor detalle Programación Extrema (eXtreme Programming, XP) la metodología ágil más popular en la actualidad
3. Características de un desarrollo ágil
3.1. Proceso iterativo e incremental Mitigación del riesgo mediante iteraciones fijas Mejora continua Calidad desde el primer día Priorización de requerimientos de acuerdo a su valor Equipos dedicados y auto-gestionados Colaboración continua con el cliente Incorporar al cambio Prácticas de desarrollo modernas
4. Metodologías y prácticas ágiles
5. Principios ágiles
5.1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
6. Ventajas del desarrollo agil
6.1. Simplificación de la sobrecarga de procesos
6.1.1. Los equipos que trabajan para crear productos regulados por estándares de la industria, deben demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de trabajo para asegurarse de que cumplen con los estrictos mandatos de código. Las metodologías ágiles pueden ayudarles a cumplir los estándares de la industria con menos sobrecarga utilizando iteraciones más cortas y empaquetadas.
6.2. Calidad mejorada
6.2.1. Las prácticas de desarrollo ágil proporcionan la funcionalidad suficiente como para satisfacer las expectativas de los accionistas con una alta calidad. Piensa en lo que significa “ofrecer lo suficiente”. Eso es, proporcionar la mínima funcionalidad con la máxima calidad. La mínima funcionalidad no implica necesariamente una pobre funcionalidad, implica lo suficiente como para conseguir que el trabajo se realice. Los accionistas suelen pensar que saben lo que quieren cuando especifican altos niveles de requerimientos para un producto TI o de software. Sin embargo, la mayoría de las veces, cuando ven el producto final, éste no resuelve el problema.
6.3. Mejorar la previsibilidad a través de una mejor gestión del riesgo
6.3.1. Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a muchas razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo difícil que sería utilizar la nueva tecnología; los requerimientos podían no estar del todo claros o los clientes cambiaron de opinión cuando el trabajo estaba prácticamente finalizado. En cualquier caso, los negocios demandan productos que cumplan con las fechas de entrega, de modo que los planes de negocio directamente relacionados con ellos puedan cumplirse. Hay muchas formas en las que las metodologías ágiles pueden ayudar a que los proyectos TI cumplan con las fechas de lanzamiento previstas.
6.4. Mejor perfil de productividad
6.4.1. Los equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo largo de todo el ciclo de desarrollo. El desarrollo tradicional suele mostrar un patrón de trabajo parecido a un palo de hockey, empezando con un ciclo de diseño de abajo arriba, moviéndose hasta una fase de prototipo para pasar luego a un ciclo de desarrollo largo, seguido por otro ciclo totalmente impredecible en el que se integran las piezas para pasar, por último, a la fase de prueba final. A medida que el proyecto progresa, los equipos tienen que trabajar juntos de manera más coherente, confiando en que todas las piezas trabajen juntas tal y como esperan. Pero lo cierto es que esto raramente ocurre, de modo que la interacción entre los equipos aumenta a medida que lo hacen los problemas de integración. Por último, la fase de pruebas lleva todo esto al límite.
6.5. Capacidad para aprovechar las inversiones realizadas
6.5.1. Adoptar las técnicas ágiles de manera satisfactoria precisa un importante soporte de herramientas. La mayoría de los equipos invierten fuertemente en buenas herramientas de software y necesitan elevar esa inversión y reducir la cantidad de cambios cuando empiezan a adoptar las metodologías ágiles. La inversión más crítica es una buena planificación y una herramienta de gestión del trabajo que proporcione una cartera de pedidos del equipo visible y que asocie el trabajo con cada elemento de trabajo en cartera. Idealmente, esa herramienta de planificación se integra con otras herramientas de desarrollo, lo que permite a los equipos mantener la trazabilidad de la cartera de pedidos en otros aspectos
7. Desventajas del desarrollo agil
7.1. Como en cualquiera otra metodología, también hay desventajas y problemas que surgen a la hora de implementarlas
7.1.1. Falta de documentación del diseño. El código no puede tomarse como una documentación. En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de código fuente. -Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades. -Falta de calidad. Probar el código de forma constante no genera productos de calidad, sólo revela falta de análisis y diseño. -Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los diseños convencionales, los proyectos ágiles dependen críticamente de las personas. -Falta de procesos de revisión del código. Con métodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programación en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador. -Falta de reusabilidad. La falta de documentación hacen difícil que pueda reutilizarse el código ágil. -Sobre costos y retrasos derivados de la refactorización continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorización no pueden despreciarse. -Restricciones en cuanto a tamaño de los proyectos abordables. -Rigidez. Algunos métodos ágiles son muy rígidos: deben cumplirse muchas reglas de una forma estricta para garantizar el éxito del proyecto. Por ejemplo XP exige en realidad mucho esfuerzo, concentración y orden. -Cambios. Los modelos de datos son “pesados” y no pueden cambiarse así como así solo porque el cliente que ira incorporar más funciones al sistema. -Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.