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
Que es?
Consiste básicamente en ajustarse estrictamente a una serie de reglas que se centra en potenciar las relaciones interpersonales para el desarrollo
Su filosofía es satisfacer al completo las necesidades del cliente
Promueve el trabajo en equipo
Adecuado para los proyectos con requisitos imprecisos, muy cambiantes
La comunicación es un punto importante y debe realizarse entre los programadores, los jefes de proyecto y los clientes.
Valores de XP
Comunicación
Comunicación cara a cara entre los desarrolladores y el cliente.
Simplicidad
Ayuda a que los desarrolladores de software encuentren soluciones más simples, según lo que diga el cliente
Retroalimentacion
La retroalimentación continua del cliente permite a los desarrolladores llevar el proyecto hacia donde el cliente quiera.
Valentia
Requiere que los desarrolladores vayan a la par con el cambio
Respeto
El equipo debe trabajar como uno, sin hacer decisiones repentinas.
Roles XP
Programador
El programador escribe las pruebas unitarias y produce el código del sistema.
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementación.
Encargado de pruebas (Tester)
Ayuda al cliente a escribir las pruebas funcionales.
Encargado de seguimiento
Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado comunicando los resultados para mejorar futuras estimaciones.
Entrenador(Coach)
Es responsable del proceso global.
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto.
Gestor (Big boss)
Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente
Modelo XP
Define 4 variables: costo, tiempo, calidad y alcance.
Existen ciclos de desarrollo cortos (llamados iteraciones)
Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones.
Proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar
El ciclo de desarrollo consiste (a grandes rasgos) en:
El cliente define el valor de negocio a implementar.
El programador estima el esfuerzo necesario para su implementación.
El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
El programador construye ese valor de negocio.
Vuelve al paso 1.
El ciclo de vida de un proyecto XP se puede separar en:
Exploración,
Los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo
Iteraciones
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.
Durante la elaboración el Plan de la Iteración se debe tener en cuenta:
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.
Planificación de la Entrega (Release)
El cliente establece la prioridad de cada historia de usuario, y los programadores realizan una estimación del esfuerzo necesario de cada una de ellas
Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto(semana)
La planificación se puede realizar basándose en el tiempo o el alcance.
Producción
Requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente.
Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana.
No se realizan más desarrollos funcionales, pero pueden ser necesarias tareas de ajuste
Mantenimiento
La velocidad de desarrollo puede bajar después de la puesta del sistema en producción.
Se requiere de tareas de soporte para el cliente
Muerte del Proyecto.
Es cuando el cliente no tiene más historias para ser incluidas en el sistema.
También ocurre cuando el sistema no genera los beneficios esperados por el cliente
Reglas y practicas
Se agrupan en:
Planificación
Plantea un dialogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores
El proyecto comienza recopilando “Historias de usuarios”
Si alguna de ellas tiene “riesgos” que no permiten establecer con certeza la complejidad del desarrollo, se realizan pequeños programas de prueba
3 diferencias con otras metodologías
Los planes son realizados por las mismas personas que realizarán el trabajo.
Los planes no son predicciones del futuro, sino simplemente la mejor estimación de cómo saldrán las cosas.
Simplicidad del plan: No se espera que un plan requiera de un “gurú”
Conceptos básicos de la planificación:
Historias de usuario
Técnica utilizada en XP para especificar los requisitos del software.
En cualquier momento historias de usuario pueden romperse, remplazarse, añadirse nuevas o ser modificadas.
En muchos casos sólo se propone utilizar un nombre y una descripción
Plan de entregas
Establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de estas.
Típicamente el cliente ordenará y agrupará según sus prioridades las historias de usuario.
Plan de iteraciones
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden prestablecido
Para cada historia de usuario se establecen las pruebas de aceptación.
Estas pruebas se realizan al final del ciclo en el que se desarrollan, pero también al final de cada uno de los ciclos siguientes
Reuniones diarias de seguimiento
Mantiene la comunicación entre el equipo, y se comparten problemas y soluciones.
Diseño
Diseños simples y claros
Simplicidad
Diseño simple se implementa más rápidamente que uno complejo.
Implementar el diseño más simple posible que funcione.
Soluciones
Pueden utilizarse pequeños programas de prueba (llamados “spike”), para explorar diferentes soluciones
Recodificacion
Escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad, conciso y/o entendible.
Los resultados de ésta práctica tienen sus frutos en las siguientes iteraciones, cuando sea necesario ampliar o cambiar la funcionalidad.
Metaforas
Manera sencilla de explicar el propósito del proyecto, y guiar la estructura y arquitectura del mismo.
Debe ser fácil de comprender para el cliente y a su vez debe tener suficiente contenido como para que sirva de guía a la arquitectura del proyecto
Desarrollo
Disponibilidad del cliente
Tener al cliente disponible durante todo el proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del equipo
No se requieren de largos documentos de especificaciones, sino que los detalles son proporcionados por el cliente
Uso de estandares
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.
Programacion dirigida por las pruebas
Lo primero que se escribe son los test. Luego, el desarrollo debe ser el mínimo necesario para pasar las pruebas previamente definidas.
Programacion en pares
XP propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador.
Al trabajar en pares se minimizan los errores y se logran mejores diseños, compensando la inversión en horas.
Ventanjas:
La mayoría de los errores se descubren en el momento en que se codifican
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 detallas 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
Publicar lo antes posible las nuevas versiones, aunque no sean las últimas, siempre que estén libres de errores.
Propiedad colectiva del codigo
Todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto.
Ritmo sostenido
Planificar el trabajo de manera de mantener un ritmo constante y razonable, sin sobrecargar al equipo.
Pruebas
Pruebas unitarias
Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados.
Las pruebas deben ser definidas antes de realizar el código
Detección y correccion de errores
Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente
Se generan nuevas pruebas para verificar que el error haya sido resuelto
Pruebas de aceptacion
Son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo.
El cliente debe especificar uno o diversos escenarios para comprobar que ha sido correctamente implementada.
Los clientes son responsables de verificar que los resultados de estas pruebas sean correctos
Una historia de usuario no se puede considerar terminada hasta tanto pase correctamente todas las pruebas de aceptación.
Ventajas y Desventajas
Ventajas
Se consiguen productos usables con mayor rapidez.
El proceso de integración es continuo
Se consigue integrar todo el trabajo con mucha mayor facilidad.
Esto se consigue gracias a las continuas versiones que se ofrecen al usuario.
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.
Obtenemos código más simple y más fácil de entender, reduciendo el número de errores.
Gracias a la filosofía de programación en parejas, se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP.
Gracias al recodificación es más fácil el modificar los requerimientos del usuario.
Conseguimos tener un equipo de desarrollo más contento y motivado, y la comunicación entre los miembros del equipo que consigue una mayor integración entre ellos.
Desventajas
Resulta muy complicado planear el proyecto y establecer el costo y la duración del mismo.
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.
Altas comisiones en caso de fallar.
