Con XP los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. La habilidad de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista para obtener un excelente solución a los problemas de negocio, antes que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después para gestionar los cambios en los mismos.
Si profundizamos en XP descubriremos que en esencia tiene muchos paralelismos con Scrum, la diferencia principal radica en que XP está pensado exclusivamente para la construcción de software, y Scrum es aplicable a la construcción iterativa de cualquier naturaleza en un entorno de incertidumbre y complejidad.
 |
| Modelo de practicas XP - Thanks to Ron Jeffries |
- En el circulo azul las que se aplican "n" veces al día
- En el circulo verde las que se realizan diariamente
- En el circulo rojo las prácticas que se realizan una vez por iteración (sprint) / release
- El equipo de desarrollo es multifucional, con analistas (ayudan al cliente a definir los requisitos), desarrolladores, testers (ayudan al cliente con los tests UAT), etc.
- El equipo debe de incorporar a un representante del cliente a modo de Propietario del Producto quién provee de requisitos, marca las prioridades y guía la dirección del proyecto.
- Usualmente hay un coach que acompaña al equipo y les facilita en el proceso.
- Puede haber un manager que provee de recursos, que gestiona la comunicación externa, coordina actividades, etc.
Los mejores equipos no tiene especialistas, solo contribuyentes generales con aptitudes especiales.
Planning Game (planificación):
La planificación en XP aborda dos cuestiones: planificar lo que es posible para una fecha de entrega y determinar qué hacer a continuación. La planificación se realiza en dos eventos:
- La planificación de release en la que el cliente presenta las historias de usuario deseadas al equipo de desarrollo y este estima tamaños. En base a estas, y la importancia de cada historia, el cliente establece un plan de releases que los equipos de XP revisan regularmente.
- La planificación de iteración (sprint en Scrum) es en la que se revisa la dirección en la que se mueve el equipo cada par de semanas. El cliente presenta las historias de usuario más importantes para las próximas dos semanas, y el equipo de desarrollo las divide en tareas y refinan su estimación.
Customer Tests (tests de cliente):
El cliente con la ayuda de los desarrolladores define para cada historia pruebas de aceptación que guiarán al equipo en la construcción y mostrarán al final de la iteración que la historia ha sido implementada correctamente. Se automatizarán todas las pruebas posibles para maximizar la calidad.
Las releases deben de ser pequeñas y desplegables en producción en ciclos lo más cortos posibles; diaria, semanal, bisemanal, mensualmente... Deben de ser releases que ofrezcan valor de negocio al usuario final y hagan visible el software y su progreso al cliente.
Simple Design (diseño simple):
Los equipos XP siempre mantienen el código y el diseño lo más sencillo y claro posible, trabajan para que el diseño sea el adecuado para la funcionalidad actual del sistema. Siempre construyen lo mínimo imprescindible de la forma más sencilla posible, no construyen cosas que el cliente no haya pedido, no crean desperdicio.
El diseño en XP no es algo que ocurra una sola vez, se producen sesiones de diseño y de rediseño a través de refactorización a lo largo de todo el proyecto.
Pair Programming (programación por parejas):
Los programadores trabajan por parejas, dos delante del mismo ordenador, en las historias de usuario asegurando que todo código esté revisado por lo menos por otro programador, lo que redunda en un código y tests de mayor calidad. Las parejas se intercambian con frecuencia, a veces diariamente, para construir una base de conocimiento compartida y mejorar sus habilidades.
Los mejores equipos de XP practican TDD, trabajando en ciclos muy cortos escribiendo primero las pruebas para luego codificar el código SUT (System Under Test). De esta manera los equipos producen un código con casi el 100% de cobertura de pruebas unitarias. El código se debe de comprometer en el repositorio de código fuente una o dos veces al día, incluidas pruebas unitarias y estas deben de haberse ejecutado antes correctamente al 100%. Así los programadores reciben información inmediata sobre cómo lo están haciendo a través de esta red de seguridad de las pruebas unitarias.
Extreme Programming se centra en ofrecer valor de negocio en cada iteración. Para lograr entrega a negocio a lo largo de todo el proyecto el software debe estar bien diseñado. XP utiliza un proceso de mejora continua del diseño llamado refactorización.
El proceso de refactorización se centra en la eliminación de la duplicados, en el aumento de la "cohesión" del código y la reducción del "acoplamiento".
Con XP el software se mantiene integrado en todo momento, cada vez que se obtenga una nueva pequeña historia de usuario debe recompilarse todo el software y debe de probarse. Son puntos de integración que que garantizan que el las funcionalidades funcionan correctamente juntas y sobre la infraestructura (arquitectura) existente.
Es mala práctica mantener una versión congelada, durante por ejemplo dos meses, mientras se hacen mejoras para luego integrarlas todas de golpe. Cuando falle algo será costoso encontrar el problema y ya no estaremos calientes para resolverlo rápidamente.
Collective Code Ownership (propiedad del código compartida):
Cualquiera miembro del equipo puede y debe poder conocer, mejorar y tocar cualquier parte del código. Por ello se hacen las pruebas automatizadas que resultan en una red de seguridad que hace posible la propiedad compartida al generar confianza y seguridad en los programadores, si provocan un bug este salta a la vista inmediatamente.
Coding Standard (estándares de código):
Debe de haber un estilo común en todo el código, no importa cual, de forma que parezca que haya sido realizado por una única persona.
Metaphor (metáfora):
Los equipos XP desarrollan una visión común de forma que cada uno pueda hacerse una idea de qué es lo que hace cada parte del software. Debe de estar formulado tan simple y claramente como si fuéramos a explicárselo a nuestra madre o abuela, un ejemplo claro es el "recolector de basura" de java.
Sustainable Pace (ritmo sostenido):
XP está concebido a largo plazo, se debe de trabajar a un ritmo que se pueda mantener indefinidamente, sin días muertos en que no se sabe qué hacer, ni días con sobrecarga y excesos de horas. Al tener claro semana a semana lo que debe de hacerse, el equipo se focaliza en el objetivo cercano de terminar una historia de usuario o release.
No hay comentarios:
Publicar un comentario