Extreme Programming

5/14/2018 Extreme Programming - slidepdf.com

http://slidepdf.com/reader/full/extreme-programming-55a92d7595a64 1/31

Programación Extrema

Extreme Programming (XP)Patricio [email protected]

Departamento de Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia



2

www.dsic.upv.es/~letelier

Contenidos

Introducción

RolesCaptura y especificación de requisitosPlanificaciónProgramaciónPrácticas XP



3


¿Qué es XP?

Es una metodología ágil Diseñada para entornos dinámicos

Pensada para equipos pequeños (hasta 10programadores) Orientada fuertemente hacia la codificación

Énfasis en la comunicación informal, verbal



4


Historia de XP

Creado por Kent Beck para la plantilladel proyecto C3 en Chrysler Kent fue contratado para dirigir el proyecto Durante el proceso nació una nueva

metodología: eXtreme Programming (XP) C3 concluyó exitosamente en 1997



5


Valores que fomenta XP

Comunicación

SimplicidadRetroalimentación

Coraje



6


Roles XPc2.com/cgi/wiki?ExtremeRoles

Programador (Programmer)

Responsable de decisionestécnicas

Responsable de construir elsistema

Sin distinción entre analistas,diseñadores o programadores

En XP, los programadoresdiseñan, programan y realizan las

pruebas

Jefe de Proyecto(Manager)

Organiza y guía lasreuniones

Asegura condicionesadecuadas para elproyecto

Cliente (Customer)

Es parte del equipo Determina qué construiry cuándo

Establece las pruebas deaceptación

http://c2.com/cgi/wiki?ExtremeRoles

http://c2.com/cgi/wiki?ExtremeRoles



7


... Roles XP

Entrenador (Coach)

Responsable del proceso Tiende a estar en un

segundo plano a medidaque el equipo madura

Encargado dePruebas (Tester )

Ayuda al cliente con laspruebas de aceptación

Se asegura de que laspruebas aceptación sesuperan

Rastreador (Tracker )

Metric Man

Observa sin molestar Conserva datos

históricos



8


Captura de Requisitos en XP

Historias del Usuario (User-Stories )

Establecen los requisitos del cliente

Las establece el cliente Son la base para las pruebas de aceptación Se caracterizan por prioridad, riesgo y

esfuerzo



9


Captura de Requisitos en XPUna ficha de Historia de Usuario



10


Planificación en XP

Planificación por entregas (releases )Las Historias de Usuario se priorizan por el clienteseleccionando aquellas más importantes para el

negocioEntregas: Son lo más pequeñas posibles

Se dividen en iteraciones (iteración = 2 o 3 semanas) Cada iteración está compuesta por historias de usuario



11


Programación en XP

Cada Historia de Usuario se descompone entareas de programación

La programación de tareas se realiza por parejas

La pareja diseña, prueba, implementa e integra elcódigo de la tarea

Código dirigido por las pruebasCódigo modular, intentando refactorizar siempreque se pueda



12


Programación en XPUna ficha de Tarea



13


Modelo de un Proyecto XP



14


Espacio de trabajo XP

Espacio abiertoMesas centralesCubículos en el espacio exterior

Espacio de trabajo

del proyecto C3 de

DaimlerChrysler



15


Prácticas XP

• El juego de laplanificación

• Entregas pequeñas• Metáfora

• Diseño simple

• Pruebas• Refactoring

• Programación enparejas

•

Propiedad colectiva• Integración contínua

• Semana de 40 horas

• Cliente in situ• Estándares de

programación



16


Prácticas XPEl Juego de la planificación

Decisiones de negocio (cliente): Alcance ¿Cuándo debe estar listo el producto para

que sea valioso en producción? Prioridad Prioriza la incorporación de las Historias

de Usuario Composición de entregas ¿Qué se necesita para

que el negocio mejore? Fechas de entrega Fechas cuando el software en

operación causaría una gran diferencia



17


Prácticas XP... El Juego de la planificación

Decisiones técnicas (programadores y otros): Estimaciones ¿Cuánto tiempo tardará en

implementarse una Historia de Usuario? Consecuencias Tener en cuenta las consecuencias

técnicas de determinadas decisiones de negocio Proceso Organización del proceso y el equipo

Planificación detallada

Dentro de una entrega, quéHistorias de Usuarioi se realizan primero. Intentar trasladarlos segmentos de desarrollo más arriesgados al principio,intentando respetar las prioridades del negocio



18


Reunión diaria “Stand-up Meeting”

Todo el equipo Problemas Soluciones

De pie en un círculo Evitar discusiones largas Sin conversaciones separadas

Prácticas XP... El Juego de la planificación

Reunión diaria XP



19


Cada entrega es lo más corta posible: Incluir requisitos más valiosos del sistema

(básicos) Reducir el riesgo mayor retroalimentación

desde el cliente, y más frecuente

Minimizar el nº de Historias de Usuario que

componen una entrega No realizarHistorias de Usuario a medias

Prácticas XPEntregas pequeñas



20


Cada proyecto XP es guiado por unametáfora global

Da un contexto al equipo para entender loselementos básicos y sus relaciones

Proporciona integridad conceptual

Prácticas XPMetáfora



21


Se diseña “la cosa más simple que pueda

funcionar”

Uso de tarjetas CRCDiseño de software correcto, es aquel que: Supera todas las pruebas No tiene lógica duplicada Pone de manifiesto las intenciones importantes de

los programadores Tiene el mínimo número de clases y métodos

Prácticas XPDiseño simple



22


Las pruebas unitarias se escriben ANTESque el código

Pruebas automatizadasPermiten el desarrollo de proyectos de formarápida y seguraPruebas unitarias programadores

Pruebas de aceptación clienteResultado Un programa cada vez másseguro

Prácticas XPPruebas



23


Refactorización = Mejora de la arquitectura

sin cambiar el comportamiento del sistemaIntentar eliminar complejidad

Código duplicado Refactorización

Se plantea su aplicación antes de enfrentaruna Historia de Usuario/Tarea

Prácticas XPRefactoring

www.refactoring.com

http://www.refactoring.com/




24








25


Toda el código se escribe en parejas Se produce código de mayor calidad

Extiende el conocimiento

“Se realiza el trabajo de 1 persona en casi la

mitad del tiempo y mejor” (cuestionable)

Prácticas XPProgramación en parejas

www.pairprogramming.com













http://www.pairprogramming.com/




26


Cualquiera puede modificar el código encualquier momento Se evitan cuellos de

botella en la codificaciónTodos asume las responsabilidades sobre elconjunto del sistema

Todos conocen algo sobre todas las partes yconocen muy bien aquéllas en las que trabajan

Prácticas XPPropiedad colectiva

















27


El código se integra y se prueba después depocas horas

Existe una ordenador dedicado para laintegración

Cada pareja integra su código en dichoordenador

Prácticas XPIntegración contínua














28


Filosofía: “Los programadores que descansan

son más productivos”

El exceso de trabajo es un serio problema enun proyecto

La gente está más fresca y tiene mejores ideas

Prácticas XPSemana de 40 horas













29


Cliente real = Aquel que usará el sistemacuando esté en producción

El cliente real debe estar con el equipo detrabajo: Responder preguntas Resolver disputas Establecer prioridades Discutir mejoras

Prácticas XPCliente in situ




















30


Son fundamentales cuando los programadorescambian de pareja o hacen refactoring del

código de otros

Se consigue un código con el mismo estilo,homogéneo, legible

Prácticas XPEstándares de programación

P á ti XP
















31

Prácticas XPInteracción entre Prácticas

XP: Kent Beck





Extreme Programming

Documents

Transcript of Extreme Programming