seminario metodologías ágiles y xp, tema 3 extreme programming
TRANSCRIPT
12/02/200212/02/2002 1
www.dsic.upv.es/~letelier
Programación ExtremaProgramación ExtremaExtreme Programming (XP)Extreme Programming (XP)
Pablo [email protected]
Facultad de ingieneria y negocios
Universidad de ciencias de la informatica
12/02/200212/02/2002 22 2
www.dsic.upv.es/~letelier
ContenidosContenidos
– IntroducciónIntroducción– RolesRoles– Captura y especificación de Captura y especificación de
requisitosrequisitos– PlanificaciónPlanificación– ProgramaciónProgramación– Prácticas XPPrácticas XP
12/02/200212/02/2002 33 3
www.dsic.upv.es/~letelier
¿Qué es XP? ¿Qué es XP?
Es una metodología ágilEs una metodología ágil– Diseñada para entornos dinámicosDiseñada para entornos dinámicos– Pensada para equipos pequeños (hasta Pensada para equipos pequeños (hasta
10 programadores)10 programadores)– Orientada fuertemente hacia la Orientada fuertemente hacia la
codificacióncodificación– Énfasis en la comunicación informal, Énfasis en la comunicación informal,
verbalverbal
12/02/200212/02/2002 44 4
www.dsic.upv.es/~letelier
Historia de XPHistoria de XP
Creado por Kent Beck para la Creado por Kent Beck para la plantilla del proyecto C3 en Chryslerplantilla del proyecto C3 en Chrysler– Kent fue contratado para dirigir el Kent fue contratado para dirigir el
proyectoproyecto– Durante el proceso nació una nueva Durante el proceso nació una nueva
metodología: eXtreme Programming metodología: eXtreme Programming (XP)(XP)
– C3 concluyó exitosamente en 1997 C3 concluyó exitosamente en 1997
12/02/200212/02/2002 55 5
www.dsic.upv.es/~letelier
Valores que fomenta XPValores que fomenta XP
ComunicaciónComunicación
SimplicidadSimplicidad
RetroalimentaciónRetroalimentación
CorajeCoraje
12/02/200212/02/2002 66 6
www.dsic.upv.es/~letelier
Roles XPRoles XP c2.c2.comcom//cgicgi//wiki?ExtremeRoleswiki?ExtremeRoles
Programador Programador (Programmer)(Programmer)
– Responsable de decisiones Responsable de decisiones técnicastécnicas
– Responsable de construir el Responsable de construir el sistemasistema
– Sin distinción entre analistas, Sin distinción entre analistas, diseñadores o programadoresdiseñadores o programadores
– En XP, los programadores En XP, los programadores diseñan, programan y diseñan, programan y realizan las pruebasrealizan las pruebas
Jefe de ProyectoJefe de Proyecto (Manager)(Manager)– Organiza y guía las Organiza y guía las
reunionesreuniones– Asegura condiciones Asegura condiciones
adecuadas para el adecuadas para el proyectoproyecto
ClienteCliente (Customer)(Customer)
– Es parte del equipoEs parte del equipo– Determina qué construir Determina qué construir
y cuándoy cuándo– Establece las pruebas de Establece las pruebas de
aceptación aceptación
12/02/200212/02/2002 77 7
www.dsic.upv.es/~letelier
... Roles XP... Roles XP
EntrenadorEntrenador (Coach)(Coach)– Responsable del Responsable del
procesoproceso– Tiende a estar en un Tiende a estar en un
segundo plano a segundo plano a medida que el equipo medida que el equipo maduramadura
Encargado de Encargado de PruebasPruebas ((TesterTester) )
– Ayuda al cliente con Ayuda al cliente con las pruebas de las pruebas de aceptaciónaceptación
– Se asegura de que las Se asegura de que las pruebas aceptación se pruebas aceptación se superansuperan
Rastreador Rastreador ((TrackerTracker))
– Metric ManMetric Man– Observa sin molestarObserva sin molestar– Conserva datos Conserva datos
históricoshistóricos
12/02/200212/02/2002 88 8
www.dsic.upv.es/~letelier
Captura de Requisitos en XPCaptura de Requisitos en XP
Historias del Usuario (Historias del Usuario (User-StoriesUser-Stories))– Establecen los requisitos del cliente Establecen los requisitos del cliente – Las establece el clienteLas establece el cliente– Son la base para las pruebas de Son la base para las pruebas de
aceptaciónaceptación– Se caracterizan por prioridad, riesgo y Se caracterizan por prioridad, riesgo y
esfuerzo esfuerzo
12/02/200212/02/2002 99 9
www.dsic.upv.es/~letelier
Captura de Requisitos en XPCaptura de Requisitos en XPUna ficha de Historia de UsuarioUna ficha de Historia de Usuario
12/02/200212/02/2002 1010 10
www.dsic.upv.es/~letelier
Planificación en XPPlanificación en XP
Planificación por entregas (Planificación por entregas (releasesreleases))
Las Historias de Usuario se priorizan por el Las Historias de Usuario se priorizan por el cliente seleccionando aquellas más cliente seleccionando aquellas más importantes para el negocioimportantes para el negocio
Entregas:Entregas:– Son lo más pequeñas posiblesSon lo más pequeñas posibles– Se dividen en iteraciones (iteración = 2 o 3 Se dividen en iteraciones (iteración = 2 o 3
semanas)semanas)– Cada iteración está compuesta por historias de Cada iteración está compuesta por historias de
usuariousuario
12/02/200212/02/2002 1111 11
www.dsic.upv.es/~letelier
Programación en XPProgramación en XP
Cada Historia de Usuario se descompone en Cada Historia de Usuario se descompone en tareas de programacióntareas de programación
La programación de tareas se realiza por La programación de tareas se realiza por parejasparejas
La pareja diseña, prueba, implementa e La pareja diseña, prueba, implementa e integra el código de la tareaintegra el código de la tarea
Código dirigido por las pruebasCódigo dirigido por las pruebas
Código modular, intentando refactorizar Código modular, intentando refactorizar siempre que se puedasiempre que se pueda
12/02/200212/02/2002 1212 12
www.dsic.upv.es/~letelier
Programación en XP Programación en XP Una ficha de TareaUna ficha de Tarea
12/02/200212/02/2002 1313 13
www.dsic.upv.es/~letelier
Modelo de un Proyecto XPModelo de un Proyecto XP
12/02/200212/02/2002 1414 14
www.dsic.upv.es/~letelier
Espacio de trabajo XPEspacio de trabajo XP
Espacio abiertoEspacio abierto
Mesas centralesMesas centrales
Cubículos en el espacio exteriorCubículos en el espacio exterior
Espacio de trabajo del proyecto C3 de DaimlerChrysler
12/02/200212/02/2002 1515 15
www.dsic.upv.es/~letelier
Prácticas XPPrácticas XP
• El juego de la planificación
• Entregas pequeñas
• Metáfora• Diseño simple • Pruebas• Refactoring
• Programación en parejas
• Propiedad colectiva
• Integración contínua
• Semana de 40 horas
• Cliente in situ
• Estándares de programación
12/02/200212/02/2002 1616 16
www.dsic.upv.es/~letelier
Prácticas XPPrácticas XPEl Juego de la planificaciónEl Juego de la planificación
Decisiones de negocio (cliente):Decisiones de negocio (cliente):– AlcanceAlcance ¿Cuándo debe estar listo el ¿Cuándo debe estar listo el
producto para que sea valioso en producción?producto para que sea valioso en producción?– PrioridadPrioridad Prioriza la incorporación de las Prioriza la incorporación de las
Historias de UsuarioHistorias de Usuario– Composición de entregasComposición de entregas ¿Qué se necesita ¿Qué se necesita
para que el negocio mejore?para que el negocio mejore?– Fechas de entregaFechas de entrega Fechas cuando el Fechas cuando el
software en operación causaría una gran software en operación causaría una gran diferenciadiferencia
12/02/200212/02/2002 1717 17
www.dsic.upv.es/~letelier
Prácticas XPPrácticas XP... ... El Juego de la planificaciónEl Juego de la planificación
Decisiones técnicas (programadores y otros):Decisiones técnicas (programadores y otros):– EstimacionesEstimaciones ¿Cuánto tiempo tardará en ¿Cuánto tiempo tardará en
implementarse una Historia de Usuario?implementarse una Historia de Usuario?– ConsecuenciasConsecuencias Tener en cuenta las Tener en cuenta las
consecuencias técnicas de determinadas decisiones consecuencias técnicas de determinadas decisiones de negociode negocio
– ProcesoProceso Organización del proceso y el equipo Organización del proceso y el equipo– Planificación detalladaPlanificación detallada Dentro de una Dentro de una
entrega, qué entrega, qué Historias de Usuarioi se realizan primero. Intentar Historias de Usuarioi se realizan primero. Intentar
trasladar los segmentos de desarrollo más trasladar los segmentos de desarrollo más arriesgados al principio, intentando respetar las arriesgados al principio, intentando respetar las prioridades del negocioprioridades del negocio
12/02/200212/02/2002 1818 18
www.dsic.upv.es/~letelier
Reunión diaria “Reunión diaria “Stand-up MeetingStand-up Meeting”” – Todo el equipoTodo el equipo
ProblemProblemasas
SolucionSolucioneses
– De pie en un círculoDe pie en un círculo Evitar discusiones largasEvitar discusiones largas
Sin conversaciones separadasSin conversaciones separadas
Prácticas XPPrácticas XP... ... El Juego de la planificaciónEl Juego de la planificación
Reunión diaria XPReunión diaria XP
12/02/200212/02/2002 1919 19
www.dsic.upv.es/~letelier
Cada entrega es lo más corta posible:Cada entrega es lo más corta posible:– Incluir requisitos más valiosos del sistema Incluir requisitos más valiosos del sistema
(básicos)(básicos)– Reducir el riesgo Reducir el riesgo mayor retroalimentación mayor retroalimentación
desde el cliente, y más frecuentedesde el cliente, y más frecuente
Minimizar el nº de Historias de Usuario que Minimizar el nº de Historias de Usuario que componen una entrega componen una entrega No realizar No realizar Historias de Usuario a mediasHistorias de Usuario a medias
Prácticas XPPrácticas XPEntregas pequeñasEntregas pequeñas
12/02/200212/02/2002 2020 20
www.dsic.upv.es/~letelier
Cada proyecto XP es guiado por una Cada proyecto XP es guiado por una metáfora globalmetáfora global
Da un contexto al equipo para entender Da un contexto al equipo para entender los elementos básicos y sus relacioneslos elementos básicos y sus relaciones
Proporciona integridad conceptualProporciona integridad conceptual
Prácticas XPPrácticas XPMetáforaMetáfora
12/02/200212/02/2002 2121 21
www.dsic.upv.es/~letelier
Se diseña “la cosa más simple que pueda Se diseña “la cosa más simple que pueda funcionar”funcionar”
Uso de tarjetas CRCUso de tarjetas CRC
Diseño de software correcto, es aquel que:Diseño de software correcto, es aquel que:– Supera todas las pruebasSupera todas las pruebas– No tiene lógica duplicadaNo tiene lógica duplicada– Pone de manifiesto las intenciones importantes Pone de manifiesto las intenciones importantes
de los programadoresde los programadores– Tiene el mínimo número de clases y métodosTiene el mínimo número de clases y métodos
Prácticas XPPrácticas XPDiseño simpleDiseño simple
12/02/200212/02/2002 2222 22
www.dsic.upv.es/~letelier
Las pruebas unitarias se escriben ANTES Las pruebas unitarias se escriben ANTES que el códigoque el códigoPruebas automatizadas Pruebas automatizadas Permiten el desarrollo de proyectos de Permiten el desarrollo de proyectos de forma rápida y seguraforma rápida y seguraPruebas unitarias Pruebas unitarias programadores programadoresPruebas de aceptación Pruebas de aceptación cliente clienteResultado Resultado Un programa cada vez más Un programa cada vez más seguroseguro
Prácticas XPPrácticas XPPruebasPruebas
12/02/200212/02/2002 2323 23
www.dsic.upv.es/~letelier
Refactorización = Mejora de la Refactorización = Mejora de la arquitectura sin cambiar el arquitectura sin cambiar el comportamiento del sistemacomportamiento del sistema
Intentar eliminar complejidad Intentar eliminar complejidad
Código duplicado Código duplicado Refactorización Refactorización
Se plantea su aplicación antes de Se plantea su aplicación antes de enfrentar una Historia de Usuario/Tareaenfrentar una Historia de Usuario/Tarea
Prácticas XPPrácticas XPRefactoringRefactoringwww.refactoring.comwww.refactoring.com
12/02/200212/02/2002 2424 24
www.dsic.upv.es/~letelier
Toda el código se escribe en parejasToda el código se escribe en parejas– Se produce código de mayor calidad Se produce código de mayor calidad
– Extiende el conocimientoExtiende el conocimiento
““Se realiza el trabajo de 1 persona en Se realiza el trabajo de 1 persona en casi la mitad del tiempo y mejor” casi la mitad del tiempo y mejor” (cuestionable)(cuestionable)
Prácticas XPPrácticas XPProgramación en parejasProgramación en parejas
www.pairprogramming.comwww.pairprogramming.com
12/02/200212/02/2002 2525 25
www.dsic.upv.es/~letelier
Cualquiera puede modificar el código en Cualquiera puede modificar el código en cualquier momento cualquier momento Se evitan cuellos Se evitan cuellos de botella en la codificaciónde botella en la codificación
Todos asume las responsabilidades sobre Todos asume las responsabilidades sobre el conjunto del sistemael conjunto del sistema
Todos conocen algo sobre todas las partes Todos conocen algo sobre todas las partes y conocen muy bien aquéllas en las que y conocen muy bien aquéllas en las que trabajantrabajan
Prácticas XPPrácticas XPPropiedad colectivaPropiedad colectiva
12/02/200212/02/2002 2626 26
www.dsic.upv.es/~letelier
El código se integra y se prueba El código se integra y se prueba después de pocas horasdespués de pocas horas
Existe una ordenador dedicado para la Existe una ordenador dedicado para la integraciónintegración
Cada pareja integra su código en dicho Cada pareja integra su código en dicho ordenadorordenador
Prácticas XPPrácticas XPIntegración contínuaIntegración contínua
12/02/200212/02/2002 2727 27
www.dsic.upv.es/~letelier
Filosofía: “Los programadores que Filosofía: “Los programadores que descansan son más productivos”descansan son más productivos”
El exceso de trabajo es un serio problema El exceso de trabajo es un serio problema en un proyectoen un proyecto
La gente está más fresca y tiene mejores La gente está más fresca y tiene mejores ideasideas
Prácticas XPPrácticas XPSemana de 40 horasSemana de 40 horas
12/02/200212/02/2002 2828 28
www.dsic.upv.es/~letelier
Cliente real = Aquel que usará el sistema Cliente real = Aquel que usará el sistema cuando esté en produccióncuando esté en producción
El cliente real debe estar con el equipo de El cliente real debe estar con el equipo de trabajo:trabajo:– Responder preguntasResponder preguntas– Resolver disputasResolver disputas– Establecer prioridadesEstablecer prioridades– Discutir mejorasDiscutir mejoras
Prácticas XPPrácticas XPCliente in situCliente in situ
12/02/200212/02/2002 2929 29
www.dsic.upv.es/~letelier
Son fundamentales cuando los Son fundamentales cuando los programadores cambian de pareja o programadores cambian de pareja o hacen hacen refactoringrefactoring del código de otros del código de otros
Se consigue un código con el mismo Se consigue un código con el mismo estilo, homogéneo, legibleestilo, homogéneo, legible
Prácticas XPPrácticas XPEstándares de programaciónEstándares de programación
12/02/200212/02/2002 3030 30
www.dsic.upv.es/~letelier
Prácticas XPPrácticas XPInteracción entre PrácticasInteracción entre Prácticas
XP: Kent Beck