Proyecto Extreme Programming: Reglas, Pautas y Normas

La Figura 5^, indica los criterios a^, seguir en cada proceso del proyecto empleando la metodología^, Extreme Programming.

31 Figura 5

Proyecto Extreme Programming: Reglas, pautas y normas

Nota: La figura muestra la línea guía que se debe seguir en el desarrollo de un proyecto con XP. Tomado de ExtremeProgramming.ORG, 2013.

A. PLANEAMIENTO (PLANNING) Historias de Usuario (User stories)

Las Historias de Usuario y los Casos de Uso de la metodología UML no son lo mismo, pero tienen la misma finalidad. Se emplean para establecer los pronósticos de tiempo para la junta de entregas proyectadas. Además, se manejan en cambio de una exagerada documentación. Las Historias de Usuario son desarrolladas por los clientes, hacen referencia a las necesidades del sistema a implementar, prescindiendo del uso de sintaxis o empleo de términos específicos.

La Figura 6 muestra una plantilla para elaborar las Historias de Usuario.

32 Figura 6

Historias de Usuario: Estructura para su elaboración.

Nota: La figura muestra los ítems que se deben valorar en la implementación de cada historia de usuario.

Planificación de Lanzamiento (Release Planning)

Después de definir un pico arquitectónico y de adquirir un número adecuado de Historias de Usuario, el equipo elabora un plan de lanzamiento de las características previstas para el lanzamiento en base a las prioridades acordadas con el cliente. La reunión de planificación de lanzamiento es una reunión que tiene como objetivo definir un plan de lanzamiento de características que se delineará y formalizará con un Plan de lanzamiento.

Hay dos momentos principales en el desarrollo de un plan de lanzamiento:

 Planning Game: que se puede definir como la técnica que permite al equipo, a partir del Backlog, definir el Plan de Liberación.

 Planning Poker: representa una técnica ágil para estimar y planificar fuertemente basada en el consenso de los participantes. Mientras que, en el juego de planificación, el propietario del producto, la persona de negocios, está fuertemente involucrados en la definición de las prioridades para cada una de las Historias de Usuario, en la planificación del Poker las luces se centran casi exclusivamente en el equipo de desarrollo, incluso si se permite la presencia del Cliente.

.

Pequeños Lanzamientos (Small Releases)

La vida y el desarrollo de la aplicación están marcados por el lanzamiento de versiones funcionales del producto. Cada lanzamiento representa el punto final de una iteración de desarrollo y el comienzo de una nueva planificación.

33 Para tener en cuenta los cambios de perspectiva, los errores de evaluación, los nuevos requisitos, las restricciones presupuestarias, cada iteración no debe durar más de unas pocas semanas (generalmente, de dos a cuatro).

Durante la fase de producción, se construye un sistema inicial simple, que se entrega al cliente. Durante las iteraciones para la construcción de versiones posteriores, los requisitos se implementarán tratando de asegurarse de producir una versión que traiga pequeños incrementos y en el menor tiempo posible. En cualquier caso, estos aumentos son decididos por el cliente y generalmente representan las siguientes características de mayor prioridad que quedan por implementar.

Los pequeños lanzamientos son esenciales en la metodología, ya que muestran la precisión del equipo hacia el proyecto. Porque en el momento de su etapa de planificación, solo se tenían vistas e ideas estimadas de la reacción del cliente en función del rendimiento de la computadora y cuán fácil de usar será su software. Pero ahora, con pequeños lanzamientos, puede conocer la reacción o los comentarios reales de sus clientes. También brindan comentarios esenciales y oportunos de los clientes. Estos comentarios ayudan a saber qué se debe cambiar en el software antes de su lanzamiento principal. Sus publicaciones deben ser iterativas, lo que significa que cada problema que los clientes recibieron en una versión debe corregirse en la próxima versión pequeña.

Iteraciones

En Extreme Programming, el esfuerzo se desglosa en términos de iteraciones.

Las iteraciones generalmente duran de una a tres semanas y generalmente se planifican unos días o una semana antes de que realmente comiencen. El objetivo es maximizar el valor que se produce durante una iteración, al mismo tiempo que selecciona una cantidad de trabajo que se puede completar de manera cómoda y segura dentro del tiempo permitido. Cada iteración debe contener una colección de historias de usuario, infraestructura y tareas que respaldan esas historias y los casos de prueba.

La Figura 7 muestra el esquema XP, que conduce las iteraciones ejecutadas sobre el desarrollo del proyecto.

34 Figura 7

Iteración en un Proyecto Extreme Programming

Nota: La figura muestra las iteraciones que se realizan en un proyecto implementado con XP.

Tomado de ExtremeProgramming.ORG, 2013.

Planificación de la Iteración (Iteration Planning) ^,

Por lo general, alrededor de una semana antes de que comience la iteración, el administrador del proyecto, el propietario del negocio y algunas personas clave (líder tecnológico, patrocinador comercial, etc.) se reúnen para planificar la siguiente iteración. Lo que sucede en esta reunión suele ser bastante fácil de entender, pero puede ser necesario algo de delicadeza para hacerlo.

A lo largo del proyecto, ha estado recopilando estas historias y debería tener una acumulación de ellas que aún no se han entregado. Como ahora se encuentra en la etapa de planificación de la iteración, ahora tiene la tarea de identificar qué tareas abordará la iteración que está a punto de comenzar. En general, hay dos factores prioritarios principales: proporcionar valor y reducir el riesgo. El objetivo de esta reunión es equilibrar las dos necesidades y seleccionar la lista de historias que se entregará en las próximas una a tres semanas. El resultado de esta reunión de planificación de la iteración debe ser una lista priorizada de lo que al propietario del proyecto le gustaría que se produjera a continuación.

Entonces, en la reunión, se identificó las historias de usuario que se desean entregar. Ahora es el momento de planificar la iteración en sí. Para hacer esto, se necesita que un personal senior de entrega, arquitectos, líderes del equipo técnico, líderes de control de calidad, etc., coloquen estimaciones junto a cada trabajo. Algunos serán pequeños y otros serán grandes; de nuevo, esto se espera. El líder del proyecto aceptar la cantidad de trabajo que cree que se

35 puede entregar cómodamente en el tiempo disponible. La clave es entregar los elementos de mayor prioridad en todo momento. Idealmente, sería en estricto orden, pero a veces eso no es posible. Pero debe minimizar la cantidad de artículos de menor prioridad que está entregando. El último paso en el proceso es seleccionar las historias que entregará y publicar esa lista al propietario de la organización para su ratificación. Una vez que el propietario o los propietarios estén de acuerdo, estará listo para comenzar la iteración.

Así se planifica una iteración en programación extrema. Se necesita una combinación de arte y ciencia. Se debe determinar cuáles son las historias de usuario de mayor prioridad y luego determinar cuánta capacidad tiene su equipo para entregarlas. Luego, lleva la lista de trabajos "aceptados" al cliente y busca la aprobación. Entonces se realiza la entrega. Y en una a tres semanas, se hace todo de nuevo.

En esta fase los desarrolladores planifican su propia actividad a realizar sobre las historias definidas en la fase anterior. Durante esta fase, las historias de usuario se pueden dividir en tareas técnicas. Los desarrolladores (o pares de desarrolladores) asumen las tareas en las que pretenden trabajar como parte de la iteración.

B. ADMINISTRACIÓN

Espacio Abierto Dedicado

Para un equipo de Programación Extrema (XP) la comunicación es fundamental.

Puede agregar rutas de comunicación primordiales a su equipo simplemente derribando las barreras que dividen a las personas. Ubicar las estaciones de trabajo en un área central sin propietario facilita la programación en pareja y alienta a las personas a trabajar juntas con sentimientos de igual valor y contribuciones. Poner algunos escritorios alrededor del perímetro brinda a las personas un lugar para trabajar solos sin desconectarse del resto del equipo.

Incluir un área grande para reuniones diarias de pie evita que las personas se pierdan la reunión. Añadir una mesa de reuniones le brinda un hogar para los debates grupales que ocurren espontáneamente. Poder ver los debates alienta a las personas a oír o unirse a ellos cuando tienen interés en el resultado.

Agregar pizarras para bosquejos de diseño y lugares donde se pueden pegar tarjetas de historias de usuarios agrega aún más canales para la comunicación.

36 Establecer un Ritmo Sostenido, Medible y Predecible

Para establecer su ritmo, debe tomar en serio los extremos de la iteración. Se requiere el software más completo, probado, integrado y listo para producción que pueda obtener en cada iteración. El aplicativo incompleto o con fallas constituye una desconocida cantidad de esfuerzo futuro, motivo por el que no se puede realizar su medición. Si se considera que no podrá terminar todo al final de la iteración, organice una cita de planificación de la iteración y vuelva a definir el alcance de la misma para optimizar la velocidad de su proyecto. Incluso si solo queda poco tiempo en la iteración, es conveniente que el equipo vuelva a concentrarse en una tarea completa que en muchas incompletas.

Laborar horas extras consume espíritu y motivación del equipo. Cuando su equipo se canse y se desmoralice, harán menos trabajo, no más, sin importar cuántas horas trabajen. Trabajar demasiado hoy roba el progreso del desarrollo del futuro. No puedes hacer planes realistas cuando tu equipo hace más trabajo este mes y menos el mes que viene. En lugar de presionar a las personas para que hagan más de lo humanamente posible, emplee una asamblea de planificación de lanzamiento para cambiar el tiempo o alcance del proyecto.

Fred Brooks dejó en claro que agregar más personas también es una mala idea cuando un proyecto ya está retrasado. La aportación que hacen muchas personas nuevas suele ser negativa. En su lugar, refuerce su equipo de desarrollo lentamente con mucha anticipación, tan pronto como prediga que un lanzamiento será demasiado tarde.

Un ritmo sostenible lo ayuda a planificar sus lanzamientos e iteraciones y evita que entre en una marcha de la muerte. Encuentra la velocidad perfecta de tu equipo que se mantendrá constante durante todo el proyecto. Cada equipo es diferente. Exigir que este equipo aumente la velocidad para igualar a ese equipo en realidad reducirá su velocidad a largo plazo. Entonces, cualquiera que sea la velocidad de tu equipo, acéptala, protégela y utilízala para hacer planes realistas.

Las Reuniones de Pie Inician Cada Día

Cada mañana se realiza una reunión para discutir los problemas, sus soluciones y aumentar el enfoque del equipo. La reunión se lleva a cabo de pie para evitar largas discusiones que no interesan a todos los miembros del equipo.

En una reunión típica, la mayoría de los asistentes no aportan nada, solo asisten para escuchar lo que otros tienen que decir. Se dedica mucho tiempo a obtener una pequeña cantidad de comunicación. Por lo tanto, la participación de todas

37 las personas en las reuniones roba recursos al proyecto y genera caos en la planificación.

Se requiere una reunión permanente para este tipo de comunicación. Es mucho mejor tener una reunión breve y obligatoria que muchas reuniones largas a las que la mayoría de los desarrolladores deben asistir de todos modos.

Si tiene reuniones diarias permanentes, a todas las demás reuniones solo deben asistir aquellas personas que sean necesarias y que aporten algo. Además, también es posible evitar algunos encuentros. Con un número limitado de participantes, la mayoría de las reuniones pueden tener lugar de forma espontánea frente a un monitor, donde el intercambio de ideas es mucho más intenso.

La reunión matutina diaria no es otra pérdida de tiempo. Le ahorrará muchas más reuniones y le ahorrará más tiempo del que desperdicia.

Velocidad del Proyecto

Es una medida de las labores que se están ejecutando en el proyecto. Para medir la velocidad del proyecto, simplemente se suman las estimaciones de las historias de usuario que terminaron durante la iteración. Es así de simple.

También suma las estimaciones de las tareas finalizadas durante la iteración.

Ambas medidas se utilizan para la planificación de iteraciones.

Durante la reunión de planificación de la iteración, los clientes pueden elegir la misma cantidad de historias de usuario igual a la velocidad del proyecto medida en la iteración anterior. Esas historias se dividen en tareas técnicas y el equipo puede registrarse para la misma cantidad de tareas similar a la velocidad del proyecto de la iteración pasada.

Este mecanismo simple permite a los desarrolladores recuperar y limpiar después de una iteración difícil y promedia las estimaciones. La velocidad de su proyecto aumenta al permitir que los desarrolladores pidan a los clientes otra historia cuando su trabajo se completa antes de tiempo y no quedan tareas de limpieza. Se esperan algunos altibajos en la velocidad del proyecto. Debe usar una reunión de planificación de lanzamiento para volver a estimar y renegociar el plan de lanzamiento si la velocidad de su proyecto cambia drásticamente durante más de una iteración. Espere que la velocidad del proyecto cambie nuevamente cuando el sistema se ponga en producción debido a las tareas de mantenimiento. La velocidad del proyecto es una medida tan detallada como puede hacer que sea precisa.

38 No se moleste en dividir la velocidad del proyecto por la duración de la iteración o el número de personas. Este número no sirve para comparar la productividad de dos proyectos. Cada equipo de proyecto tendrá un sesgo diferente para estimar historias y tareas, algunos estiman alto, algunos estiman bajo. No importa a la larga. El seguimiento de la cantidad total de trabajo realizado durante cada iteración es la clave para mantener el proyecto en movimiento a un ritmo constante y predecible.

El problema con cualquier proyecto es la estimación inicial. La recopilación de muchos detalles no hace que su estimación inicial sea más que una conjetura.

Preocúpate por estimar el alcance general del proyecto y hazlo bien en lugar de crear documentos grandes. Considere dedicar el tiempo que habría invertido en crear una especificación detallada para hacer un par de iteraciones de desarrollo. Mida la velocidad del proyecto durante estas exploraciones iniciales y adivine mucho mejor el tamaño total del proyecto. Esto se consigue por medio de la programación en parejas y de la propiedad colectiva del código. Ver Figura 9.

Reparar Cuando XP se Rompe

Arreglar el proceso en el momento que se rompa. Sigue las reglas de XP para iniciar, pero no dudar en cambiar lo que no funciona. Esto no significa que el equipo pueda hacer lo que quiera. Las reglas deben seguirse hasta que el equipo las haya cambiado. Todos sus desarrolladores deben saber exactamente qué esperar unos de otros, tener un conjunto de reglas es la única forma de establecer estas expectativas.

Organizar reuniones retrospectivas para hablar sobre lo que funciona y lo que no, e idee formas de mejorar XP. Haga que mejorar su proceso sea una parte normal de su desarrollo.

C. DISEÑO Simplicidad

XP siempre trata de encontrar la solución más simple, un enfoque que tiene muchas ventajas. Cuando uno se enfoca solo en los factores necesarios, uno no se detiene en aspectos innecesarios. Esto también incluye desarrollar solo las funciones necesarias en este momento, en lugar de comenzar a trabajar para cualquier requisito futuro. De esta manera el equipo acelera el desarrollo.

Además, un producto ágil es mucho más fácil de gestionar, tanto en las últimas

39 etapas de desarrollo como en el mantenimiento. Finalmente, un código de programación lo más simple posible también nos permite comprender la importancia de la comunicación: si todo el equipo es capaz de comprender el código fuente, se vuelve más fácil discutir sobre él.

Sistema Metáfora^,

Un Sistema Metáfora fue fácil de elegir en los primeros dos proyectos de Programación Extrema (XP) (C3 y VCAPS). C3 fue construido como una línea de producción. VCAPS se estructuró como una lista de materiales. Esos dos proyectos eran raros porque ya habían estado funcionando durante un año o más cuando hicieron la transición a XP. Se necesita un conocimiento profundo sobre el sistema para elegir una buena metáfora y esos equipos la tenían.

Ahora System Metaphor es en sí mismo una metáfora de un diseño simple con determinadas características. La característica más importante es poseer una estructura que ayude a las personas nuevas a comenzar a contribuir rápidamente. La segunda característica es un diseño que haga consistentes a las clases y métodos de nomenclatura.

Utilizar tarjetas CRC

Las tarjetas CRC (Clase, Responsabilidades, Colaboración) son una actividad que une los mundos de los juegos de rol y el diseño orientado a objetos.

Con la intención de esbozar rápidamente varias ideas diferentes para el diseño de alguna característica de un sistema orientado a objetos, dos o más miembros del equipo escriben en fichas los nombres de las clases más destacadas involucradas en la característica. Luego, las tarjetas se completan con listas de las responsabilidades de cada clase y los nombres de los colaboradores, es decir, otras clases de las que dependen para llevar a cabo sus propias responsabilidades.

El siguiente paso es validar, o invalidar, según sea el caso, cada idea de diseño representando un escenario plausible de la computación, cada desarrollador asumiendo el papel de una o más clases.

Emplear tarjetas CRC para diseñar el sistema en equipo. El valor agregado que otorgan las tarjetas CRC es facilitar que las personas rompan con el modo de pensamiento procedimental. Las tarjetas CRC permiten que equipos de proyecto completos contribuyan al desarrollo.

40 Una sesión de CRC procede con alguien que simula el sistema al hablar sobre qué objetos envían mensajes a otros objetos. Al recorrer paso a paso las debilidades y los problemas del proceso, se descubren fácilmente. Las alternativas de diseño se pueden explorar rápidamente simulando el diseño que se propone.

Si se encuentra demasiadas personas hablando y moviendo cartas a la vez, simplemente limite el número de personas de pie y moviendo cartas a dos.

Cuando una persona se sienta, otra puede ponerse de pie. Esto funciona para las sesiones que se salen de control, lo que a menudo sucede cuando los equipos se vuelven ruidosos cuando finalmente se resuelve un problema difícil.

Una de las mayores críticas a las Tarjetas CRC es la falta de diseño escrito. Por lo general, esto no es necesario ya que las tarjetas CRC hacen que el diseño parezca obvio. Si se requiere un registro más permanente, se puede escribir una tarjeta para cada clase en su totalidad y conservarla como documentación. Un diseño, una vez imaginado como si ya estuviera construido y funcionando, se queda con una persona durante algún tiempo.

Figura 8

Tarjetas CRC (Clase, responsabilidad y colaboración)

Nota: La figura nos muestra los elementos de una tarjeta CRC

Spike Solutions^,

Crear Spike Solutions para descubrir respuestas a problemas técnicos o de diseño difíciles. Un Spike Solution es un programa muy simple para explorar posibles soluciones. Se construye el Spike para que aborde solamente el problema bajo análisis e ignore las demás distracciones. El objetivo que se persigue es minimizar el riesgo de un problema técnico o maximizar la confiabilidad de la valoración de una historia de usuario.