UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN Licenciatura en Informática Programación extrema 26 de Febrero de 2018 Grupo 2692
Historia Es creada por Kent Beck en el año de 1996. Ésta metodología se desarrolló en Chrysler Corporation mientras se realizaba una aplicación de nóminas. Pone más énfasis en la adaptabilidad que en la previsibilidad los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural.
Beck se dio cuenta que los procesos deberían de ser flexibles y rá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. Es el más destacado de los procesos ágiles de desarrollo de software.
Objetivos Crear un método que hiciera que los desarrollos fueran más sencillos. Potenciar el trabajo en grupo, involucrando a todos en el desarrollo del Software.
El objetivo principal de XP es la satisfacción del cliente, por tanto la agilidad para responder las necesidades de él , es de vital importancia. Establecer las mejores prácticas de Ingeniería de SW en el desarrollo del proyecto.
Mejorar la productividad de los proyectos. Garantizar la calidad del SW, haciendo que éste supere las expectativas del cliente.
Lograr un equilibrio entre valores personales y corporativos Simplicidad Se busca trabajar únicamente en lo que el cliente pide sin agregados. Comunicación El trabajo se realiza de manera conjunta, expresando todas las dudas y resolviéndolas en equipo. Retroalimentación Estrechar la comunicación con el usuario con el fin de atender todas las inquietudes del mismo para encontrar y corregir errores.
Respeto Tratar de manera justa respeto a todos y cada uno de los integrantes del equipo. Coraje Planificar el trabajo para entregarlo en tiempo y forma, comunicando los avances con el usuario con honestidad.
Roles en programación extrema 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 Tracker: Encargado de seguimiento.
Entrenador (coach): Guía a los miembros del equipo para seguir el proceso correctamente. Consultor: Miembro externo con conocimiento especifico de un tema necesario para el proyecto. Gestor (Big Boss): Dueño y es el vinculo entre cliente y programadores
Reglas Planificación: Se realizan entregas frecuentes y el proyecto se divide en iteraciones Administración: Se hace un espacio de trabajo y se divide el tiempo Diseño: Se realizan cambios en el código en lugar de modificar el diseño así la empresa ahorra costos.
Codificación: Todo el código de producción será programado e integrarlo a menudo, se debe configurar un equipo dedicado a esta integración. Pruebas: Todo el código debe pasar todas las pruebas unitarias antes de que pueda ser liberado. Cuando se encuentra un error se crean pruebas. Las pruebas de aceptación se ejecutan a menudo y la puntuación se publica.
F A S E S
Planeación Negociación Durante la planeación se debe llegar a un acuerdo entre los clientes y el equipo de trabajo para definir los tiempos de entrega de cada iteración. Es importante mantener una buena planeación para cumplir con todos los requerimientos, los cuales deberá definir el cliente y poder cumplir la organización en tiempo y forma. Aspectos fundamentales Costo Calidad Tiempo
CALIDAD Incluye los procesos y actividades de la organización que determinan las responsabilidades, objetivos y las políticas de control para lograr la satisfacción del cliente y el cumplimiento de cada requerimiento. TIEMPO Consiste en el adecuado reparto de responsabilidades y objetivos partiendo desde el desarrollo individual hasta la conjunción del proyecto por parte del equipo de trabajo. Es fundamental una correcta administración del tiempo pues con esto se logrará una mayor productividad. COSTO Deberá definirse el costo tomando en cuenta los recursos humanos, materiales y tecnológicos para construir cada una de las iteraciones; También deberá tomarse en cuenta el valor promedio de cada una para evitar sugerencias presupuestarias irreales.
Aspectos fundamentales Costo Calidad Tiempo
Historia de usuario Sirven para describir la funcionalidad que debe tener el producto, usualmente suelen ser puntos específicos que tienen cierta prioridad dentro del desarrollo del sistema.
Tarea de ingeniería Sirven para llevar un seguimiento a las historias (desarrollo, corrección, mejora, etc.)
Tarjetas CRC En la parte superior, el nombre de la clase. Las responsabilidades de dicha clase. Son sus objetivos, a alto nivel. A la derecha de las responsabilidades, los colaboradores, que son otras clases que ayudan a conseguir cumplir a esta con sus responsabilidades.
PROCESOS El programador construye el valor de negocio El cliente definirá los requerimientos del negocio El programador estima el esfuerzo para cada iteración Iteración terminada El cliente ordena y prioriza la construcción de acuerdo a sus restricciones de tiempo El programador construye el valor de negocio
ADMINISTRACIÓN Workspace La comunicación crea sentido de equipo y logra colaboración efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos. Hay diversos factores que pueden ayudar a ello:
Computadoras Habrá que colocar los equipos en un área central que no pertenezca a nadie para programar en pares, así como también algunos alrededor en caso de que se requiera trabajar solos.
Pizarra de trabajo Tarjetas de información El tablero es un radiador de información, difunde el estado actual de la iteración (actualizado en la reunión diaria de sincronización ) Tarjetas de información Donde cada tarjeta representa una tarea.
Daily Stand Up Meeting | Reuniones Diarias de Trabajo Consiste en: Reuniones de encuentro cada mañana con el equipo Todo el mundo se pone de pie en un círculo para evitar largas discusiones Todo el equipo conocen las necesidades y las contribuciones de todos.
Aspectos a reportar: Lo que se realizó previamente (un día antes) Lo que se piensa realizar ese mismo día Retrasos detectados y problemas que estos ocasionan
Ventajas Reuniones pequeñas y más eficientes con todos los desarrolladores Permite medir la velocidad del proyecto con base en los casos de uso de la primera iteración Al permitir a los desarrolladores elegir nuevas historias, la velocidad aumenta
Velocidad detallada Reuniones para volver a estimar y negociar el “Plan de lanzamiento” Estimar alcance general
Move People Around | Mover a la Gente. Pair Programming Evitar Cross Training. Equipos de trabajo Flexibles Siguiendo la prácticas anteriores se garantiza entre otras ventajas productividad y continuidad del proyecto a realizar.
(Fix XP When It Breaks | Determinar Cuando Ocurre Una Falla) Seguir las reglas de XP es fundamental, pero no dude en cambiar lo que no funciona. Esto no significa que el equipo pueda hacer lo que quiera. Las reglas se deben seguir hasta que el equipo las haya cambiado. Todos sus desarrolladores deben saber exactamente qué esperar el uno del otro, tener un conjunto de reglas es la única forma de establecer estas expectativas.
Diseño Simplicidad: Consiste en ahorrar tiempo y así evitar las complejidades del diseño. Características de un software adecuado: Funcionalidad de todas las pruebas Una sola entrada de datos Clases y métodos necesarias
Metáfora de Sistema Tipo de diseño simple Todos los integrantes tienen conocimiento del sistema Fácil entendimiento y aportación de mejoras sin necesidad de documentación Permite construir clases y métodos consistentes
Software Rot Diseño inadecuado y limitado de recursos del proyecto Modificaciones dentro del código Provoca errores sutiles y aumenta el costo de mantenimiento
Diagrama de flujo de la etapa del diseño
Codificación ¿Qué se requiere? Que el cliente siempre esté disponible ya que debe formar parte del equipo de desarrolladores para afinar los detalles en la programación. Historias de usuario para hacer estimaciones de tiempo, prioridades y asegurar la funcionalidad del sistema. Reunión de planificación de liberación para negociar las historias de usuario Reunión de planificación de entregas para mostrarle al cliente las versiones.
Prueba de la primera unidad Es mucho más fácil crear las pruebas al inicio para evitar errores al codificar, pues considera lo importante y evita malos entendidos en las especificaciones . Se crea solo el código que se ejecutará en prueba para después hacer la segunda, el código solo debe implementar lo requerido por el usuario
Estándar de código Para que se libere la versión, el cliente deberá realizar Pruebas funcionales No tuviste una etapa de requerimientos por lo que el tiempo que ahí ahorraste, en estas pruebas determinan que el sistema continúe en producción o se detenga. 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. Mismo Aspecto Fácil -Entendible
Programación en pares Todo el código debe ser creado por dos personas en la misma computadora. Esto incrementará la calidad del código sin impacto en el tiempo, pues aunque se crea que tardará más disminuye el tiempo en corregir errores. La programación en pares es una habilidad social. Cada participante de programación debe ser capaz de decir “Intentemos tu idea primero”. Ambos programadores deben aportar ideas. Y no limitarse a escuchar.
Programación en pares Se solicita ayuda. Unidad de prueba fallida. Se realiza cambio de pareja. Código complejo. Nueva Unidad de Prueba.
Integración secuencial Ayuda a saber si todos los integrantes del equipo están trabajando en la misma versión del sistema. Evita tener que integrar el proyecto completo al finalizar la codificación. Utiliza un repositorio de código fuente. Posee un equipo de integración de código.
Configurar un Equipo de Integración Dedicado El equipo dedicado a la liberación secuencial actúa cuando el equipo de desarrollo es co-localizado, y este actúa como una muestra física para controlar la liberación. El ordenador permite a los desarrolladores ver quién es la liberación y cuándo.
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? Cada desarrollador crear pruebas unitarias para el código a medida que se desarrolla.
Propiedad colectiva Desarrollo ágil Código unificado y entendible Diferentes visiones acerca de la creación de código. Soluciones con diferentes enfoques.
Pruebas Objetivos Aumenta la calidad reduciendo los errores y el tiempo transcurrido entre la aparición y detección. Verificar que el sistema se comporta de la manera esperada. Aumenta la seguridad de evitar efectos colaterales a la hora de realizar modificaciones.
Pruebas Unitarias Encargadas de verificar el código. Automatizar la ejecución. Documentar defectos en versiones previas del programa. Evitar redundancia.
Pruebas Funcionales /Aceptación Determinar si un sistema satisface los criterios de aceptación. Determinar si acepta o no el sistema.
Conclusiones 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.