Programación Extrema (eXtreme Programing, XP)

Informática VI

Introducción

Contenido

Historia

Objetivos

Valores

Roles

Reglas(5)

Historia

Historia

Es creada porKent Beck en el año de 1996.

Ésta metodología se desarrolló en Chrysler Corporationmientras se realizaba una aplicación de nóminas.

Beck se dio cuenta que los procesos deberían de ser flexibles yrápidos para realizar cambios ágiles en las estructuras.

Las ideas primordiales de su sistema las comunicó en la revista“C++Magazine” en una entrevista que le hicieron en 1999.

Objetivos

Objetivos

Crear un método que hiciera que los desarrollos fueran más sencillos.¡Aplicando Sentido común!.

Potenciar el trabajo en grupo, involucrando a todos en el desarrollo delSoftware.

El objetivo principal de XP es la satisfacción del cliente, por tanto laagilidad para responder las necesidades de él , es de vital importancia.

Establecer las mejores prácticas de Ing de SW en el desarrollo del proyecto.

Mejorar la productividad de los proyectos.

Garantizar la calidad del SW, haciendo que éste supere las expectativas delcliente

Valores

Valores

XP no es en realidad un conjunto de reglas, sino más bien una manera detrabajar en armonía con sus valores personales y corporativos.

Simplicidad: “Desarrollaremos lo que sea solicitado y necesario, pero nomás que eso”.

Comunicación: “Todos somos parte de un equipo y nos comunicamos”. Retroalimentación: “Tomaremos seriamente los compromisos con el

usuario, se mostrará al usuario el software frecuentemente y de formatemprana, escuchando cuidadosamente sus observaciones y realizando loscambios que sean necesarios”.

Coraje: “Diremos la verdad en nuestros avances y estimados, no hayexcusas para el fracaso, planificamos para tener éxito”.

Respeto: Todos en el equipo dan y reciben el respeto que merecen comointegrantes del equipo y los aportes de cada integrante son valorados portodos”.

Roles

Roles

Programador: Produce el código del sistema.

Cliente: Escribe y asigna prioridad a las historias de usuarios.

Tester: Encargado de ejecutar difundir resultados de las pruebas y esresponsable de las herramientas de soporte de las mismas.

Tracker: Encargado de seguimiento.

Entrenador (coach): Guía a los miembros del equipo para seguir elproceso correctamente.

Consultor: Miembro externo con conocimiento especifico de un temanecesario para el proyecto.

Gestor (Big boss): Dueño y es el vinculo entre cliente y programadores.

Reglas

Reglas

Planificación: Hacer entregas frecuentes. El proyecto se divide eniteraciones.

Administración: Espacio de trabajo abierto. La velocidad de proyecto esmedido.

Diseño: Simplicidad. Se realizan cambios en el código en lugar demodificar el diseño. La empresa ahorra costos.

Codificación: El código debe ser escrito. Todo el código de producción espara ser programado. Integrar a menudo. Configurar un dedicado equipode integración.

Pruebas: Todo el código debe pasar todas las pruebas unitarias antes deque pueda ser liberado. Cuando se encuentra un error se crean pruebas.Las pruebas de aceptación se ejecutan a menudo y la puntuación sepublica.

Fases de la programación Extrema

Contenido

Planeación

Administración

Diseño

Codificación

Pruebas

Planeación

Planeación

En el juego de planificación, el cliente y los programadoresnegocian el alcance del proyecto para cada iteración.

El factor crítico es permitir al cliente tomar las decisionesde negocio y al equipo de desarrollo tomar las decisionestécnicas.

Para planear la programación extrema debemos detomar en consideración algunas piezas claves como son:

Costo Calidad Tiempo

Planeación

• Juego de planificación.

• Versiones pequeñas.

• Historias.

Planeación

Planeación(Artefactos)

Historia del Usuario

Historia de Usuario

Número: Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):

Usuario: Iteración Asignada:

Prioridad enNegocio:

(Alta / Media / Baja)

Puntos Estimados:

Riesgo enDesarrollo:

(Alto / Medio / Bajo)

Puntos Reales:

Descripción:

Observaciones:

Tareas de Ingeniería

Tarea de Ingeniería

Número Tarea: Historia de Usuario (Nro. y Nombre):

Nombre Tarea:

Tipo de Tarea :

Desarrollo / Corrección /

Mejora / Otra (especificar)

Puntos Estimados:

Fecha Inicio: Fecha Fin:

Programador Responsable:

Descripción:

Planeación(Artefactos)

Tarjetas CRC (Clase, responsabilidad, colaborador)

Planeación(Artefactos)

El cliente define el valor del negocio a implementar.

El programador estima el esfuerzo necesario para suimplementación.

El cliente selecciona que construir, de acuerdo con susprioridades y las restricciones del tiempo.

El programador construye ese valor del negocio.

Planeación(Procesos)

Administración

La comunicación es muy importante para un equipo deprogramación extrema. Existen diversos factores quepueden ayudar a ello:

Computadoras:

Colocar computadoras en un área central que no pertenece anadie, vuelve la programación por pares mucho más sencilla eimpulsa a trabajar juntos. Así como colocar algunas en elperímetro, ofrece trabajar solos, pero sin desconectarlos delresto del equipo.

Administración(Work Space)

Área de Reuniones:

También es importante un área donde ocurran las reuniones,como una mesa de conferencias, y que se permita mantenerlas discusiones simultáneas, en una sola mesa de trabajo. Loque alienta a las personas escuchar activamente o inclusounirse a las discusiones y aportar algo.

Administración(Work Space)

Pizarra de Trabajo:

La inclusión de pizarrones para colocar las notas principaleso las historias de usuario.

Tarjetas de información:

Donde pueda informar al equipo, el progreso del proyecto enel cual se esta trabajando.

Administración(Work Space)

Se necesita tener un software completo, probado eintegrado.

En caso de no tener la capacidad necesaria para poderobtener todo, es necesario hacer una reunión deplanificación para maximizar la velocidad del proyecto.

Administración(Sustainable Pace | Ritmo Sostenido de Trabajo)

NO Horas extra de trabajo: Pueden cansar al equipo yralentizar aún más el trabajo.

NO Gente nueva: En cuanto tomo esta decisión esporque me doy cuenta de que mi equipo de trabajo ya valento, es por ello que ya es demasiado tarde.

Administración(Sustainable Pace | Ritmo Sostenido de Trabajo)

SÍ Utilizar reunión de planificación de liberación pararedefinir alcance o en mejor forma el calendario.

¿Para qué nos ayuda?

Planificar versiones e iteraciones, impide entrar entrabajos a marcha de muerte.

Se encuentra una perfecta velocidad del equipo pues semantendrá constante durante todo el proyecto evitandoretrasos o cargas de trabajo exageradas.

Administración(Sustainable Pace | Ritmo Sostenido de Trabajo)

Consiste en:

Reuniones de encuentro cada mañana para comunicar problemas, soluciones, ypromover el enfoque de equipo.

Todo el mundo se pone de pie en un círculo para evitar largas discusiones. Así los miembros del equipo conocen las necesidades y las contribuciones de

todos. Se reportan básicamente 3 aspectos:

Lo que se realizó previamente (un día antes) Lo que se piensa realizar ese mismo día Los retrasos que se han detectado y cuáles son los problemas que los

ocasionan

Ventajas:Es más eficaz tener una breve reunión que se requiere de cada uno para asistir amuchas reuniones con unos pocos desarrolladores cada uno.

Administración(Daily Stand Up Meeting | Reuniones Diarias de Trabajo)

Es una forma de medir la velocidad del proyecto en base alos casos de uso que se tiene, durante la primera iteración.

Durante la reunión de planificación de la iteración losclientes pueden elegir el mismo número de historias deusuario igual a la velocidad del proyecto medidos en laiteración anterior. Esas historias se dividen en tareastécnicas y el equipo se le permite inscribirse en el mismonúmero de tareas iguales a velocidad de proyecto de laiteración anterior.

La velocidad de proyecto sube al permitir a losdesarrolladores pedir otra historia y cuando su trabajo estéterminado temprano y no hay tareas que limpiar.

Administración(Project Velocity)

Como punto importante hay que resaltar que la velocidad delproyecto es tan detallada como una medida que se puede tomar.

Durante este proceso se pueden esperar unos altos y bajos en lavelocidad del proyecto, si esto llega a pasar se utilizan reunionesde planificación de liberación para volver a estimar y negociar el“Plan de Lanzamiento”.

El problema con cualquier proyecto es la estimación inicial. Larecopilación de un montón de detalles no hace que su estimaciónno sea una conjetura inicial correcta. Hay que preocuparse porestimar el alcance general del proyecto y conseguir que laderecha en vez de la creación de documentos de gran tamaño.

Administración(Project Velocity)

Este punto hace referencia a los siguientes aspectos:

• Evita pérdida de conocimiento

• Evita que se hagan “cuellos de botella”(en lo que refiere a tener problemas a la creación delcódigo en etapas posteriores )

• Cross Training: es una práctica que las empresas deben evitar ya que trae comoconsecuencia pérdida de información.

• Equipos de trabajo Flexibles: quiere decir que cada una de las personas que participanen la creación deben conocer que se hace en cada una de las partes del sistema, ya que asiestaran involucrados en un mayor porcentaje, como consecuencia todo el equipo se vuelveproductivo.

• Pair Programming: requiere que dos programadores participen en un esfuerzocombinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otrono está haciendo actualmente y al término cambian de roles.

Siguiendo la prácticas anteriores se garantiza entre otras ventajas productividad y continuidad delproyecto a realizar.

Administración(Move People Around | Mover a la Gente)

Para determinar qué hacer es importante tener en cuentalas reglas de la Programación extrema a seguir.

Es importante saber qué hará cada miembro del equipopara tener claras las expectativas, es decir, saber quéesperar de cada rol.

Las reuniones ayudan a determinar que está funcionando yqué no y así poder mejorar el proceso de manera continua.

Administración(Fix XP When It Breaks | Determinar Cuando Ocurre Una Falla)

Diseño

Diseño

Simplicidad:

Un diseño simple siempre llevará menos tiempo paraterminarse que uno complejo.

Si encuentras algo complejo sustituyelo con undiseño simple.

Siempre es más rápido y barato reemplazar códigocomplejo antes de que gastes más tiempo en hacerlo.

Diseño simple. En cualquier momento el diseñoadecuado para el software es aquel que:

• Funciona con todas las pruebas.

• No tiene lógica duplicada. Una sola entrada de datos.

• Tiene el menor numero posible de clases y métodos.

El diseño sencillo es como eliminar cualquier elementodel diseño que se pueda sin violar las tres primerasreglas.

Diseño

Elige un System Metaphor (Metáfora de Sistema).

"The system metaphor is a story that everyone –customers, programmers, and managers - can tell abouthow the system works.“ Kent Beck, ExtremeProgramming Explained, p. 179.

Un System Metaphor es un diseño simple con algunascualidades.

Diseño

Lo mas importante es que siempre esté disponiblepara que gente nueva pueda entender el sistema sinla necesidad de revisar la documentación.

El diseño debe permitir que la gente pueda aportarde manera inmediata algunos cambio o mejoras.

Otra cualidad es que el diseño debe permitirconstruir clases y metodos consistentes.

Diseño

En la mayoría del software existe un Software Rot(Decaimiento del Software), este es causada por un diseñoinadecuado y limitados recursos del proyecto.

Es mejor hacer cambios en el código que modificar eldiseño ya que ésto provoca complicaciones dentro delproyecto.

Después de un tiempo nos damos cuenta de que la fijaciónde un error provoca varios errores incluso más sutiles (ycaros) que se produzcan y el costo de mantenimientoaumenta significativamente.

Diseño

Diseño(Diagrama de Flujo de la Etapa de Diseño)

Codificación

Es un requisito que el cliente siempre este disponible.

No solo será ayuda, debe formar parte del equipo de desarrolladores

Se usan:

• Historias de usuario

o escritas por el cliente con ayuda de desarrolladores

o permiten hacer estimaciones de tiempo y asignar prioridad

o se pretende asegurar la mayor parte de la funcionalidad deseadadel sistema

Codificación(Cliente Disponible)

• Reunión planificación de liberación

o el cliente tendrá que negociar las historias de usuario

• Reunión planificación de entregas

o define pequeñas versiones incrementales que se lemostrarán al cliente

Puesto que en los casos de uso se dejan detalles fuera, elcliente deberá trabajar con los desarrolladores para afinaresos detalles para que se complete la tarea deprogramación.

Codificación

Para que se libere la versión, el cliente deberá realizarPruebas Funcionales hasta que esté listo para serlanzado.

Esta etapa puede ser tediosa y llevarte mucho tiempopero debes recordar que no tuviste una etapa derequerimientos por lo que el tiempo que ahí ahorraste,en estas pruebas determinan que el sistema continúe enproducción o se detenga.

Codificación

El código debe tener el formato de estándares de codificación

acordados. Los estándares de codificación deben mantener el

código consistente y fácil para todo el equipo. para leer y

refactorización. El código que tiene el mismo aspecto.

-Mismo Aspecto

-Facil

-Entendible

Codificación(Estándar de Código)

Al crear primero sus pruebas resulta mucho más fácil y más rápido crear sucódigo. La creación de una unidad de prueba ayuda a un desarrollador aconsiderar realmente lo que hay que hacer, los requisitos se establecieronfinalmente y no puede haber ningún malentendido en las especificaciones(descritas en e el código ejecutable).

Hay un ritmo de desarrollo de software, para crear una prueba se deben dedefinir algunos pequeños del problema en cuestión, se crea el código que seejecutará en la prueba y entonces así se creará una segunda prueba.

El código que se crea debe de ser simple, y solo se deben de implementarlas características requeridas por el usuario. Mediante la creación depruebas el diseño se verá influido por el deseo de probar todo lo que sea devalor para su cliente.

Codificación(Prueba de la Primera Unidad)

XP define que todo el código generado debe ser creado pordos personas trabajando en una misma computadora.

La programación en pares incrementa la calidad de códigosin tener un impacto significativo en el tiempo de entrega.

• Esto va en contra del sentido común ya que se puede pensarque dos personas trabajando por separado pueden generarmas código en menos tiempo. Sin embargo, lassignificativas mejoras en la calidad hacen que laprogramación en pares desemboque en un gran ahorro detiempo en la corrección de errores.

Codificación(Programación en Pares)

La programación en pares es una habilidad social. Cadaparticipante de una pareja de programación debe ser capazde decir “Intentemos tu enfoque primero”. Esto no significaque la pareja deba entrar en una dinámica “estudiante-maestro”, es decir, ambos programadores deben aportarideas y no limitarse a escuchar.

Codificación(Programación en Pares)

Codificación(Programación en Pares)

Otra forma consiste en nombrar un integrador o un equipo deintegración. La integración de código de múltiples desarrolladoreses más que una sola persona puede manejar. Y un equipo depersonas es demasiado grande un recurso para integrar más de unavez al mes.

Muchos proyectos utilizan en una herramienta de repositorio decódigo fuente para controlar la integración. La mayoría de losrepositorios de código fuente parecen favorecer el desarrollo y laintegración secuencial paralelo. Es decir, que queden bloqueadosen un archivo para un solo desarrollador puede agregarfuncionalidad a la vez. Ellos permiten a cualquiera liberar encualquier momento, porque sobreescribe han sido controlados anivel de archivo individual.

Codificación(Integración Secuencial)

• La integración de código es un aspecto sumamenteimportante. De esta manera nos aseguramos que todo elequipo está trabajando sobre la misma versión delsistema.

• Debido a ello es necesario que cada pareja dedesarrolladores haga “commit” al repositorio cada que setermine una unidad funcional. Esto debe seraproximadamente una vez al día.

• La integración continua evita tener que integrar elproyecto completo al finalizar la codificación ahorrandouna cantidad significativa de tiempo.

Codificación(Seguir Integrando)

Un solo equipo dedicado a la liberación secuencial funciona muybien cuando el equipo de desarrollo es co-localizado. Este equipoactúa como una muestra física para controlar la liberación.

El ordenador permite a los desarrolladores para ver quién es laliberación y cuándo. Cuando el equipo de liberación está ocupadootros cambios pueden ser liberados, se garantiza la estabilidad.

El último conjunto de pruebas de unidad combinada se puedeejecutar antes de soltarla. Debido a que una sola computadora seutiliza el conjunto de pruebas está siempre al día. Si las pruebas deunidad funcionan a 100 % se confirman los cambios, si no logranlos cambios se depuran o se echaron atrás y depuradas en la propiaestación de trabajo a los desarrolladores.

Codificación(Configurar un Equipo de Integración Dedicado)

Propiedad colectiva anima a todos a contribuir con nuevas ideas para todos los segmentos del proyecto. Cualquier desarrollador puede :

cambiar línea de código para agregar funcionalidad, corregir los errores, mejorar los diseños

¿Cómo Funciona?La forma en que esto funciona es que cada desarrollador crear pruebas

unitarias para el código a medida que se desarrolla. Todo el código que se libera en el repositorio de código fuente incluye pruebas unitarias que funcionan al 100%.

En la práctica, la propiedad colectiva es en realidad más fiable que poneruna sola persona encargada de velar clases específicas. Sobre todoporque una persona puede dejar el proyecto

Codificación(Propiedad Colectiva)

Desarrollo ágil

Código unificado y entendible

Diferentes visiones acerca de la creación de código.

Soluciones con diferentes enfoques.

Codificación(Ventajas)

Pruebas

Permite aumentar la calidad de los sistemas reduciendo el número de errores no detectados y disminuyendo el tiempo transcurrido entre la aparición de un error y su detección

Tienen que verificar que su sistema se comporta de la manera esperada, por lo que podrían encajar dentro de la definición de pruebas unitarias que propone XP.

También permite aumentar la seguridad de evitar efectos colaterales no deseados a la hora de realizar modificaciones.

Pruebas(Objetivos)

Pruebas unitarias

Encargadas de verificar el código y automatizar la ejecución de las mismas y para documentar defectos en versiones previas del programa y no repetirlos.

Pruebas(Objetivos)

Pruebas Funcionales /Aceptación

Es una prueba formal conducida para determinar si un sistema satisface los criterios de aceptación y permite al cliente determinar si acepta o no el sistema.

Pruebas

La primer prueba es la más difícil.

El control que se lleva durante las pruebas es más valioso que el código.

Lo más difícil de las pruebas es ahorrar.

Siempre se deben de realizar las pruebas.

Las pruebas se deben realizar antes de comenzar con el código.

Pruebas(Conclusiones)