Diseo e Implementacin de Sistemas

Extreme Programing
Sesin 10
Ing. Gener Zambrano M. Sc.
gzambranol@usmp.pe

ndice del contenido:

Historia
Introduccin
Qu es XP?
XP caractersticas
XP valores
XP principios
XP roles
XP - artefactos
Ciclo de vida de un proyecto XP
XP - prcticas

XP - fases - aplicacin de las prcticas

XP Historia.
La programacin extrema o eXtreme Programming (XP) es un
enfoque de la ingeniera de software formulado por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999).
Todo en el software cambia. Los requisitos cambian.
1. El diseo cambia.
2. El negocio cambia.
3. La tecnologa cambia.
4. El equipo cambia.
5. Los miembros del equipo cambian. El problema no es el
cambio en s mismo, puesto que sabemos que el cambio va a
suceder; el problema es la incapacidad de adaptarnos a dicho
cambio cuando ste tiene lugar.

XP Historia.
Es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de
trabajo. XP se basa en realimentacin continua entre el cliente y el
equipo de desarrollo, comunicacin fluida entre todos los
participantes, simplicidad en las soluciones implementadas y
coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos
y muy cambiantes, y donde existe un alto riesgo tcnico.

Como soluciona XP problemas?

Retrasos y desviaciones:
versiones cortas.
Cancelan el proyecto: entregas
peridicas.
Sistemas deteriorados y
defectos: pruebas continuas.
Requisitos mal comprendidos:
cliente dentro del equipo.
Cambios de negocio: versiones
cortas.
Falsa riqueza de caractersticas:
realizar tareas prioritarias.

Cambios de personal: anima el

contacto y la integracin.

Qu es XP?
Un proceso ligero, de bajo riesgo, flexible, predecible, cientfico y
divertido de desarrollar software.
Basada en la simplicidad, la comunicacin y el reciclado continuo
de cdigo.
Conjunto de practicas y reglas empleadas para desarrollar software
En vez de planificar, analizar y disear para el futuro distante,
hacer todo esto un poco cada vez, a travs de todo el proceso de
desarrollo.

XP caractersticas:
Principios de actuacin claves :
1. Acortar los ciclos de desarrollo
2. Involucrar al cliente desde el principio hasta el final de cada
ciclo.
Se centra en la satisfaccin del cliente.
1. Diseada para entregar el software, a quien lo necesita, en el
momento en el cual lo necesita.
2. Provee los mecanismos necesarios para hacer cambios en los
requerimientos del usuario (incluso bien avanzado el ciclo de
vida del software).
Enfatiza el trabajo en equipo.
Gerentes, clientes y
desarrolladores, forman un gran equipo de trabajo, dedicado a
entregar un software de calidad.

XP caractersticas:

XP valores:
XP no es un conjunto de reglas a
seguir, sino una forma de trabajar
en armona con los valores
personales y organizacionales,
que tiene su punto de partida en
cinco valores fundamentales que
son: Comunicacin, Simplicidad,
Retroalimentacin, Coraje y
Respeto.

XP valores:
Simplicidad
La simplicidad consiste en desarrollar slo el sistema que
realmente se necesita. Implica resolver en cada momento slo
las necesidades actuales.
Desarrollaremos lo que sea solicitado y necesario.
un diseo y programacin simple mejora la calidad de las
comunicaciones, pues es ms fcil de implementar y entender
por todos en el equipo.

XP valores:
Feedback rpido y continuo
Una metodologa basada en el desarrollo incremental de
pequeas partes, con entregas y pruebas frecuentes y continuas,
proporciona un flujo de retro-informacin valioso para detectar
los problemas o desviaciones.

De esta forma los fallos se localizan muy pronto.

La planificacin no puede evitar algunos errores, que slo
se evidencian al desarrollar el sistema.

La

retro-informacin es la herramienta que permite

reajustar la agenda y los planes.

Retroalimentacin concreta y frecuente del cliente, del equipo y

de los usuarios finales da una mayor oportunidad de dirigir el
esfuerzo.

XP valores:
Coraje
El coraje implica saber tomar decisiones difciles. Reparar un
error cuando se detecta. Mejorar el cdigo siempre que tras el
feedback y las sucesivas iteraciones se manifieste susceptible
de mejora.
Tratar rpidamente con el cliente los desajustes de agendas para
decidir qu partes y cundo se van a entregar.
Se requiere valor para comunicarse con los dems cuando eso
podra exponer la propia ignorancia. Se requiere valor para
mantener el sistema simple, dejando para maana las decisiones
de maana. Y, sin un sistema simple, comunicacin constante y
retroalimentacin, es difcil ser valeroso.

XP valores:
Comunicacin
XP pone en comunicacin directa y continua a clientes y
desarrolladores. El cliente se integra en el equipo para
establecer prioridades y resolver dudas. De esta forma ve el
avance da a da, y es posible ajustar la agenda y las
funcionalidades de forma consecuente.
Algunos problemas en los proyectos tienen su origen en que
alguien no dijo algo a alguien ms sobre algo importante en
algn momento. XP hace casi imposible la falta de
comunicacin.

XP valores:
Respeto
El valor de respeto incluye el respeto por los dems , as como el
respeto propio.
Los miembros respetan su propio trabajo por siempre luchando
por la alta calidad y la bsqueda para el mejor diseo para la
solucin a la mano a travs de la refactorizacin .
Por ejemplo, los desarrolladores nunca deben subir cambios que
impidan la compilacin de la versin, que hagan fallar pruebas
unitarias ya realizadas o que de alguna otra forma retrasen el
trabajo de sus pares, esto significa tener respeto por el trabajo (y el
tiempo) de los dems.

Principios de XP:
XP no es un modelo de procesos ni un marco de trabajo, sino
un conjunto de 12 prcticas que se complementan unas a otras y
deben implementarse en un entorno de desarrollo cuya cultura
se base en los cuatro valores citados
Prcticas de codificacin:
1. Simplicidad de cdigo y de diseo para producir software
fcil de modificar.
2. Reingeniera continua para lograr que el cdigo tenga un
diseo ptimo.

3. Desarrollar estndares de codificacin, para comunicar ideas

con claridad a travs del cdigo.
4. Desarrollar un vocabulario comn, para comunicar las ideas
sobre el cdigo con claridad.

Principios de XP:
Prcticas de desarrollo:
5. Adoptar un mtodo de desarrollo basado en las pruebas para
asegurar que el cdigo se comporta segn lo esperado.
6. Programacin por parejas, para incrementar el conocimiento,
la experiencia y las ideas.

7. Asumir la propiedad colectiva del cdigo, para que todo el

equipo sea responsable de l.
8. Integracin continua, para reducir el impacto de la
incorporacin de nuevas funcionalidades.

Principios de XP:
Prcticas de negocio:

9. Integracin de un representante del cliente en el equipo, para

encauzar las cuestiones de negocio del sistema de forma
directa, sin retrasos o prdidas por intermediacin.
10. Adoptar el juego de la planificacin para centrar en la
agenda el trabajo ms importante.
11. Entregas regulares y frecuentes para satisfacer la inversin
del cliente.
12. Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.

XP - roles:
Los roles presentes en esta metodologa son los siguientes:

XP ciclo de vida de un proyecto XP.

Autor: Kent Beck

Extreme Programming Proceso y Fases

XP ciclo de vida de un proyecto XP.

1. Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias
de usuario que son de inters para la primera entrega del
producto. Al mismo tiempo el equipo de desarrollo se familiariza
con las herramientas, tecnologas y prcticas que se utilizarn en
el proyecto.
Se prueba la tecnologa y se exploran las posibilidades de la
arquitectura del sistema construyendo un prototipo. La fase de
exploracin toma de pocas semanas a pocos meses, dependiendo
del tamao y familiaridad que tengan los programadores con la
tecnologa.

XP ciclo de vida de un proyecto XP.

2. Planificacin de la Entrega (Release).

En esta fase el cliente establece la prioridad de cada historia de

usuario, los programadores realizan una estimacin del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el
contenido de la primera entrega y se determina un cronograma en
conjunto con el cliente.
Una entrega debera obtenerse en no ms de tres semanas. Esta
fase dura unos pocos das. Las estimaciones de esfuerzo asociado
a la implementacin de las historias la establecen los
programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programacin. Las historias
generalmente valen de 1 a 3 puntos.

XP ciclo de vida de un proyecto XP.

2. Planificacin de la Entrega (Release).

Por otra parte, el equipo de desarrollo mantiene un registro

de la velocidad de desarrollo, establecida en puntos por
iteracin, basndose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas
en la ltima iteracin.
La planificacin se puede realizar basndose en el tiempo o el
alcance. La velocidad del proyecto es utilizada para establecer
cuntas historias se pueden implementar antes de una fecha
determinada o cunto tiempo tomar implementar un conjunto de
historias. necesarias para su implementacin.

XP ciclo de vida de un proyecto XP.

3. Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser

entregado. El Plan de entrega est compuesto por iteraciones de
no ms de tres semanas. En la primera iteracin se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creacin de esta arquitectura, sin
embargo, esto no siempre es posible ya que es el cliente quien
decide qu historias se implementarn en cada iteracin (para
maximizar el valor de negocio).

XP ciclo de vida de un proyecto XP.

3. Iteraciones

Al final de la ltima iteracin el sistema estar listo para entrar en

produccin. Los elementos que deben tomarse en cuenta durante
la elaboracin del Plan de la Iteracin son: historias de usuario no
abordadas, velocidad del proyecto, pruebas de aceptacin no
superadas en la iteracin anterior y tareas no terminadas en la
iteracin anterior. Todo el trabajo de la iteracin es expresado en
tareas de programacin, cada una de ellas es asignada a un
programador como responsable, pero llevadas a cabo por parejas
de programadores.

XP ciclo de vida de un proyecto XP.

4. Produccin

La fase de produccin requiere de pruebas adicionales y

revisiones de rendimiento antes de que el sistema sea trasladado
al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusin de nuevas caractersticas a la
versin actual, debido a cambios durante esta fase. Es posible que
se rebaje el tiempo que toma cada iteracin, de tres a una semana.
Las ideas que han sido propuestas y las sugerencias son
documentadas para su posterior implementacin (por ejemplo,
durante la fase de mantenimiento).

XP ciclo de vida de un proyecto XP.

5. Mantenimiento

Mientras la primera versin se encuentra en produccin, el

proyecto XP debe mantener el sistema en funcionamiento al
mismo tiempo que desarrolla nuevas iteraciones. Para realizar
esto se requiere de tareas de soporte para el cliente. De esta
forma, la velocidad de desarrollo puede bajar despus de la
puesta del sistema en produccin. La fase de mantenimiento
puede requerir nuevo personal dentro del equipo y cambios en su
estructura.

XP ciclo de vida de un proyecto XP.

6. Muerte del Proyecto.

Es cuando el cliente no tiene ms historias para ser incluidas en el

sistema. Esto requiere que se satisfagan las necesidades del
cliente en otros aspectos como rendimiento y confiabilidad del
sistema.
Se genera la documentacin final del sistema y no se realizan ms
cambios en la arquitectura. La muerte del proyecto tambin
ocurre cuando el sistema no genera los beneficios esperados por
el cliente o cuando no hay presupuesto para mantenerlo.

XP Fases (prcticas):

XP Fases (prcticas):
1. Planeacin:
Se escucha los requerimientos, las necesidades de los usuarios,
esta actividad conlleva a la creacin de historias de usuario, las
cuales describen la salida necesaria, caractersticas y
funcionalidades del software a elaborar, cada historia es colocada
en una tarjeta indizada, as el cliente asigna un valor o prioridad a
determinada historia, tomando como referencia el valor, que la
actividad descrita en la tarjeta, representa para el negocio.
Posteriormente el equipo de trabajo evala cada historia y se le
asigna un costo medido en semanas de desarrollo, en el caso que
este sea superior a tres semanas, se solicita al usuario que
descomponga la historia original en otras mas pequeas y que
puedan ser abarcadas en dicho tiempo.

XP Fases (prcticas):
1. Planeacin:
Una vez llegado a un compromiso sobre las entregas, las historias
son ordenadas segn su desarrollo de la siguiente manera:
Todas las historias se implementarn de inmediato.
Las historias con ms valor y ms riesgosas entrarn en la
programacin de actividades y se implementarn en primer
lugar.
Una vez realizada la primera entrega de software (o
incremento), se calcula la velocidad del proyecto, el cual es el
nmero de historias implementadas para dicha entrega.

XP Fases (prcticas):
1. Planeacin:
El valor obtenido permite: Facilitar la estimacin de las fechas
de entrega y programar actividades para entregas posteriores,
determinar el grado de compromiso para todas las historias
durante el desarrollo del proyecto, ajustando la velocidad de
las entregas.

A medida que se ejecuta el proyecto, el cliente puede agregar mas

historias, cambiar el valor de una ya existente, descomponerla o
eliminarlas, as el equipo de desarrolladores modifica sus planes
y reconsidera las entregas faltantes.

XP Fases (prcticas):
1. Planeacin:
Para el negocio:

mbito Qu debe resolver el software?

Prioridad Qu debe ser echo en primer lugar?

Composicin de versiones Cunto es necesario hacer para

aportar valor?
Fechas de versiones Fechas para presencia del software?

XP Fases (prcticas):
1. Planeacin:
Para el desarrollador:

Estimaciones Cunto lleva implementar una caracterstica?

Consecuencias, informar sobre
decisiones que adopta el negocio.

consecuencias

de

las

Procesos Cmo se organiza el trabajo en el equipo?

Programacin detallada: En una versin Qu se resolver
primero?

XP Fases (prcticas):
2. Diseo:

Se le da preferencia a la sencillez sobre representaciones ms

complejas, as el diseo gua la implementacin de una historia
mientras se escribe, se inhibe de agregar funcionalidad adicional,
ya que dicha funcionalidad ser agregada despus.
Se utilizan las tarjetas CRC (Clase, Responsabilidad,
Colaborador), para identificar y organizar las clases orientadas a
objetos.

XP Fases (prcticas):
2. Diseo:
En aquellos casos donde se encuentre un problema de diseo
difcil, se recomienda la creacin de un prototipo operativo para
esa porcin de diseo, implementando y evaluando el prototipo
de diseo, as cuando se implemente la implementacin
verdadera, se disminuyen los riesgos.
La programacin extrema estimula el rediseo, as el
comportamiento externo del cdigo queda inalterable, pese a las
mejoras realizadas en su estructura interna, al modificar y
simplificar el diseo interno, esto slo se puede alcanzar gracias a
las ventajas que ofrece la encapsulacin y el polimorfismo de la
programacin orientada a objetos.

XP Fases (prcticas):
3. Codificacin:
El primer paso de la codificacin, no es escribir el cdigo mismo
del desarrollo, al contrario, se elaboran las pruebas unitarias de
cada una de las entregas relacionadas con las historias, de esta
manera el desarrollador centrar sus esfuerzos de programacin
en pasar las pruebas previamente elaboradas, es decir, las pruebas
actan como guas de accin para el programador.
El cdigo se debe integrar como mnimo una vez al da, y realizar
las pruebas sobre la totalidad del sistema.

XP Fases (prcticas):
4. Pruebas:

Las pruebas unitarias, elaboradas como primer paso en la etapa

de la codificacin, se implementan con una estructura que
permita su automatizacin, para que as puedan implementarse
repetidas veces y con facilidad. Dichas pruebas pueden ejecutarse
a diario con el objeto de corregir cualquier desviacin o anomala
del software a tiempo.
Tambin se acostumbra a ejecutar pruebas de aceptacin por
parte del cliente, estas pruebas se centran en las caractersticas y
funcionalidades generales del sistema y que son visibles y
auditables por parte del cliente.

XP prcticas de la planificacin
Historias de usuarios (relatos)
Las historias de usuario son un conjunto de fichas escritas por
el cliente con la ayuda de los desarrolladores para indicar las
funciones que debe realizar el sistema, constituyendo el
mecanismo base de captura de requerimientos de la
programacin extrema.
Cada historia de usuario incluye una breve descripcin,
entorno a lo que el sistema debe de hacer, es importante
procurar no incluir sintaxis tcnica, de modo que se centren en
las necesidades y no en la especificacin del aspecto de las
interfaces de usuario ni en la implementacin, como base de
datos.
Los clientes ayudan a asegurar que la mayora de las
funcionalidades deseadas para el sistema estn cubierta con las
historias.

Nmero: 001

Nombre Historia de Usuario: Gestionar Citas

Usuario: Paciente
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)

Descripcin:
Los pacientes podrn (previa autenticacin) gestionar sus citas, es decir, podrn generar, modificar o anular
sus citas. Para generar una cita el paciente deber realizar una bsqueda seleccionando la especialidad o
ingresando el nombre del mdico, el sistema mostrar las especialidades, mdicos, fechas y horas
disponibles de acuerdo a la bsqueda realizada. El paciente deber seleccionar la fecha y hora para generar

su cita, la cual se guardar en un registro. Adems, en la opcin Gestionar Citas el sistema mostrar una lista
de las citas pendientes, esto permitir al paciente modificar o anular una cita; para ello el paciente
seleccionar la cita que desea modificar y podr cambiar la fecha, hora y/o mdico de acuerdo a la
disponibilidad (para ello previamente se debe realizar una bsqueda por mdicos), si desea anular la cita
seleccionar la opcin Anular Cita.
Observaciones:
El paciente slo podr modificar fecha, hora y/o mdico.
El sistema permitir anular la cita slo si se realiza con un plazo mximo de dos horas de anticipacin a la
10/5/2015
cita.

XP prcticas de la planificacin
Tarjetas de ingeniera
Tarea de Ingeniera

Nmero Tarea:

Historia de Usuario (Nro. y Nombre):

Nombre Tarea:

Tipo de Tarea :
Desarrollo / Correccin / Mejora / Otra

Puntos Estimados:

(especificar)

Fecha Inicio:
Programador Responsable:

Descripcin:

Fecha Fin:

XP prcticas del diseo:

Una metfora es una historia que todo el mundo puede

contar a cerca de cmo funciona el sistema.

Hay que buscar unas frases o nombres que definan cmo

funcionan las distintas partes del programa, de forma que
slo con los nombres se pueda uno hacer una idea de qu es
lo que hace cada parte del programa. Un ejemplo
Programa de gestin de compras, ventas, con gestin de
cartera y almacn.

Las metforas ayudan a cualquier persona a entender el

objeto del programa.

XP prcticas del diseo:

Tarjetas CRC:

Las Tarjetas CRC (Class, Responsibilities and Colaboration)

sirven para disear el sistema en conjunto entre todo el equipo

Una clase es cualquier persona, cosa, evento, concepto, pantalla

o reporte. Las responsabilidades de una clase son las cosas que
conoce y las que realizan, sus atributos y mtodos. Los
colaboradores de una clase son las dems clases con las que
trabaja en conjunto para llevar a cabo sus responsabilidades.

XP prcticas del diseo:

Tarjetas CRC:
Las principales actividades de las tarjetas CRC son:

Identificacin de clases y asociaciones que participan del

diseo del sistema.
Obtencin de las responsabilidades que debe cumplir cada
clase.
Establecimiento de cmo una clase colabora con otras clases
para cumplir con sus responsabilidades.
La tcnica CRC propone una forma de trabajo,
preferentemente grupal, para encontrar los objetos del
dominio de la aplicacin, sus responsabilidades y cmo
colaboran con otros para realizar tareas.

XP prcticas del diseo:

Tarjetas CRC:

XP prcticas del diseo:

Diseo simple:
1. Implementar la solucin ms simple que pueda funcionar

2. La complejidad innecesaria y el cdigo extra debe ser

removido inmediatamente
3. No agregar nuevas funcionalidades antes de que sean
agendadas, primero centrarnos en lo principal
4. Tiene el menor nmero de clases y mtodos

Se remueve la redundancia, se eliminan las funcionalidades no

necesarias y se rejuvenecen los diseos obsoletos.

XP prcticas del desarrollo:

Refactorizacin (recodificacin):

Es una actividad constante de reestructuracin del cdigo con

el objetivo de remover duplicacin de cdigo, mejorar su
legibilidad, simplificarlo y hacerlo ms flexible para facilitar
los posteriores cambios.

consiste en hacer el programa mas simple sin perder

funcionalidad.
No debemos de recodificar ante especulaciones si no solo
cundo el sistema te lo pidaMejora la estructura interna del
cdigo sin alterar su comportamiento externo

Nos ahorra tiempo e incrementa la calidad

XP prcticas del desarrollo:

Disponibilidad del cliente:
Un cliente real debe sentarse con el equipo de
programadores, estar disponible para responder a sus
preguntas, resolver discusiones y fijar las prioridades.
La comunicacin oral es ms efectiva que la escrita, ya
que esta ltima toma mucho tiempo en generarse y puede
tener ms riesgo de ser mal interpretada.
Las historias de usuario son escritas por los clientes con la
ayuda de los desarrolladores

XP prcticas del desarrollo:

Estndares de programacin:
Se debe establecer un estndar de codificacin aceptado e implantado por
todo el equipo.
Pruebas unitarias: Los programadores continuamente escriben pruebas
unitarias, que deben correr sin defectos para poder continuar desarrollando.
Pruebas funcionales: Los clientes escriben pruebas para demostrar que los
requerimientos se han completado
Crear y mantener un conjunto de pruebas que son ejecutadas, luego de cada
cambio para asegurar la calidad de la lnea base.
No debe existir ninguna caracterstica en el programa que no haya sido
probada.

XP prcticas del desarrollo:

La programacin en parejas.
Todo el cdigo de produccin se escribe con dos personas mirando
a una mquina, con un solo teclado y un solo ratn.
Cada miembro de la pareja juega su papel: uno codifica en el
ordenador y piensa la mejor manera de hacerlo, el otro piensa mas
estratgicamente, Va a funcionar?, Puede haber pruebas donde
no funcione?, Hay forma de simplificar el sistema global para
que el problema desaparezca?. De esta forma se consigue un
cdigo y diseo con gran calidad.

XP prcticas del desarrollo:

Propiedad colectiva del cdigo:
Cualquier programador puede cambiar cualquier parte del
cdigo en cualquier momento.
Motiva a todos a contribuir con nuevas ideas en todos los
segmentos del sistema,
Evita que algn programador sea imprescindible para realizar
cambios en alguna porcin de cdigo
40 horas por semana:
Se debe trabajar un mximo de 40 horas por semana
No se trabajan horas extras en dos semanas seguidas
El trabajo extra desmotiva al equipo

XP prcticas de las pruebas:

Realizar pruebas:
Toda caracterstica en el programa debe ser probada, los
programadores escriben pruebas para chequear el correcto
funcionamiento del programa, los clientes realizan pruebas
funcionales. El resultado un programa mas seguro que soporte
cambios en el tiempo.

XP prcticas de las pruebas:

Las pruebas de aceptacin

Ciclo de entregas:

Enlaces:
http://www.extremeprogramming.org/

http://xprogramming.com/index.php

Principales metodologas giles:

SCRUM, Ken Schwaber & Jeff Sutherland, www.scrumguides.org
Extreme Programming, Kent Beck www.extremeprogramming.org
DSDM (Dynamic Systems Development Method), www.dsdm.org
Lean Programming, Mary Poppendieck, www.poppendieck.com
FDD (Feature-Driven Development), Peter Coad & Jeff De
www.nebulon.com/fdd, http://www.agilemodeling.com/essays/fdd.htm
Adaptative Software Development, Jim Highsmith www.adaptivesd.com
Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org

Luca,

Diseo e Implementacin de Sistemas

Extreme Programing

Fin de la sesin 10
Ing. Gener Zambrano M. Sc.
gzambranol@usmp.pe