Please enable JavaScript.
Coggle requires JavaScript to display documents.
Metodología Ágil de Desarrollo de Software – XP - Coggle Diagram
Metodología Ágil de Desarrollo de Software – XP
Introducción
La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que utiliza las metodologías tradicionales.
Generalmente el proceso de desarrollo llevaba asociado un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada.
Qué es XP
XP es una metodología ágil para el desarrollo de software y consiste básicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades del cliente para lograr un producto de buena calidad en poco tiempo, centrada en potenciar las relaciones interpersonales como clave para el éxito del desarrollo de software.
La filosofía de XP es satisfacer al completo las necesidades del cliente, por eso lo integra como una parte más del equipo de desarrollo.
Promueve el trabajo en equipo, preocupándose en todo momento del aprendizaje de los desarrolladores y estableciendo un buen clima de trabajo.
Valores de XP
Existen 5 valores clave de la metodología XP, estos son:
Retroalimentación
La retroalimentación continua del cliente permite a los desarrolladores llevar y dirigir el proyecto en una dirección correcta hacia donde el cliente quiera.
Valentía
Requiere que los desarrolladores vayan a la par con el cambio, por que sabemos que este cambio es inevitable, pero el estar preparado con una metodología ayuda a ese cambio.
Simplicidad
La simplicidad ayuda a que los desarrolladores de software encuentren soluciones más simples a problemas, según el cliente lo estipula.
Respeto
El equipo debe trabajar como uno, sin hacer decisiones repentinas. Extreme Programming promueve el trabajo del equipo.
Comunicación
Prevalece en todas las prácticas de Extreme Programming. Comunicación cara a cara es la mejor forma de comunicación, entre los desarrolladores y el cliente.
Roles XP
Roles de acuerdo con la
propuesta original de Beck :
Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona
realimentación al equipo en el proceso XP.
Determina cuándo es necesario realizar algún
cambio para lograr los objetivos de cada iteración
Entrenador (Coach)
Es responsable del proceso global.
Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.
Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir
las pruebas funcionales.
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto.
Cliente
El cliente escribe las historias de usuario y las
pruebas funcionales para validar su implementación.
Gestor (Big boss)
Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas.
Programador
El programador escribe las pruebas unitarias y
produce el código del sistema.
Modelo XP
La metodología XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance.
Sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores
El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función de los valores de las otras tres.
Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones. La siguiente figura esquematiza los ciclos de desarrollo en cascada e iterativos tradicionales, comparados con el de XP.
Proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo.
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
El programador construye ese valor de negocio.
El programador estima el esfuerzo necesario para su implementación.
Vuelve al paso 1.
El cliente define el valor de negocio a implementar.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden.
Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar en las siguientes Fases:
Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas.
En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son:
historias de usuario no abordadas
velocidad del proyecto
pruebas de aceptación no superadas en la iteración anterior
tareas no terminadas en la iteración anterior.
Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente.
En esta fase no se realizan más desarrollos funcionales, pero pueden ser necesarias tareas de ajuste (“fine tuning”).
Planificación de la Entrega (Release)
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas.
Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto.
Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema.
Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.
La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.
Reglas y prácticas
La metodología XP tiene un conjunto importante de reglas y prácticas. En forma genérica, se pueden agrupar en:
Reglas y prácticas para el Diseño
Diseño
La metodología XP hace especial énfasis en los diseños simples y claros.
Los conceptos más importantes de diseño en esta metodología son los siguientes:
Soluciones “spike”
Cuando aparecen problemas técnicos, o cuando es difícil de estimar el tiempo para implementar una historia de usuario, pueden utilizarse pequeños programas de prueba (llamados “spike”), para explorar diferentes soluciones.
Recodificación
La recodificación (“refactoring”) consiste en escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad, a los efectos de hacerlo más simple, conciso y/o entendible.
Simplicidad
Un diseño simple se implementa más rápidamente que uno complejo. Por ello XP propone implementar el diseño más simple posible que funcione.
Metáforas
Una “metáfora” es algo que todos entienden, sin necesidad de mayores explicaciones. La metodología XP sugiere utilizar este concepto como una manera sencilla de explicar el propósito del proyecto, y guiar la estructura y arquitectura del mismo.
Reglas y prácticas para el Desarrollo
Desarrollo
Los conceptos más importantes del desarrollo en esta metodología son los siguientes:
Programación en pares
XP propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador.
Adicionalmente, la programación en pares tiene
las siguientes ventajas:
La mayoría de los errores se descubren en el momento en que se codifican, ya que el código es permanentemente revisado por dos personas.
La cantidad de defectos encontrados en las pruebas es estadísticamente menor. Los diseños son mejores y el código más corto.
El equipo resuelve problemas en forma más rápida.
Las personas aprenden significativamente más, acerca del sistema y acerca de desarrollo de software.
El proyecto termina con más personas que conocen los detalles de cada parte del código.
Las personas aprenden a trabajar juntas, generando mejor dinámica de grupo y haciendo que la información fluya rápidamente.
Las personas disfrutan más de su trabajo.
Integraciones permanentes
Todos los desarrolladores necesitan trabajar siempre con la “última versión”. Realizar cambios o mejoras sobre versiones antiguas causan graves problemas, y retrasan al proyecto.
Programación dirigida por las pruebas (“Test-driven programming”)
En las metodologías tradicionales, la fase de pruebas, incluyendo la definición de los tests, es usualmente realizada sobre el final del proyecto, o sobre el final del desarrollo de cada módulo.
Propiedad colectiva del código
En un proyecto XP, todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto.
Uso de estándares
Si bien esto no es una idea nueva, XP promueve la programación basada en estándares, de manera que sea fácilmente entendible por todo el equipo, y que facilite la recodificación
La metodología XP indica que debe llevarse un ritmo sostenido de trabajo. Anteriormente, ésta práctica se denominaba “Semana de 40 horas”.
Disponibilidad del cliente
Uno de los requerimientos de XP es tener al cliente disponible durante todo el proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del grupo.
Reglas y prácticas para la Planificación
Planificación
La metodología XP plantea la planificación como un dialogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores o gerentes.
Los conceptos básicos de esta planificación son los siguientes:
Plan de entregas (“Release Plan”)
El cronograma de entregas establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas.
Plan de iteraciones (“Iteration Plan”)
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden prestablecido.
Las Historias de Usuario
Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software.
Respecto de la información contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto.
Reuniones diarias de seguimiento (“Stand-up meeting”)
El objetivo de tener reuniones diarias es mantener la comunicación entre el equipo, y compartir problemas y soluciones.
Reglas y prácticas para las Pruebas
Existen 3 factores claves en las reglas y prácticas de las pruebas de un software estos son:
Detección y corrección de errores
Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente, y se deben tener precauciones para que errores similares no vuelvan a ocurrir.
Pruebas de aceptación
Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo.
Pruebas unitarias
Las pruebas unitarias son una de las piedras angulares de XP. Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados.
Ventajas
Evidentemente, para que algo esté siendo tomado tan en cuenta como la XP, debe ofrecer una serie de ventajas a la hora de ponerlo en práctica que haga que el esfuerzo de entender y aplicar sus prácticas, sea insignificante con respecto a los beneficios obtenidos.
Estas son:
Obtenemos código más simple y más fácil de entender, reduciendo el número de errores.
Gracias a la filosofía del “pair programming” (programación en parejas), se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP.
Se consiguen productos más fiables y robustos contra los fallos gracias al diseño de los test de forma previa a la codificación.
Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario.
Se atienden las necesidades del usuario con mayor exactitud.
Conseguimos tener un equipo de desarrollo más contento y motivado.
El proceso de integración es continuo, por lo que el esfuerzo final para la integración es nulo.
Se consiguen productos usables con mayor rapidez
Conclusiones y recomendaciones
Conclusiones
Los desarrolladores deben estar involucrados en todas las funcionalidades del proyecto
La programación en parejas ayuda a reducir costo y tiempos y mejorar la calidad del proyecto.
Organiza a los integrantes del equipo para trabajar a un mismo ritmo divertido y con horario adecuado.
Los métodos en cascada o espiral son los más adecuados para proyectos.
El cliente le da un valor agregado al proyecto ya que ayuda a que los requerimientos sean más compresibles y de fácil aprobación.
Que requieran decenas de desarrolladores y en los que las especificaciones estén claramente determinadas desde el comienzo
Es difícil estimar el costo y duración del proyecto por no existir una definición desde inicio.
Recomendaciones
Usar XP en equipos pequeños de desarrollo que no superen a 20
Se debe involucrar al cliente en el desarrollo del proyecto desde el inicio hasta el final ya que es indispensable que conozca y apruebe la metodología.
Los desarrolladores deben compartan el código y ser responsables del código de todo el proyecto.
Para proyectos medianos, y en los que las especificaciones no se puedan obtener hasta luego de comenzado el proyecto, XP es la metodología recomendada.
Desventajas
Estas son:
No se puede aplicar a proyectos de gran escala, que requieran mucho personal, a menos que se las subdivida en proyectos más pequeños.
Es más complicado medir los avances del proyecto, pues es muy complicado el uso de una medida estándar.
Resulta muy complicado planear el proyecto y establecer el costo y la duración del mismo.
Altas comisiones en caso de fallar.
