Desarrollo de software. Programación extrema (eXtreme Programming: XP) II
En el anterior artículo se describieron los principios en los que se sustenta esta metodología. Ahora toca analizar las distintas fases que conforman su ciclo de vida.
1) Exploración
Se realiza la toma de contacto con el proceso o procesos de negocio que se van a informatizar así como con la arquitectura y tecnología de desarrollo. Básicamente se realizan las siguientes tareas:
– Historias de usuario: Suponen una de las principales novedades de la metodología y no por el producto en sí, sino por cómo se elabora. Se trata de especificaciones de funcionalidades deseadas del sistema (podrían ser comparables a descripciones de casos de uso) que realizan los mismos usuarios (el mismo cliente), por lo que sus contenidos están en el mismo lenguaje que los usuarios manejan.
Se trata de especificaciones iniciales cuyo nivel de detalle dependerá de la información que precisen los programadores para realizar una estimación del tiempo que requerirá su implementación. Más adelante, cuando se vaya a abordar el proceso de construcción, los programadores recabarán todo el detalle que necesiten para el desarrollo de la funcionalidad mediante el diálogo directo con el cliente.
A nivel documental, una historia de usuario será como una ficha, a la que se le asigna una numeración (sería como el ID de la ficha), un nombre, un autor, un número de versión (una historia de usuario puede retocarse todas las veces que sean necesarias), una prioridad, un nivel de riesgo, una estimación de tiempo de desarrollo, el número de iteración que se le asigna, una descripción y unas observaciones.
Como es puede apreciar, existen diversos aspectos que cumplimentan los técnicos del proyecto (o el mismo usuario si el técnico le facilita la información), pero la mayor parte de la ficha es responsabilidad del cliente.
– Definición de la arquitectura del sistema.
– Posibilidad de realizar algún prototipo, si fuera necesario, para determinar la viabilidad de determinadas soluciones técnicas o tecnológicas.
2) Planificación:
Los programadores realizan la estimación del tiempo necesario para implementar cada historia de usuario. En algunos casos será necesario complementarlas con spikes, que pueden ser desde simples bosquejos a mano alzada, prototipos estáticos, prototipos dinámicos, etc…, estos, en función de su complejidad, podrán ser elaborados por usuarios, técnicos o de forma colaborativa. El objetivo es intentar disminuir en lo posible el margen de error en la estimación.
Las historias de usuario pueden contener especificaciones de funcionalidades simples o complejas (composición de funcionalidades). Dado que se considera que cada historia de usuario debe ser programada entre una y tres semanas, es necesario realizar ajustes en las mismas para que entren en ese período de tiempo, de manera que si se estima que se desarrollan en menos de una semana es necesario agrupar historias de usuario y si tardan más de tres semanas, dividirlas en partes.
Una vez que las tareas de estimación han terminado, el siguiente producto a obtener es el plan o cronograma de entregas (Release Plan), en el que participan todos los actores del proyecto. En él se definen las historias de usuario que se implementan en cada iteración.
Como estamos ante un proceso de desarrollo iterativo e incremental, resulta conveniente la revisión de este Release Plan cada cierto número de iteraciones, con el objeto de ajustarlo en cada momento a la realidad del proyecto (en el desarrollo de las iteraciones pueden aparecer nuevas historias de usuario o modificaciones de las ya existentes) y de corregir aspectos de la planificación que no se hayan estimado convenientemente, como por ejemplo la velocidad del proyecto (número de historias de usuario que se pueden implementar por iteración), ya que lo mismo se ha sido demasiado optimista o pesimista.
Se considera que cada iteración debe llevar a lo sumo dos o tres semanas (hay autores que sitúan el margen entre una y cuatro semanas) y que una entrega completa (el resultado de varias iteraciones disponible para su paso a producción) no debería tardar más de tres meses.
3) Iteraciones
Se desarrolla en cada iteración el conjunto de historias de usuario que se han seleccionado para la misma. Cada una de ellas se clasifica en tareas de ingeniería que vendrían a considerarse como las entradas de trabajo para cada equipo de programadores.
A nivel documental, como sucede con las historias de usuario, las tareas de ingeniería vendrían a ser como una ficha que contendría el número identificador de la tarea, el identificador de la historia de usuario con la que está relacionada, el nombre de la tarea, el tipo (nuevo desarrollo, corrección, mejora, etc…), la fecha de inicio, su fecha de fin, el equipo responsable y la descripción.
Como se comentó anteriormente los detalles que necesite el equipo de trabajo para realizar la tarea de ingeniería los tratará directamente con el usuario.
Cuando se construye se tienen en cuenta todas las prácticas especificadas en el primer artículo: construcción de pruebas unitarias, refactorización, pruebas unitarias, pruebas de integración, etc…
Para cada historia de usuario se definen pruebas de aceptación que deben ser realizadas (como mínimo) al final de cada iteración, donde también se realizan pruebas de regresión (comprobando que se verifican adecuadamente las pruebas de aceptación de iteraciones anteriores).
4) Producción:
Se realizan pruebas adicionales y de rendimiento antes de la puesta en producción efectiva de la versión de la aplicación con la que se ha estado trabajando.
En esta fase, donde el cliente realiza la aceptación del producto que se pasa a producción pueden ser detectadas determinadas correcciones o mejoras a incorporar al sistema previo a su puesta en funcionamiento real. Sobre las mismas se puede tomar la decisión de incluirlas en esta versión o en otra sucesiva, si se decide incorporarlas, se realizarán iteraciones más cortas para llevarlas a cabo.
5) Mantenimiento:
En esta fase el equipo de proyecto debe realizar, si fuera necesario, un mantenimiento correctivo del proyecto mientras puede llevar a cabo nuevas iteraciones.
6) Muerte del proyecto:
No existen más historias de usuario que incluir en el sistema, el cual además es estable en aspectos no funcionales.
Jummp 
Seria bueno subir algunos ejemplos de los diagramas de XP
sobre Historias de usuario, tarjetas CRC