Introduccion Programacion Extrema XP

Metodologia Agil basada en:

Aumento de
Fuerte
Comunicacion
productividad
con el cliente

Resultados Trabajos cortos y

Inmediatos poco complejos
CARACTERISTICAS

Testeo Continuo Software Funcional

Alta participacion del

Planificacion Flexible
cliente

Respuestas Rapidas Grupos de trabajo chicos

CICLO DE VIDA

Exploracion Planificacion

Produccion Iteracion
CICLO DE VIDA

Escuchar al Cliente
(Historias de Usuario)

Exploracion
Refinar Historias de Usuario
(Exploracion)

Entender lo pedido
(Familiarizarse con las
herramientas a usar)
CICLO DE VIDA

(Cronograma de Historias de Usuario)

Establecer Prioridades de las Historia de Usuario

Planificacion

Realizar una estimacion de esfuerzo

CICLO DE VIDA

Crear Version

Testeo

Chequeo
No Cumple
Iteracion Cumple
Siguiente Historia de Usuario
CICLO DE VIDA

Testeo Global del sistema

-Pruebas de rendimientos del cronograma

de historias de Usuario completado (Fase
de Iteraciones)
-Toma de desiciones con una
aproximación global del sistema

Produccion
Puesta en produccion en el cliente

Mantenimiento

-Implementacion de tareas de soporte del

Sistema entregado.
 Simplicity

Communication
VALORES Feedback
De la Programación Extrema

Courage

Respect
No hacer más que lo que sea absolutamente necesario.
Simplicity
Enfocarse en las necesidades de hoy.

Relación estrecha con el valor ‘Comunicación’.

La sencillez precisa que se haga refactoring de manera frecuente.

Se evita destinar mucho tiempo en el diseño contemplando un muchas variables futuras.

SENCILLEZ
 Communication
Apela a formas de comunicación menos complejas y formales que las
metodologías de desarrollo de software tradicionales.

Comunicación oral y frecuente (al menos, diaria).

Objetivo: generar y diseminar el conocimiento de la manera más rápida posible.

COMUNICACIÓN
 Sistema Feedback

Tests unitarios
Tests de integración.
Cliente

Tests funcionales (o de aceptación) escritos por el cliente y los testers.

Equipo

Cuando el cliente tiene nuevos requerimientos, el equipo da una estimación de manera directa,
acerca del tiempo de implementación.

RETROALIMENTACIÓN
 Courage
Varios de los valores implican coraje.

Por ejemplo, no hacer más que lo necesario, implica el coraje de saber que, más
adelante, será necesario refactorizar el código actual.

VALENTÍA
 Respect
El valor de respeto se refiere al respecto hacia a otros y hacia uno mismo.

Los programadores nunca deberían entregar código que rompan la compilación o

los tests.

Los miembros que tienen los 4 valores antes mencionados, obtienen el respeto de
todo el equipo.

RESPETO
ACTORES Y Programmer
RESPONSABILID
Customer
ADES
Coach
De la Programación Extrema

Tracker

Tester
 Responsable de decisiones técnicas
Programmer
 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

PROGRAMADOR
 Es parte del equipo
Customer
 Toma todas las decisiones comerciales relacionadas con el proyecto :

 Criterios de aceptación

 Presupuesto para el proyecto

 Características a incluir en las entregas

CLIENTE 
 Puede ser un consultor externo Coach
 Principal responsable del proceso

 Ayuda a orientar al equipo sobre las prácticas de XP y la autodisciplina

 Ayuda a evitar posibles errores que los nuevos equipos puedan cometer, lo que
agiliza el proyecto.

ENTRENADOR 
 Es un rol opcional y depende si el equipo lo requiere
Tracker
 Realiza un seguimiento de las métricas ágiles relevantes

 Evalúa el progreso y la identificación de áreas clave para la mejora

 Conserva datos históricos

RASTREADOR 
 Tester

 Ayuda al cliente con las pruebas funcionales

 Se asegura de que los tests funcionales se ejecutan

PROBADOR 
 Codificar

ACTIVIDADES Hacer Pruebas

De la Programación Extrema Escuchar

Diseñar
 Codificar
 Es necesario codificar y plasmar nuestras ideas a través del código.

 En programación, el código expresa la interpretación del problema, así

podemos utilizar el código para comunicar, para hacer comunes las ideas, y
por tanto para aprender y mejorar.

CODIFICAR
 Hacer Pruebas
 Las características del software que no pueden ser demostradas mediante
pruebas simplemente no existen

 Las pruebas dan la oportunidad de saber si lo implementado es lo que en

realidad se tenía en mente

 Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos
pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema,
entonces habremos acabado por completo

HACER PRUEBAS  
 Escuchar
 En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas
cosas que las personas de negocios piensan que son interesantes. Si ellos
pudieran programarse su propio software ¿para qué nos querrían?"
 Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado,
y tenemos que preguntar a quien necesita la información. Tenemos que
escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos
de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la
realimentación entre ambos nos ayudan a todos a entender los problemas

ESCUCHAR  
 Diseñar
 El diseño crea una estructura que organiza la lógica del sistema, un buen
diseño permite que el sistema crezca con cambios en un solo lugar

 Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo
complejo, lo apropiado es dividirla en varias

 Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos

cuanto antes

DISEÑAR  
 El juego de
Versiones Pequeñas (Short Releases)
la Planificación  (Planning Game)
 El alcance de la siguiente versión esta definido por  Un sistema simple se pone rápidamente en
las consideraciones de negocios y estimaciones producción
técnicas 
 El objetivo es maximizar
el valor del software producido.  Periódicamente, se producen nuevas
 La estrategia es poner en producción las versiones agregando en cada iteración
características más importantes lo antes posible aquellas funciones consideradas valiosas
 Las Piezas clave son las Story Cards, Los Jugadores para el cliente
son los desarrolladores y el cliente y las Movidas
son Exploración, Selección y Actualización

PRÁCTICAS BÁSICAS DE XP
 Metáfora del Sistema (Metaphor)
 Cada Proyecto es guiado por
una historia simple de cómo funciona el
sistema en general
 La historia reemplaza a la arquitectura y
debe estar en lenguaje común, entendible
para todos
PRÁCTICAS BÁSICAS DE XP
Diseño Simple (Simple Designs)
 El sistema se diseña con la máxima
simplicidad posible
 Se plasma el diseño en tarjetas CRC
(Clase – Responsabilidad- Colaboración)
 No se implementan características que no son
necesarias
 Durante el análisis se determinan las clases
que son realmente necesarias para el sistema
 Pruebas continuas
 La cobertura de testeo debe ser muy
amplia, no debe haber código no testeado.
 Están involucrados los programadores
(tests unitarios y de integración) y los
clientes (tests funcionales o de aceptación).
PRÁCTICAS BÁSICAS DE XP
Refactoring
 El refactoreo del código sucede cada vez
que sea necesario.
 Esta práctica es consecuencia directa del
valor ‘Sencillez’ ya que el foco siempre
está en codificar lo que se necesita hoy sin
dedicar tiempo a posibles futuros
requerimientos.
 Pair programming Collective code ownership
 Se programa de a dos personas  Todos pueden hacerse cargo de cambios en
cualquier lugar del código.
 Emparejamiento dinámica (no se trabaja
todo el tiempo con la misma persona).
 Diferentes roles: una persona escribe el  Todos conocen la totalidad del sistema.
código mientras la otra piensa si va a
funcionar, que tests habría que modificar,
etc.

PRÁCTICAS BÁSICAS DE XP
 Integracion Continua

-Armado de nuevo codigo para formar un modulo.

-Integracion del nuevo modulo generado.

-Puesta en prueba del nuevo modulo.

-Fin del dia

PRÁCTICAS BÁSICAS DE XP
 40hs Semanales

-Dedicacion laboral de cada individuo del equipo de un maximo

de 40hs semanales.

-Incentiva motivacion e Innovacion.

-Acepta 35hs o 45hs semanales.

-Prohibe llegar a 60hs o el cumplimiento de hs.

PRÁCTICAS BÁSICAS DE XP
 Cliente en el sitio (On-Site Customer)

Cliente de facil acceso

-Comunicacion continua entre el equipo y el

cliente.

-Disponibilidad bidireccional, tanto el cliente

como el equipo de trabajo tienen que estar
disponibles unos para otros.

PRÁCTICAS BÁSICAS DE XP
 Estandares de codeo

Seguimiento de Framework de trabajo.

-Permitir el refactoreo.

-Acuerdo de como codificar los modulos en el

equipo.

PRÁCTICAS BÁSICAS DE XP
 Potenciar
el trabajo
en equipo Balance:
Costo
Satisfacción
Tiempo
del cliente
Calidad
Alcance

OBJETIVOS DE XP