Vous êtes sur la page 1sur 10

CARACTERSTICAS DE LA METODOLOGA GIL XP Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin.

Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe es ms importante que la posible prdida de productividad inmediata.

Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorizacin del cdigo, es decir, rescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores. ROLES XP Programador Escribe las pruebas unitarias y produce el cdigo del sistema. Responsable sobre el diseo (refactorizacin, simplicidad) Responsable sobre la integridad del sistema (pruebas) Capacidad de comunicacin Acepta crticas (cdigo colectivo)

Cliente Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Encargado de Pruebas Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de Seguimiento (Tracker) 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. El tiene que conocer el proceso XP a fondo para dar guas al los miembros del grupo. Para que ellos apliquen los procesos correctamente. Consultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Jefe del Proyecto (Gestor)
2

Coordina la comunicacin y cooperacin entre el cliente y los programadores.

FUNCIONAMIENTO

Planeacin La actividad de planeacin (tambin llamada juego de planeacin) comienza escuchando actividad para recabar requerimientos que permiten que los miembros tcnicos del equipo XP entiendan el contexto del negocio para el software y adquieren la sensibilidad de la salida y caractersticas principales y funcionalidad que se requieren. Escuchar lleva a la creacin de algunas historias (tambin llamadas historias del usuario) que describen la salida necesaria, caractersticas y funcionalidad del software que se va a elaborar. Cada historia (similar a los casos de usos) es escrita por el cliente y colocada en una tarjeta indizada. El cliente asigna un valor (es decir, una prioridad) a la historia con base en el valor general de la caracterstica o funcin para el negocio. Despus, los miembros del equipo XP evalan cada historia y le asignan un costo, medido en semanas de desarrollo. Si se estima que la historia requiere ms de 3 semanas de desarrollo, se pide al cliente que la descomponga en historias ms chicas y de nuevo se asigna un valor y costo. Es importante observar que en cualquier momento es posible escribir nuevas historias. Los clientes y desarrolladores trabajan juntos para decidir cmo agrupar las historias en la siguiente entrega (el siguiente incremento de software) que desarrollar el equipo XP. Una vez que se llega a un compromiso sobre la entrega (acuerdo sobre las historias por incluir, la fecha de entrega y otros aspectos del proyecto), el equipo XP ordena las historias que sern desarrolladas en una de 3 formas: 1) Todas las historias se implementarn de inmediato (en pocas semanas), 2) Las historias con ms valor entrarn a la programacin de actividades y se implementarn en primer lugar o 3) Las historias ms riesgosas formarn parte de la programacin de actividades y se implementarn primero. Despus de la primera entrega del proyecto (tambin llamada implemento de software) el equipo XP calcula la velocidad de ste. En pocas palabras, la velocidad del proyecto es el nmero de historias de los clientes implementadas durante la primera entrega. La velocidad del proyecto se usa para: 1) Ayudar a estimar las fechas de entrega y programar las actividades para las entregas posteriores, y 2) Determinar si se ha hecho un gran compromiso para todas las historias durante todo el desarrollo del proyecto. Si esto ocurre, se modifica el contenido de las entregas o se cambian las fechas de entrega final.
4

A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el valor de una ya existente, descomponerlas o eliminarlas. Entonces, el equipo XP reconsidera todas las entregas faltantes y modifica sus planes en consecuencia. HISTORIAS DE USUARIO Segn XP: Escrita por el usuario Terminologa del cliente Bajo nivel de detalle Sirve de base para estimar los tiempos de implementacin No deben ser menos de 20 ni mas de 80

VELOCIDAD DEL PROYECTO Lo que dice XP: Nmero de historias de usuario o tareas de programacin realizadas por iteracin. Sirve de ayuda para estimar la cantidad de historias de usuario a implementar en una determinada iteracin DIVISIN EN ITERACIONES Lo que dice XP: El proyecto se divide en varias iteraciones La duracin de una iteracin vara entre una y tres semanas

ENTREGAS PEQUEAS Lo que dice XP: Entregas funcionales del proyecto frecuentemente

PLAN DE ENTREGAS Lo que dice XP: Reunin al inicio del proyecto Cuales historias de usuario sern implementadas para cada entrega Grado de relevancia para cada historia de usuario Se aproxima el tiempo para la realizacin de cada iteracin
5

Diseo El diseo XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseo sencillo siempre se prefiere sobre una representacin ms compleja. Adems, el diseo gua la implementacin de una historia conforme se escribe: Nada ms y nada menos. Se desalienta el diseo de funcionalidad adicional porque el desarrollador supone que se requera despus. XP estimula el uso de tarjetas CRC como un mecanismo eficaz para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidadcolaborador) identifican y organizan las clases orientadas a objetos que son relevantes para el incremento actual de software. Las tarjetas CRC son el nico producto de trabajo de diseo que se generan como parte del proceso XP. Sin el diseo de una historia se encuentra un problema de diseo difcil, XP recomienda la creacin inmediata de un prototipo operativo de esa porcin del diseo. Entonces, se implementa y evala el prototipo del diseo, llamado solucin en punta. El objetivo es disminuir el riesgo cuando comience la implementacin verdadera y validar las estimaciones originales para la historia que contiene el problema de diseo. XP estimula el rediseo, tcnica de construccin que tambin es un mtodo para la optimizacin del diseo. Fowler describe el rediseo del modo siguiente: Rediseo es el proceso mediante el cual se cambia un sistema de software en forma tal que no altere el comportamiento externo del cdigo, pero si mejore la estructura interna. Es una manera disciplinada de limpiar el cdigo que minimiza la probabilidad de introducir errores. En esencia, cuando se redisea, se mejora el diseo del cdigo despus de haber sido escrito. Como el diseo XP virtualmente no utiliza notacin y genera pocos, si alguno, productos del trabajo que no sean tarjetas CRC y soluciones en punta, el diseo es visto como un artefacto en transicin que puede y debe modificarse continuamente a medida que avanza la construccin. El objetivo del rediseo es controlar dichas modificaciones, sugiriendo pequeos cambios en el diseo que son capaces de mejorarlo en forma radical. Sin embargo, debe notarse que el esfuerzo que requiere el rediseo aumenta en forma notable con el tamao de la aplicacin. Un concepto central en XP es que el diseo ocurre tanto antes como despus de que comienza la codificacin. Redisear significa que el diseo se hace de manera continua
6

conforme se construye el sistema. En realidad, la actividad de construccin en s misma dar al equipo XP una gua para mejorar el diseo.

SIMPLICIDAD Lo que dice XP: El diseo debe ser sencillo. Slo se crearn diagramas tiles

TARJETAS CRC Lo que dice XP: Su principal utilidad es dejar el enfoque procedimental y entrar al modelo orientado a objetos. Todo el grupo participa en su elaboracin.

Codificacin Despus de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseo preliminar, el equipo no inicia la codificacin, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso (incremento de software). Una vez creada la prueba unitaria, el desarrollador est capacitado para centrarse en lo que debe implementarse para pasar la prueba. No se agrega nada extrao (MS). Una vez que el cdigo est terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentacin instantnea para los desarrolladores. Un concepto clave durante la actividad de codificacin (y uno de los aspectos de los que ms se habla en la XP) es la programacin por parejas. XP recomienda que dos personas trabajen juntas en una estacin de trabajo con el objeto de crear cdigo para una historia. Esto da un mecanismo para la solucin de problemas en tiempo real y para el aseguramiento de la calidad tambin en tiempo real. Tambin mantiene a los desarrolladores centrados en el problema que se trate. En la prctica, cada persona adopta un papel un poco diferente. Por ejemplo una de ellas tal vez piense en los detalles del cdigo de una porcin particular del diseo, mientras la otra se asegura de que siguen los estndares de codificacin (parte necesaria de XP) o de que el cdigo
7

para la historia satisfar la prueba unitaria desarrollada a fin de validar el cdigo confrontndolo con la historia. A medida que las parejas de programadores terminan su trabajo, el cdigo que desarrollan se integra con el trabajo de los dems. En ciertos casos, esto lo lleva a cabo a diario un equipo de integracin. En otros, las parejas de programadores tienen la responsabilidad de la integracin. Esta estrategia de integracin continua ayuda a evitar los problemas de compatibilidad e interfaces y brinda un ambiente de prueba de humo que ayuda a descubrir a tiempo los errores. Cliente siempre presente Lo que dice XP: El cliente debe estar disponible en el sitio de trabajo El cliente es fundamental para solucionar dudas cara a cara

El cdigo se escribe siguiendo estndares Lo que dice XP: Al escribir el cdigo del programa se deben seguir estndares de programacin.

Codificar primero la prueba Lo que dice XP: Escribir primero la prueba que el cdigo. El tiempo de escribir una prueba y luego el cdigo del programa para dicha prueba es menor que solo escribir el cdigo. Escribir pruebas primero permite identificar los casos especiales que deber pasar el cdigo. Toda la produccin de cdigo debe ser hecha en parejas Lo que dice XP: Toda la produccin de cdigo debe ser hecha en parejas sentadas frente a un nico computador.
8

Al trabajar en parejas se tiene un diseo de mejor calidad y un cdigo ms organizado.

Al trabajar en parejas se solucionan los problemas ms fcilmente.

Integracin continua El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el cdigo en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%. Pruebas La creacin de pruebas unitarias antes de que comience la codificacin es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategias de pruebas de regresin, siempre que se modifique el cdigo (lo que ocurre con frecuencia, dada la filosofa del rediseo en XP). A medida que se organizan las pruebas unitarias individuales en un grupo de prueba universal [Wel99], las pruebas de la integracin y validacin del sistema puede efectuase a diario. Esto da el equipo XP una indicacin continua del envase y tambin lanza seales de alerta si las cosas marchan mal. Wells [Wel99] dice: corregir pequeos problemas cada cierto nmero de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final. Las pruebas de aceptacin XP, tambin llamadas pruebas del cliente son especificadas por el cliente y se centran es las caractersticas y funcionalidad generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptaciones derivan de las historias de los usuarios que se han implementado como parte de la liberacin del software.

VENTAJAS: Programacin organizada. Menor taza de errores. Satisfaccin del programador. Solucin de errores de programas Versiones nuevas Implementa una forma de trabajo donde se adapte fcilmente a las circunstancias.

DESVENTAJAS: Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar. Imposible prever todo antes de programar Demasiado costoso e innecesario

10

Vous aimerez peut-être aussi