Gestin de Software

Ao 2006

Extreme Programming (XP)

Grupo Integrantes Lber Batalla Diego Fontanarossa Javier Garderes Andrs Gatto

CI: 4.227.3192 CI: 4.227.4124 CI: 4.011.7027 CI: 3.875.4198

1 ndice
1 2 3 4 5 NDICE........................................................................................2 INTRODUCCIN..............................................................................3 HISTORIAS DE USUARIO...................................................................4 PROCESO Y FASES.........................................................................6 REGLAS Y PRCTICAS DE XP.............................................................9
5.1 Planificacin...................................................................................................... 9 5.2 Diseo............................................................................................................. 12 5.3 Codificacin.................................................................................................... 13

6 ROLES EN XP.............................................................................17
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7.1 7.2 7.3 7.4 7.5 Programador................................................................................................... 17 Cliente............................................................................................................ 17 Encargado de pruebas (Tester).......................................................................17 Encargado de seguimiento (Tracker) .............................................................17 Entrenador (Coach)......................................................................................... 18 Gestor (Big Boss)............................................................................................ 18 Consultor........................................................................................................ 18 Doomsayer (Augur de desastres)....................................................................18 Nivel Nivel Nivel Nivel Nivel 1 2 3 4 5 Inicial................................................................................................ 21 Repetible.......................................................................................... 21 - Definido........................................................................................... 22 Gestionado.......................................................................................22 Optimizante......................................................................................23

7 RELACIN ENTRE CONCEPTOS DE XP Y CMM.......................................21

8 CONCLUSIONES............................................................................24

2 Introduccin
Extreme Programming es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Su creador Kent Beck.
Todo en el software cambia. Los requisitos cambian. El diseo cambia. El negocio cambia. La tecnologa cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en s mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando ste tiene lugar.

Es el mtodo que ms popularidad ha alcanzado de las metodologas giles y se basa en la suposicin de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Asume que con un poco de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si se est siguiendo un camino acertado o equivocado, evitando as tener que echar marcha atrs demasiado tarde. Esta metodologa se inspira en los siguientes valores: simplicidad, feedback, coraje y comunicacin. La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en cada momento slo las necesidades actuales. Con este principio de simplicidad, junto con la comunicacin y el feedback resulta ms fcil conocer las necesidades reales. Una metodologa basada en el desarrollo incremental iterativo de pequeas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-informacin (feedback) valioso para detectar los problemas o desviaciones. De esta forma fallos se localizan muy pronto. La planificacin no puede evitar algunos errores, que slo se evidencian al desarrollar el sistema. La retro-informacin es la herramienta que permite reajustar la agenda y los planes.

El coraje implica saber tomar decisiones difciles, reparar un error cuando se detecta, mejorar el cdigo siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora. XP pone en comunicacin directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la agenda y las funcionalidades de forma consecuente.

3 Historias de Usuario
Las historias de usuario son la tcnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras ms especficas o generales, aadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Respecto de la informacin contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto. En muchos casos slo se propone utilizar un nombre y una descripcin o slo una descripcin, ms quizs una estimacin de esfuerzo en das. Beck en su libro presenta un ejemplo de ficha (customer story and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. Una de las interrogantes (que tambin se presenta cuando se utilizan casos de uso) es cul es el nivel de granularidad adecuado para una historia de usuario? La respuesta no es tajante. Jeffries dice que depende de la complejidad del sistema, debe haber al menos una historia por cada caracterstica importante, y propone realizar una o dos historias por programador por mes. Si se tienen menos, probablemente sea conveniente dividir las historias, si se tienen ms lo mejor es disminuir el detalle y agruparlas. Para efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una iteracin). No hay que preocuparse si en un principio no se identifican todas las historias de usuario. Al comienzo de cada iteracin estarn registrados los cambios en las historias de usuario y segn eso se planificar la siguiente iteracin.

Las historias de usuario son descompuestas en tareas de programacin y asignadas a los programadores para ser implementadas durante una iteracin.

4 Proceso y Fases
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 travs del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En la siguiente figura se muestra como esta metodologa es iterativa y utiliza pequeos lapsos de tiempo para realizar las actividades. De tal forma de que los cambios no sean tan costosos.

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto. Fase I: Exploracin En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto.

Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa. Fase II: Planificacin de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacin. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la velocidad de desarrollo, establecida en puntos por iteracin, basndose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ltima iteracin. La planificacin se puede realizar basndose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuntas historias se pueden implementar antes de una fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el nmero de iteraciones necesarias para su implementacin. Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior.

Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores Fase IV: Produccin La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin (por ejemplo, durante la fase de mantenimiento). Fase V: Mantenimiento Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Fase VI: Muerte del Proyecto Es cuando el cliente no tiene ms 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. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. La siguiente figura muestra la ejecucin de las fases.

5 Reglas y Prcticas de XP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la usual curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asinttico. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de un conjunto de prcticas que en base a la experiencia en proyectos de alto riesgo y requerimientos cambiantes, han surgido como receta para un buen desempeo. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica. El mrito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

5.1 Planificacin
El Juego de la Planificacin Es un espacio frecuente de comunicacin entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Esta prctica se puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario segn prioridad y esfuerzo, y se define el contenido de la entrega y/o iteracin, apostando por enfrentar lo de ms valor y

riesgo cuanto antes. Este juego se realiza durante la planificacin de la entrega, en la planificacin de cada iteracin y cuando sea necesario reconducir el proyecto. Escribir Historias de Usuario Las Historias de Usuario se crean con el mismo propsito que los Casos de Uso, pero no son lo mismo. Se utilizan para crear estimaciones de tiempo para las reuniones de planificacin de las liberaciones. Tambin son utilizadas en lugar del Documento de Requerimientos. Las Historias de Usuario son escritas por los clientes como las cosas que el cliente necesita que el sistema haga por l. Son similares a los Escenarios de Uso, excepto porque no estn limitados a describir la interfaz de usuario. Deben ser escritas con un formato de dos o tres lneas de texto, escritas por el cliente usando la terminologa del cliente sin trminos tcnicos. Las Historias de Usuario tambin guan la creacin de las Pruebas de Aceptacin. Uno o ms tests automatizados de aceptacin deberan ser creados de forma que puedan verificar que una historia de usuario haya sido implementada correctamente. Las Historias de usuario deberan tener nicamente la granularidad suficiente para realizar estimaciones de cunto se tardaran en implementar. Cuando llega el momento de implementar la Historia de Usuario, los miembros del equipo encargados de desarrollarla deberan obtener una descripcin ms detallada de los requerimientos personalmente (con el cliente). Los planes de Liberacin organizan el calendario Las reuniones de Planificacin de Liberaciones son utilizadas para construir un Plan de Liberaciones, que organiza el proyecto. Luego, el Plan de Liberaciones es utilizado para crear Planes de Iteracin para cada Iteracin individual. Es importante que las decisiones tcnicas sean tomadas por el personal tcnico y las decisiones de negocios sean tomadas por el personal encargado del negocio. La esencia de la Reunin de Planificacin de Liberaciones es estimar la duracin de la implementacin de cada Historia de Usuario en trminos de Semanas Ideales de Programacin. Una Semana Ideal de Programacin es cunto se estima que llevara implementar la Historia de Usuario si no hubiese nada ms que hacer (sin tomar en cuenta trabajo extra, dependencias, etc., pero incluyendo la implementacin de tests). El cliente elige luego cul historia tiene mayor importancia o prioridad de ser completada. Se podra planificar por fecha o por alcance. La velocidad del proyecto es usada para determinar cuntas historias pueden ser implementadas antes de una fecha dada o cunto tardaran en ser finalizadas un conjunto de historias.

Si se planifica por fecha, se podra determinar cuntas historias de usuario podrn completarse multiplicando el nmero de iteraciones planificadas por la velocidad del proyecto. Si planificamos por alcance, se podra determinar el nmero de iteraciones necesarias para finalizar la liberacin dividiendo la cantidad de historias de usuario por la velocidad del proyecto. Entregas pequeas La idea es producir rpidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero que constituyan un resultado de valor para el negocio. Una entrega no debera tardar ms de 3 meses. Medir la velocidad del proyecto La Velocidad del Proyecto es una medida de cunto trabajo est siendo completado en el proyecto. Para medirla, simplemente se sumaran las estimaciones de las Historias de Usuario que fueron finalizadas durante la Iteracin. Durante las Reuniones de Planificacin de las Iteraciones, los clientes estn habilitados a elegir un nmero de historias a implementar igual a la Velocidad del Proyecto medida en la Iteracin anterior. Luego, son estudiadas tcnicamente y divididas en tareas tcnicas, pudiendo el equipo comprometerse a ejecutar el mismo nmero de tareas tcnicas de la velocidad del proyecto medida en la iteracin anterior. Mediante este mecanismo posibilita la mejora de la planificacin por parte del equipo luego de una iteracin difcil. La idea detrs del uso de la Velocidad del Proyecto es que las estimaciones iniciales suelen ser poco precisas. Por lo cual, sera ms redituable ejecutar algunas iteraciones para poder medir y as obtener una idea ms real sobre el tamao del proyecto. Rotacin del Equipo La rotacin del equipo evita problemas de conocimiento y de cuellos de botella. Si una nica persona puede trabajar en un rea dada y esa persona deja el equipo o tiene otras tareas pendientes, aparecer un atraso en el avance. En ocasiones el entrenamiento de personas para incorporarse a una nueva rea, es un problema que requiere atencin para evitar islas de conocimiento. La rotacin del equipo en conjunto con la Programacin en Parejas, lograran dicho entrenamiento. En lugar de que una persona conozca el cdigo de una seccin completa, todo el equipo conoce todo el cdigo de cada seccin. Con esto el equipo se vuelve ms flexible y se sobrecarga menos. Mejorar el proceso cuando se detecten problemas El proceso debera ser mejorado y reorganizado tan pronto como se detecten problemas. Las reglas de XP deberan ser seguidas en el comienzo pero deben estar abiertas a cambios en lo que no funcione. Esto no significa que

el equipo puede hacer cualquier cosa, sino que las reglas pueden cambiarse una vez detectado que el equipo ha cambiado su funcionamiento. La nica forma de tener una idea de cunto esperar del equipo es teniendo reglas claras de funcionamiento conocidas por todos. Mediante reuniones con el equipo deberan ser detectados los problemas y de ah buscar la solucin que mejor se adapte.

5.2 Diseo
Diseo Simple Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. Un diseo simple siempre toma menos tiempo para finalizarlo que un complejo. La complejidad innecesaria y el cdigo extra debe ser removido inmediatamente. Siempre es ms rpido y ms barato reemplazar ahora el cdigo complejo antes que gastemos ms tiempo en l. Hay que mantener las cosas lo ms simples posibles tanto como sea posible a travs de no agregar nuevas funcionalidades antes de que sean agendadas. Kent Beck dice que en cualquier momento el diseo adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene lgica duplicada, refleja claramente la intencin de implementacin de los programadores y tiene el menor nmero posible de clases y mtodos. Metforas En XP no se enfatiza la definicin temprana de una arquitectura estable para el sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se generaran por no contar con ella explcitamente en el comienzo del proyecto se solventan con la existencia de una metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema. La prctica de la metfora consiste en formar un conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y mtodos del sistema. Tarjetas CRC Usar Tarjetas CRC (Class, Responsibilities and Collaboration) para disear el sistema en conjunto. La mayor ventaja de las tarjetas CRC es permitir reducir el modo de pensar procedural y apreciar la tecnologa de objetos. Las tarjetas CRC permiten contribuir al diseo a todo el equipo del proyecto. No agregar funcionalidades antes de lo planeado

Siempre estamos tentados en agregar funcionalidades ahora antes que despus debido a que sabemos exactamente como agregarla o porque hara al sistema mucho mejor. Parecera que fuera ms rpido agregarlas ahora pero nosotros debemos recordarnos constantemente que no las necesitamos ahora realmente y quizs nunca las necesitemos. Funcionalidades extra siempre nos hacen atrasar y malgastar nuestros recursos. Refactorizacin La refactorizacin es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. La refactorizacin mejora la estructura interna del cdigo sin alterar su comportamiento externo. Refactorizar a lo largo de todo el proyecto nos ahorra tiempo e incrementa la calidad. El diseo del sistema de software es una cosa viviente. No se puede imponer todo en un inicio, pero en el transcurso del tiempo este diseo evoluciona conforme cambia la funcionalidad del sistema. Para mantener un diseo apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto. De hecho, este cuidado continuo sobre el diseo es incluso ms importante que el diseo inicial. Un concepto pobre al inicio puede ser corregido con esta actividad continua, pero sin ella, un buen diseo inicial se degradar.

5.3 Codificacin
El cliente est siempre disponible El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del xito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho tiempo en generarse y puede tener ms riesgo de ser mal interpretada. Las historias de usuario son escritas por los clientes con la ayuda de los desarrolladores. Los clientes aseguran que la mayora de las funcionalidades deseadas del sistema estn cubiertas por las historias mientras que los desarrolladores ayudan con las estimaciones de tiempo. Durante la planificacin de una liberacin, el cliente debe negociar la seleccin de las historias de usuario que sern incluidas en dicha liberacin. El tiempo de la liberacin deber ser discutido tambin.

Los clientes deben realizar sus decisiones de acuerdo a sus objetivos de negocio. Como los detalles no son incluidos en las historias de usuario, los desarrolladores necesitarn hablar con los clientes para obtener suficientes detalles para completar una cierta actividad de programacin. El cliente tambin ser necesario con las pruebas funcionales. Pareciera que necesitramos una gran cantidad de tiempo del cliente comparado con otras metodologas, pero no debemos olvidarnos que el tiempo del cliente es ahorrado al principio por no requerir una especificacin detallada de los requerimientos y ahorrado despus ya que el sistema es mucho ms probable que sea de su agrado. En algunos casos esta alta disponibilidad del cliente puede ser difcil de conseguir. Algunas recomendaciones propuestas para dicha situacin son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que acte como interlocutor del cliente, contar con el cliente al menos en las reuniones de planificacin, establecer visitas frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas asociados estableciendo llamadas telefnicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo. Estndares de programacin XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin (del equipo, de la organizacin u otros estndares reconocidos para los lenguajes de programacin utilizados). Los estndares de programacin mantienen el cdigo legible para los miembros del equipo, facilitando los cambios. Pruebas unitarias La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. Cuando creamos las pruebas antes del cdigo encontraremos ms fcil y rpida la realizacin del cdigo ya que ayuda a los desarrolladores a entender lo que debe ser hecho. Hay tambin cierto beneficio en el diseo del sistema. A veces es muy difcil testear ciertos sistemas de software, principalmente si el cdigo es escrito antes que las pruebas y por un equipo diferente. Si creamos las pruebas primero, nuestro diseo ser influenciado por el deseo de testear todo lo que es de valor para nuestro cliente. El cdigo que crearemos ser simple y conciso, implementando solo aquellas caractersticas necesarias. Otros desarrolladores podrn ver como usar este nuevo cdigo observando las pruebas.

En este contexto de desarrollo evolutivo y de nfasis en pruebas constantes, la automatizacin para apoyar esta actividad es crucial. Programacin en parejas Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. La programacin de a pares incrementa la calidad del software sin impactar el tiempo para cumplir lo prometido. No es muy intuitivo, pero dos personas trabajando en una sola computadora agregarn tantas funcionalidades como si estuvieran trabajando por separado, excepto que lograrn una mayor calidad. Y con una mayor calidad tendremos grandes ahorros de tiempo en el futuro. Las principales ventajas de introducir este estilo de programacin son: muchos errores son detectados conforme son introducidos en el cdigo (inspecciones de cdigo continuas), por consiguiente la tasa de errores del producto final es ms baja, los diseos son mejores y el tamao del cdigo menor (continua discusin de ideas de los programadores), los problemas de programacin se resuelven ms rpido, se posibilita la transferencia de conocimientos de programacin entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, los programadores conversan mejorando as el flujo de informacin y la dinmica del equipo, y finalmente, los programadores disfrutan ms su trabajo. Dichos beneficios se consiguen despus de varios meses de practicar la programacin en parejas. La mejor forma de programar en parejas es sentarse un junto al otro en frente al monitor. Una persona es la que codifica y piensa tcticamente acerca del mtodo que est siendo creado, mientras que la otra piensa estratgicamente acerca de cmo dicho mtodo encaja dentro de la clase. Integracin secuencial El cdigo es integrado en el repositorio tomando turnos. Esto es, solo una pareja de desarrolladores puede integrar, testear y liberar cambios al repositorio de cdigo en un momento determinado. De esta forma se permite que la ltima versin est consistentemente identificada. Esto no significa que uno no pueda integrar su cdigo con la ltima versin en su propia estacin de trabajo. Lo que no se puede es liberar esos cambios al resto del equipo sin esperar su turno. Integracin contnua Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. En ningn caso se puede estar sin integrar por ms de un da.

Es una forma de que todo el mundo est trabajando con casi la ltima versin. De este modo evitamos que los cambios sean hechos sobre versiones obsoletas, lo que sera un gran problema a la hora de integrar. Adems evita o detecta antes los problemas de compatibilidad. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea incorporado definitivamente. La integracin continua a menudo reduce la fragmentacin de los esfuerzos de los desarrolladores por falta de comunicacin sobre lo que puede ser reutilizado o compartido. Propiedad colectiva del cdigo Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algn programador sea imprescindible para realizar cambios en alguna porcin de cdigo. Optimizar al final No hay que optimizar hasta el final. Tampoco hay que intentar adivinar cual ser el cuello de botella de nuestro sistema, sino que hay que medirlo. Hazlo que ande, hazlo bien, y luego hazlo rpido. 40 horas por semana Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificacin para cambiar el mbito del proyecto o la fecha de entrega.

6 Roles en XP
Aunque en otras fuentes de informacin aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck.

6.1 Programador
El programador escribe las pruebas unitarias y produce el cdigo del sistema. Define las tareas que conlleva cada historia de usuario, y estima el tiempo que requerir cada una. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo.

6.2 Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema. En cualquier caso, debe tener la autoridad necesaria para responder dudas respecto a historias de usuario ya existentes.

6.3 Encargado de pruebas (Tester)

El 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.

6.4 Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Mantiene contacto directo y continuo con el equipo de desarrollo evaluando la situacin. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin, involucrando al Gestor, Entrenador, o al Cliente en el caso considerarlo conveniente.

6.5 Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Es el responsable de proveer la tecnologa y metodologas a usar por el equipo de desarrollo. Oficia de mentor para los miembros menos experientes de forma de asegurar su desempeo en el proyecto, y media entre los miembros del equipo para asegurar un ambiente saludable de trabajo.

6.6 Gestor (Big Boss)

Es el dueo del equipo y sus problemas. Persona experta en tecnologa y labores de gestin, su labor esencial es de coordinacin. Es la imagen del equipo al exterior. Elige los miembros que conformaran el plantel, obtiene los recursos necesarios y maneja los problemas que se generan. Agenda reuniones (planes de iteracin, agenda de compromisos, etc), verifica que se realicen de manera adecuada y registra lo referente a las mismas. No le dice al grupo lo que tiene que hacer (el Cliente y el plan de iteracin lo hacen), cuando hacerlo (la agenda de compromisos lo hace), ni verifica el avance de las tareas (Tracker).

Roles opcionales: 6.7 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.

6.8 Doomsayer (Augur de desastres)

Es el responsable de asegurarse que se conocen los riesgos involucrados, que las malas noticias se den a conocer en la medida correcta, y que no se sobredimensionen. Debe buscar posibles riesgos en forma constante, presentndolos al equipo siempre con una alternativa para tratar el problema.

Combinacin de Roles
Algunos roles pueden ser combinados en un mismo individuo. Por ejemplo, la misma persona puede ser el Gestor y el Tracker simultneamente. Sin embargo, la combinacin de otros roles perjudicara al correcto desempeo del rol como tal. Ejemplos de ello serian: Programador-Tracker

Programador-Tester Cliente-Programador Entrenador-Tracker

El Gestor probablemente no debera ser combinado con ningn otro rol excepto de Tracker. Tambin se considera que el Entrenador no debera combinarse con el Programador, aunque es posible que se realice en forma exitosa.

Comparacin de los Roles entre PIS y XP

A continuacin de muestra una tabla con los roles mencionados en el Proyecto de Ingeniera de Software (PIS), y los roles ms similares que se presentan en XP: PIS XP Administrador Gestor Responsable de la Comunicacin Entrenador Analista Programador Implementador Programador Especialista Tcnico Programador Arquitecto Programador Responsable de Reuso Programador Diseador de Interfaz de Usuario Programador Responsable de Integracin Programador Asistente de Verificacin Tester - Cliente Responsable de Verificacin Tester Responsable de SQA Tester - Programador Coordinador de Desarrollo N/A (Tracker) Responsable de SCM N/A (Progamador) Si bien los roles aqu comparados no son anlogos en forma directa, las responsabilidades implicadas se comparten en forma mayoritaria. Existen casos a su vez en los que un rol definido convencionalmente pueda repartir sus responsabilidades, como es el caso con el Cliente en XP. El mismo, al proveer de las pruebas de aceptacin desde el comienzo, puede ser visto como un asistente de verificacin. Por otro lado, existen roles en PIS que no son definidos en forma explicita en XP, como ser el caso de los Responsables en general. Si bien estas tareas deben realizarse, la responsabilidad es ms compartida entre los miembros del equipo. En particular los roles de Coordinador de Desarrollo y el Responsable de SCM no son contemplados en XP. En el caso de la gestin de configuracin, al estar tan relacionada con las actividades de los Programadores en XP lo consideramos adecuado para la comparacin. El Coordinador de Desarrollo deja de existir en XP

directamente ya que se definen las tareas a realizar en los planes de iteracin. Sin embargo, algunas de las tareas del Tracker pueden ser comparables con ciertas responsabilidades del coordinador mencionado.

7 Relacin entre conceptos de XP y CMM

Ron Jeffries (Consultor Senior internacional, quien ha participado activamente desde los inicios de XP junto a Kent Beck, siendo el primer XP Coach con dedicacin completa (full-time)), plantea que ciertas caractersticas encontradas en CMM (hasta en los niveles ms altos), estn presentes en el proceso de desarrollo de XP y analiza nivel a nivel, los principales parecidos.

7.1 Nivel 1 Inicial

XP especficamente recomienda dos niveles de planificacin, los cuales forman el Juego de la Planificacin. Dichos niveles, estn basados en las estimaciones de los desarrolladores para la produccin y en la priorizacin por parte del cliente. El proceso de la Planificacin conjunta resulta en un estimativo de qu ser producido y cmo. El Plan de Iteracin, planifica un intervalo pequeo y los resultados de cada iteracin retroalimentan el siguiente plan para redefinir y depurar la Planificacin. Esto redundar en la atenuacin de las sucesiones de crisis caractersticas en las organizaciones clasificadas como Nivel 1 en CMM. Las prcticas recomendadas por XP, redundan en la desaparicin de hroes imprescindibles encargados de apagar incendios. En su lugar, la aparicin de integrantes del equipo que se tornen imprescindibles, es un indicio de que algo est funcionando mal, lo cual debera ser investigado en profundidad para determinar sus causas para reparar el proceso. A su vez, la prctica de la Programacin en Parejas, redunda en no necesitar personal excepcional para poder realizar el trabajo y en general es mejor tener dos mentes atacando un problema que una excelente. El Gestor, no especifica qu se debe hacer a cada momento. Por el contrario, se dedica a controlar el progreso y a servir de interlocutor con la Direccin, dejando las decisiones tcnicas y las asignaciones para ser tratadas en conjunto por el equipo de desarrollo y por un proceso voluntario. Al ser visto de esta manera, XP apelara a la correctitud del seguimiento del proceso, ms que a las individualidades dentro del equipo para resolver los problemas, por lo que no dependera de las personas y podra pensarse que sera repetible.

7.2 Nivel 2 Repetible

XP claramente especifica un conjunto de prcticas las cuales estn bien definidas y estn documentadas. El equipo debe estar entrenado

al inicio del proyecto, tiene un Coach en tiempo completo y entrena a los nuevos miembros en las prcticas del proceso. La programacin en parejas y contar con un proceso abierto y accesible, asegura que todos los miembros del equipo saben que est pasando en el sistema. En XP existe la constante preocupacin por cuatro variables: Recursos, Alcance, Calidad y Tiempo. Dichas variables permitiran determinar si se est cumpliendo la planificacin con la calidad deseada a medida que transcurre el proyecto, siendo posible reportar las mediciones a la alta gerencia. A raz de lo anterior, podra reunirse, a primera vista y cumpliendo con las prcticas recomendadas, los requerimientos del nivel dos de CMM para hacer del proceso XP un proceso repetible, practicable, definido, documentado, capacitando a nuevo personal en l, medido y mejorable.

7.3 Nivel 3 - Definido

Las reglas de XP encaminaran el criterio de transparencia del proceso (por ejemplo: la completitud de las Historias de Usuario), de las entradas, estndares y procedimientos, mecanismos de verificacin, salidas y criterios de aceptacin. Nuevamente, utilizando las cuatro variables especificadas anteriormente, XP permitira una gestin simple, teniendo una visin clara de la performance del proceso.

7.4 Nivel 4 Gestionado

XP especifica los objetivos de calidad para los productos mediante los Test Funcionales. Permanentemente es requerido que las pruebas unitarias se mantengan en un 100% de cumplimiento, por lo que el nmero de Pruebas Unitarias correctas no sera una estadstica interesante. Podramos definir el Factor de Carga, el cual relaciona el tiempo transcurrido con las estimaciones de dificultad de los desarrolladores. Igualmente no sera un objetivo cuantitativo, pero podran medirse los cambios en el Factor de Carga como una idea de hacia dnde apuntar los esfuerzos de mejora. Algunas variables candidatas a ser medidas seran: el nmero de pruebas unitarias vs. el nmero de clases del sistema, la tasa de cambios de creacin de tests, el nmero de clases, las tasas de lneas de cdigo de clases/mtodos, etc.

7.5 Nivel 5 Optimizante

Las prcticas de XP recomiendan una mejora continua del proceso y del desarrollo en s, detectando cada falla en el transcurso del proyecto y teniendo una retroalimentacin para no repetir errores del pasado. Esto cabra en la definicin del Nivel 5 CMM asociado a la mejora continua. Igualmente, no podemos olvidar el contexto en el cual XP estara recomendado, que es en proyectos de alto riesgo, con requerimientos cambiantes y con equipos de trabajo no superiores en nmero a 20 personas, por lo que los requerimientos de documentacin y de rigurosidad de CMM son aligerados por XP.

8 Conclusiones
Las metodologas giles han ganado popularidad desde que se public su manifiesto, siendo XP el miembro del grupo que goza de mayor aceptacin en el rea. Estas metodologas buscan simplificar los procesos a travs de la reduccin de irreversibilidad de los mismos. XP es una metodologa que para ser aplicada en forma correcta deben seguirse sus directivas en forma constante, aunque permite ciertas flexibilidades. Las doce prcticas propuestas Kent Beck son un punto de comienzo, pero XP variar en cada ambiente. Debe hacerse notar que si se deja de lado el ambiente de trabajo abierto (las instalaciones no lo permiten), el cliente en la misma oficina (si no tienen los recursos de tiempo y personal necesarios), y la programacin de a pares (al equipo no le agrada y trabajan en forma remota), etc etc, puede pasar de encontrarse pensando que se esta haciendo XP cuando en realidad no se estn obteniendo sus beneficios. XP requiere que el equipo sea consciente y piense en lo que funciona de manera correcta y lo que no, buscando nuevas formas de mejorar el proceso. Qu nos dice XP que ya sabamos? Numerosas cosas: La alta comunicacin funciona. Si el equipo se establece en una misma sala donde se puedan tomar decisiones y evaluar los resultados, la velocidad de las cosas aumenta dramticamente. La Validacin es importante. XP reduce el tiempo entre una idea, su criterio de validacin, y su implementacin. Al requerir tests repetibles automatizados, el equipo se asegura de estar avanzando correctamente. El Iterar funciona. La idea de las iteraciones no es nueva, pero muchos equipos declaran ser iterativos cuando no lo son. XP obliga a iterar al establecer mltiples integraciones por da, iteraciones de una a tres semanas de largo que concluyan con un sistema funcionando, y nuevos lanzamientos cada pocos meses.

Cul es el mayor desafo involucrado al implementar XP? Identificar e implementar el 90% de las soluciones Fragmentar las historias en historias ms sencillas y consistentes.

Saber distinguir entre lo que es importante y lo que no.

Hacia donde va XP? En las siguientes lneas se encontraran algunas de las opiniones ms populares al respecto: La simplificacin y clarificacin del proceso. El proceso de planificacin aun se siente algo ms complicado de lo que debera ser. La forma de integrar continuamente probablemente no se encuentre explicada suficientemente. La idea bsica es muy poderosa, pero muchos equipos aun no la utilizan. Buscar valores ocultos. La comunidad de XP ha estado explorando en busca de principios ocultos que puedan informar de mtodos tiles. Limites de XP. Puede un equipo grande utilizar XP? Cundo y dnde XP es la opcin correcta a seguir? Tests de Aceptacin. XP usa tests de aceptacin automatizados generados por el propio cliente. A medida que esta prctica se implemente en distintos ambientes posiblemente se note un impacto en la opinin de los desarrolladores. El rol del Cliente. La visin del programador en este rol es: Dme un grupo de historias sencillas para trabajar, responda todas mis preguntas, y dme un grupo de tests para saber cuando habr terminado.. Ser cliente de software es un trabajo complejo, y posiblemente se generen nuevas ideas al respecto.