Ing. Manuel Alcántara Ramírez
Programación Extrema
Como surge XP
Creado por Kent Beck
En el proyecto C3 en Chrysler
Kent dirigió el proyecto
Durante el proceso nació esta nueva metodología: eXtreme
Programming (XP)
C3 concluyó exitosamente en 1997
3 UNTECS - Manuel Alcántara R.
¿Qué es XP?
Es una metodología ágil que se caracteriza por:
Estar diseñada para entornos dinámicos.
Es Flexible.
Es Predecible.
Para equipos pequeños (máximo 10 programadores).
Orientada fuertemente hacia la codificación.
Énfasis en la comunicación informal, verbal.
De bajo riesgo
4 UNTECS - Manuel Alcántara R.
Comparación Ciclos de vida
Tradicionales con el de XP
UNTECS - Manuel Alcántara R. 5
Características de XP Metodología creada a base de prueba y error.
Considera 4 valores que pueden mejorar cualquier proyecto de software: Simplicidad,
Comunicación,
Realimentación,
Coraje.
Expresada en forma de 12 prácticas (algunas ya existentes desde hace años), que se soportan las unas a las otras y conforman un conjunto completo.
6 UNTECS - Manuel Alcántara R.
Simplicidad
“Hacer que el sistema funcione lo mas simple posible”
“Mantener el sistema en la condición mas simple posible”.
En relación al proceso y la codificación, el principio es hacerlo
simple que pueda funcionar,
Es mejor hacer algo simple hoy, que hacerlo más complicado hoy y
probablemente nunca usarlo.
7 UNTECS - Manuel Alcántara R.
Comunicación
El cliente es parte del equipo de desarrollo.
Comunicación constante entre el equipo de gestión y el
equipo de desarrollo.
Comunicación constante entre desarrolladores.
XP hace casi imposible la falta de comunicación.
8 UNTECS - Manuel Alcántara R.
Retroalimentación Retroalimentación concreta y frecuente del cliente, del equipo y
de los usuarios finales da una mayor oportunidad de dirigir el
esfuerzo.
Testeo continuo a través de todo el proceso
Testeo como herramienta de especificación y desarrollo
Testeo como garantía de integridad del código frente a
cambios.
Velocidad, pero además calidad
9 UNTECS - Manuel Alcántara R.
Coraje Se requiere coraje para comunicarse con los demás
cuando eso podría exponer la propia ignorancia.
Se requiere coraje para mantener el sistema simple, dejando para mañana las decisiones de mañana.
Se requiere coraje para confiar en que la retroalimentación durante el camino es mejor que tratar de adivinar todo con anticipación.
Es difícil ser valeroso.
Se requiere coraje para enfrentar la reacción frente a los cambios
10 UNTECS - Manuel Alcántara R.
Proceso de desarrollo de software con XP
11 UNTECS - Manuel Alcántara R.
Proceso de Desarrollo de Software con XP
Prototipo
arquitectónico
Planificación de
entregas Iteración
Tests de
aceptación
Pequeñas
entregas
Historias de
usuario
Metáfora de
sistema
Prototipo
requerimientos
Estimación
incierta Estimación
confiable
Plan de entregas Versión mas
reciente
Aprobación del
cliente
Escenarios de testeo
Historias nuevas
Velocidad del proyecto
Próxima
iteración
bugs
12 UNTECS - Manuel Alcántara R.
Proceso de Desarrollo de Software con XP
13 UNTECS - Manuel Alcántara R.
Iteración
14 UNTECS - Manuel Alcántara R.
Iteración
Próxima
iteración
Planificación de
iteración Desarrollo
Versión mas
reciente
Velocidad de
proyecto
Plan de
iteración
Plan de entregas
Bugs
Historias de
usuario
Tests de
aceptación
fallados
Funcionalidades
nuevas
Corrección de bugs
Día a día
Historias nuevas,
Velocidad de proyecto
Aprender y
comunicar
15 UNTECS - Manuel Alcántara R.
Desarrollo
16 UNTECS - Manuel Alcántara R.
Desarrollo
Corrección de
bugs
Reunión de
pie
Manejo colectivo del
software
Próxima tarea o test de
aceptación fallido
Plan de iteración
Día a día
tareas
Tests de
aceptación
fallados
Tests de unidad
pasados al 100%
Test de
aceptación
aprobado
Tareas sin terminar
Demasiado por
hacer
Nueva
funcionalidad
Aprender y
comunicar
Programación en pares
Reconstrucción de código
17 UNTECS - Manuel Alcántara R.
Manejo colectivo del código
Próxima tarea o
test de
aceptación
Creación de
unidad de testeo Programación en
pares
100% de
unidades de
testeo pasados
Pares
Unidad de
testeo fallida
Mover Gente
Se necesita ayuda Cambio de
par
Unidad de
testeo aprobada
Código
simple Código
complejo
Reconstrucción
despiadada
Ejecutar
todas las
unidades
de testeo
Test de
aceptación
aprobado
Ejecutar test
de aceptación
fallados
18 UNTECS - Manuel Alcántara R.
Proceso de Desarrollo de Software con XP
19 UNTECS - Manuel Alcántara R.
Resumen de prácticas
Proceso de planificación
Entregas pequeñas
Metáfora del sistema
Diseño simple
Testeo
Reconstrucción
Programación en pares
Propiedad colectiva
Integración continua
Semana de 40 horas
Cliente siempre disponible
Estándares de codificación
20 UNTECS - Manuel Alcántara R.
Interacción entre las Prácticas
21 UNTECS - Manuel Alcántara R.
Roles en XP
Programador (Programmer)
Responsable de decisiones técnicas
Responsable de construir el sistema
Sin distinción entre analistas, diseñadores o codificadores
En XP, los programadores diseñan, programan y realizan las pruebas
22 UNTECS - Manuel Alcántara R.
Roles en XP
Jefe de Proyecto (Manager)
Organiza y guía las reuniones
Asegura condiciones adecuadas para el proyecto
Cliente (Customer)
Es parte del equipo
Determina qué construir y cuándo
Establece las pruebas funcionales
23 UNTECS - Manuel Alcántara R.
Roles en XP
Encargado de Pruebas (Tester)
Ayuda al cliente con las pruebas funcionales
Se asegura de que las pruebas funcionales se superen
Rastreador (Tracker)
Hace el seguimiento del proyecto.
Observa sin molestar.
Conserva datos históricos.
24 UNTECS - Manuel Alcántara R.
Roles en XP
Entrenador (Coach)
Responsable del proceso
Tiende a estar en un segundo plano a medida que el equipo madura
25 UNTECS - Manuel Alcántara R.
Artefactos esenciales en XP
Historias del Usuario
Tareas de Ingeniería
Pruebas de Aceptación
Pruebas Unitarias y de Integración
Plan de la Entrega
Código
26 UNTECS - Manuel Alcántara R.
Captura de Requisitos en XP
Se usan Historias del Usuario (User-
Stories)
Establecen los requisitos del cliente
Trozos de funcionalidad que aportan valor
Se les asignan tareas de programación con un nº de
horas de desarrollo.
Las establece el cliente.
Son la base para las pruebas funcionales.
27 UNTECS - Manuel Alcántara R.
Historias (Relatos) de Usuario Una Historia de usuario es un relato acerca de qué problema debe resolver el
sistema.
Cada relato se escribe en una tarjeta y representa una parte de la funcionalidad que es coherente para el cliente.
Son escritos por el cliente o usuario, con la ayuda de los desarrolladores, para permitir estimar los tiempos y asignar prioridades.
Los clientes ayudan a asegurar que la mayoría de la funcionalidad deseada para el sistema esté cubierta con las historias.
Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles.
No se debe hablar ni de posibles algoritmos para su implementación.
No se debe considerar los diseños de base de datos, etc.
28 UNTECS - Manuel Alcántara R.
Ejemplo de Historia de Usuario
Historia de Usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número: Iteración Asignada: 2
Prioridad en Negocio: Alta
(Alta / Media / Baja) Puntos Estimados:
Riesgo en Desarrollo:
(Alto / Medio / Bajo) : Alto Puntos Reales:
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un usuario y clave para que el autor pueda posteriormente acceder al artículo.
Spike para Historia de Usuario
30 UNTECS - Manuel Alcántara R.
Tarea de Ingeniería
Tarea
Número tarea: Número historia:
Nombre tarea:
Tipo de tarea :
Desarrollo / Corrección / Mejora / Otra Puntos estimados:
Fecha inicio: Fecha fin:
Programador responsable:
Descripción:
Prueba de Aceptación
Caso de Prueba
Número Caso de Prueba: Número Historia de Usuario:
Nombre Caso de Prueba:
Descripción:
Condiciones de ejecución:
Entradas:
Resultado esperado:
Evaluación:
Prá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 continua
• Semana de 40 horas
• Cliente in situ
• Estándares de programación
33 UNTECS - Manuel Alcántara R.
Escenarios en XP : Exploración
Historias de Usuario
Prioridad Riesgo
Esfuerzo (puntos)
Spikes (Bosquejos)
Definir Historias de Usuario
Elaborar Spikes
Estimar Esfuerzo y Riesgo
?
34 UNTECS - Manuel Alcántara R.
Escenarios en XP:
Planificación de la Entrega
Historias de Usuario
Primera Iteración
Segunda Iteración
Última Iteración
…
N-ésima Iteración
Historias fuera de la entrega
Velocidad de Proyecto (VP) puntos/semana
Entrega <= 3 meses
2 a 3 semanas
35 UNTECS - Manuel Alcántara R.
Escenarios en XP : Comenzar Iteración
Historias de la Iteración
Definir y ordenar Tareas de Ingeniería
Tareas de la iteración
36 UNTECS - Manuel Alcántara R.
Escenarios en XP : Programación
Pruebas de Aceptación de Historias de la iteración
Programación en Parejas
Tareas de Historias de la iteración
Historias de la Iteración
Versión del Producto
Diseño
Refactoring
Programación
Pruebas Unitarias
Integración
Pruebas de Integración
Pruebas de Aceptación
37 UNTECS - Manuel Alcántara R.
Escenarios en XP : Pruebas de Aceptación
Pruebas de Aceptación
Definir Pruebas de Aceptación
Aplicar Pruebas de Aceptación
Corregir errores Definir nuevas Historias
38 UNTECS - Manuel Alcántara R.
Entorno y clima de trabajo
Espacio de trabajo XP
Espacio abierto
Mesas centrales
Cubículos en el espacio exterior
Espacio de trabajo
del proyecto C3 de
DaimlerChrysler
39 UNTECS - Manuel Alcántara R.
Reunión diaria: “Stand-up Meeting”
Todo el equipo
Problemas
Soluciones
De pie en un círculo
Evitar discusiones largas
Sin conversaciones separadas
… Entorno y clima de trabajo Reunión diaria XP
40 UNTECS - Manuel Alcántara R.
Entorno y clima de trabajo
Gantt de Pared
Obtenida de www.agiletek.com
“Centro del universo del proyecto”
“Punto de reunión para la “Stand-up Meeting”
41 UNTECS - Manuel Alcántara R.
XP en la práctica (i) Retroalimentación a escala fina: Desarrollo guiado por pruebas Planificación iterativa Cliente como parte del equipo Programación en pares
Proceso continuo: Integración continua Refactorización Liberación pequeña, entregas frecuentes
42 UNTECS - Manuel Alcántara R.
XP en la práctica (ii)
Entendimiento compartido: Diseño simple
Metáforas del sistema
Propiedad colectiva del código
Estándares de codificación
Bienestar del programador:
Ritmo sostenible (Semanas de 40 horas)
43 UNTECS - Manuel Alcántara R.
Diseño simple
El diseño debe ser lo más simple posible: no introducir
estructura, ni funcionalidad antes de tiempo.
Se puede añadir complejidad más adelante.
Inconveniente: Vencer la tendencia al “gran diseño previo”
44 UNTECS - Manuel Alcántara R.
Pruebas automatizadas (i) Todo código que puede fallar debe tener una prueba.
Hacer la prueba aún antes de la implementación.
Inconveniente: Obliga a imponer una forma de trabajar y puede ser necesaria formación/experiencia.
Dos tipos: Prueba de Unidad (o del Programador) y Prueba de Aceptación (o Funcional, o del Cliente).
La Prueba de 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.
45 UNTECS - Manuel Alcántara R.
Pruebas automatizadas (ii) Para cada lenguaje de programación hay herramientas de Prueba
de Unidad que permiten automatizar la ejecución de las mismas, como JUnit para Java. (ver http://www.xprogramming.com/software.htm)
Frecuentemente una Prueba de Unidad es mejor que un comentario para ayudar a entender por qué una determinada función es necesaria, para demostrar cómo es llamada una función y cuales son los resultados esperados, y para documentar defectos en versiones previas del programa que queremos asegurarnos de que no vuelvan.
46 UNTECS - Manuel Alcántara R.
Integración continua Todos los cambios deben ser integrados a la base del
código al menos diariamente.
Las pruebas deben correr al 100% antes y después de la integración.
Cada nueva versión debe tener la mínima funcionalidad extra que tiene sentido.
Encaja con “release early, release often”
Ventajas: tener realimentación de los usuarios y ofrecer pronto nueva funcionalidad (+éxito).
47 UNTECS - Manuel Alcántara R.
Programación en pares
La Programación en Pares requiere que dos desarrolladores participen en un proyecto en una misma estación de trabajo.
Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento: Mientras uno redacta Pruebas de Unidad el otro piensa acerca de la clase que satisfará a dicha prueba, por ejemplo.
Los estudios demuestran que, tras aprender Habilidades Personales dos programadores son más que doblemente productivos que uno sólo para una tarea determinada.
48 UNTECS - Manuel Alcántara R.
Refactorización (i)
Es una técnica disciplinada de reestructurar cualquier código existente, alterando su estructura interna sin modificar su comportamiento externo.
¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?
49 UNTECS - Manuel Alcántara R.
Refactorización (ii)
Si un programa funciona pero está mal diseñado, pronto surgirán problemas a la hora de actualizarlo. Los problemas más comunes pueden ser catalogados como “olor de código” (ya que la acumulación de los mismos provocan que el código apeste).
Existen listas de refactorizaciones. Ejemplo:
Add Parameter
A method needs more information from its caller.
Add a parameter for an object that can pass on this information.
50 UNTECS - Manuel Alcántara R.
Últimas ideas… El método de desarrollo empleado por la programación extrema y el que suele
llevarse a cabo en la generación de Software Libre tienen grandes parecidos.
Hay algunas prácticas de la programación extrema que no se usan de manera mayoritaria (pruebas de unidad y de aceptación, metáfora y refactorización) y que son muy interesantes y provechosas.
XP y bases de datos: cuidar que tanto BDs relacionales como orientadas al objeto sean flexibles, de manera de migrar fácilmente los datos en caso de cambios.
En cuanto al lanzamiento de cada mini-versión, usar una estación de integración que permite a los desarrolladores observar quién y cuándo se está realizando, manteniendo estabilidad en el sistema.
51 UNTECS - Manuel Alcántara R.
Referencias http://www.extremeprogramming.org/
http://www.programacionextrema.org/
http://www.jera.com/techinfo/xpfaq.html
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
http://clabs.org/caseforxp.htm
http://ootips.org/xp.html
http://www.bobjectsinc.com/cstug/xpslides/
http://www.xp123.com/
http://c2.com/cgi/wiki?XpGlossary
52 UNTECS - Manuel Alcántara R.
Conclusiones
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la
experiencia práctica
53 UNTECS - Manuel Alcántara R.
Referencias K. Beck, “Embracing change with Extreme Programing”, Computer, Vol. 32, No. 5 Oct.
1999, pp 70-77
L. Williams, R. Kessler, W. Cunningham and R. Jeffries, “Strenghthening the Case for Pair Programing”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp 19-25
R. Martin, “Extreme Programing Development through dialog”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp 12-13
C3 Team, “Chrysler goes to “Extremes”, Distributed Computing, Oct 1998, pp 24-28
http://www.xprogramming.com
http://www.extremeprogramming.org
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
54 UNTECS - Manuel Alcántara R.
Top Related