Tema 2. Metodologia XP - Parte 3 PDF

Ing.
Ronald Huanca Calle

Paradigmas de la ingeniera del software
INF 2720 A
Ing. Ronald Huanca Calle

Antecedentes e Historia de la
TeMa 2
eXtreme Programming
eXtreme Programming

Antecedentes e Historia de
eXtreme Programming
En 1989, Cunningham form un equipo que

usaba los principios y muchas de las prcticas
que despus adoptara XP, mientras trabajaba
para la compaa Wyatt Software [Fowler
2000].
Pero se reconoce a Kent Beck como el

que articul esta propuesta y le dio
nombre propio.
eXtreme Programming

Posteriormente, la consolidacin de XP se
logra con la publicacin del libro Extreme
Programming Explained: embrace change en
el ao 1999, donde Beck resume su propia
experiencia y le da forma y nombre a la
entonces nueva metodologa de desarrollo de
software, la cual le vali el premio: Software
Development Jolt Product Excellence.
Kent Beck
eXtreme Programming


Las ideas primordiales de su sistema las comunic en la revista C++

Magazine en una entrevista que sta le hizo el ao 1999. En sta deca
que l estaba convencido que la mejor metodologa era un proceso:


Que es la
eXtreme Programming?


Que es XP?
Que es XP?


Que es XP?
Principios, practicas y roles de la
eXtreme Programming


Principios de XP
Se busca :


Practicas de XP


Practicas de XP
Practicas de XP
El Juego de la planificacin
El Juego de la planificacin


Practicas de XP
Practicas de XP
El Juego de la planificacin.Reunin diaria XP
Entregas pequeas
Es un
permanente
dilogo entre
las partes
empresarial
(deseable) y
tcnica
(posible)


Practicas de XP
Practicas de XP
Una metfora es una
historia que todo el
mundo puede contar a
cerca de cmo
funciona el sistema.
Algunas veces
podremos encontrar
metforas sencillas
Programa de gestin
de compras, ventas,
con gestin de cartera
y almacn. Las
metforas ayudan a
cualquier persona a
entender el objeto del
programa.
Metfora
Cada versin
debe de ser tan
pequea como
fuera posible,
conteniendo los
requisitos de
negocios ms
importantes, las
versiones tiene
que tener
sentido como
un todo.
Es mucho
mejor planificar
para 1 mes o 2
que para seis
meses y un
ao.
Diseo Simple
Cuando se
implementa nuevas
caractersticas en
los programas se
plantea la manera
de hacerlo lo mas
simple posible,
despus de
implementar esta
caracterstica, nos
preguntamos como
hacer el programa
mas simple sin
perder
funcionalidad.

Practicas de XP
No debe existir ninguna

caracterstica en el
programa que no haya
sido probada, los
programadores escriben
pruebas para chequear el
correcto funcionamiento
del programa, los clientes
realizan pruebas
funcionales. El resultado
un programa mas seguro
que conforme pasa el
tiempo es capaz de
aceptar nuevos cambios.
Pruebas

Practicas de XP
Refactorizacin - Refactoring
Cuando se implementa
nuevas caractersticas
en los programas se
plantea la manera de
hacerlo lo mas simple
posible (Cmo hacer el
programa mas simple
sin perder
funcionalidad? )este
proceso se le denomina
recodificar o refactorizar
(refactoring).
No se debe recodificar
ante especulaciones si
no solo cuando el
sistema te lo pida.

Practicas de XP
Programacin en Parejas
Todo el cdigo de produccin

lo escriben dos personas
frente al ordenador, con un
slo ratn y un slo teclado.
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?
El emparejamiento es
dinmico, puedo estar
emparejado por la maana con
una persona y por la tarde con
otra, si tienes un trabajo sobre
un rea que no conoces muy
bien puedes emparejarte con
otra persona que si conozca
ese rea. Cualquier miembro
del equipo se puede emparejar
con cualquiera.

Practicas de XP
Cualquiera puede aportar

valor al cdigo en cualquier
parcela puede hacerlo,
ningn miembro del equipo
es propietario del cdigo. Si
alguien quiere hacer cambios
en el cdigo puede hacerlo.
Si hacemos el cdigo
propietario, y necesitamos de
su autor para
que lo cambie entonces
estaremos alejndonos
cada
vez mas de la comprensin
del problema, si se necesita
un cambio sobre una parte
del cdigo lo hacemos y
punto. XP propone un
propiedad colectiva sobre el
cdigo nadie conoce cada
parte igual de bien pero todos
conoce algo sobre cada
parte, esto prepara para la
sustitucin no traumtica de
cada miembro del equipo.
Propiedad Colectiva


Practicas de XP
Practicas de XP
Integracin Continua
Semana de 40 horas
El cdigo se debe integrar como
mnimo una vez al da, y realizar las
pruebas sobre la totalidad del sistema.
Una pareja de programadores se
encargara de integrar todo el cdigo
en una computadora y realizar todas
las pruebas hasta que estas funcionen
al 100%.
Si queremos estar frescos y

motivados cada maana y
cansado y satisfecho cada
noche. El viernes quiero estar
cansado y satisfecho para
sentir que tengo dos das para
pensar en algo distinto y volver
el lunes lleno de pasin e ideas.
Esto requiere que trabajemos
40 horas a la semana, mucha
gente no puede estar ms de
35 horas concentrada a la
semana, otros pueden llegar
hasta 45 pero ninguno puede
llegar a 60 horas durante varias
semanas y aun seguir fresco,
creativo y confiado. Las horas
extras son sntoma de serios
problemas en el proyecto, la
regla de XP dice nunca 2
semanas seguidas realizando
horas extras.


Practicas de XP
Clientes en casa - Cliente in situ
Practicas de XP
Un cliente real debe
sentarse con el equipo de
programadores, estar
disponible para responder
a sus preguntas, resolver
discusiones y fijar las
prioridades. Lo difcil es
que el cliente nos ceda
una persona que conozca
el negocio para que se
integre en el equipo
normalmente estos
elementos son muy
valiosos, pero debemos
de hacerles ver que ser
mejor para su negocio
tener un software pronto
en funcionamiento, y esto
no implica que el cliente
no pueda realizar
cualquier otro trabajo.
Estndares de Programacin
Si los programadores van a estar

tocando partes distintas del
sistema, intercambiando
compaeros, haciendo
refactoring, debemos de
establecer un estndar de
codificacin aceptado e
implantado por todo el equipo.


Roles de XP


Roles de XP
Roles de XP


Roles de XP
Objetivos de la
eXtreme Programming


Objetivos de XP
El objetivo principal de la XP
es la satisfaccin del cliente.
Se le trata de dar al cliente lo
que quiere y cuando quiere.
Por tanto, se debe responder
rpidamente a las
necesidades del cliente,
aunque realice cambios en
fases avanzadas del proyecto.
Como metodologa gil que
es, se pueden producir
modificaciones de los
requisitos del proyecto a lo
largo de su desarrollo.
Otro de los objetivos es el
trabajo en equipo. Tanto los
jefes del proyecto, clientes y
desarrolladores forman parte
del equipo y deben estar
involucrados en el desarrollo.


Las cuatro valores

Para garantizar
el xito de un
proyecto, se han
considerado
como
fundamentales
cuatro valores

Valores de XP
Comunicacin

Sencillez Simplicidad

FeedBack


Comunicacin. Muy importante. La XP ayuda
mediante sus prcticas a la comunicacin entre
los integrantes del grupo de trabajo: jefes de
proyecto, clientes y desarrolladores.
Sencillez. Los programas deben ser los ms
sencillos posibles y tener la funcionalidad
necesaria que se indican en los requisitos. No hay
que aadir algo que no se necesite hoy. Si se
necesita aadir ms funcionalidad maana pues
ya se har entonces.
Retroalimentacin. Las pruebas que se le
realizan al software nos mantiene informados del
grado de fiabilidad del sistema.
Valenta. Asumir retos, ser valientes ante los
problemas y afrontarlos. El intentar mejorar algo
que ya funciona. Aunque gracias a las pruebas
unitarias no existe el riesgo de meter la pata.
Algunas voces, aaden adems un quinto valor: la
humildad. Con la comparticin de cdigo, la
refactorizacin y el trabajo de equipo tan estrecho
una buena dosis de humildad siempre es de
agradecer.
Valentia - Respeto


Actividades


Proceso de desarrollo
eXtreme Programming




Artefactos esenciales en XP
Historia de Usuario
Historia de Usuario
Historia de Usuario
Nombre Historia de Usuario:
Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre):
Iteracin Asignada:
Puntos Estimados:
Puntos Reales:
Representan una breve

descripcin del
comportamiento del
sistema, emplea
terminologa del cliente
sin lenguaje tcnico, se
realiza una por cada
caracterstica principal
del sistema, se emplean
para hacer estimaciones
de tiempo y para el plan
de lanzamientos,
reemplazan un gran
documento de requisitos
y presiden la creacin
de las pruebas de
aceptacin.
Estas deben proporcionar

slo el detalle suficiente
como para poder hacer
razonable la estimacin de
Nmero: 1
Nombre: Enviar artculo
cunto tiempo requiere la
implementacin de la
Usuario: Autor
historia, difiere de los
Modificacin de Historia Nmero:
Iteracin Asignada: 2
casos de uso porque son
Prioridad en Negocio: Alta
escritos por el cliente, no
Puntos Estimados:
por los programadores,
(Alta / Media / Baja)
empleando terminologa
Riesgo en Desarrollo:
del cliente. Las historias
Puntos Reales:
(Alto / Medio / Bajo)
de usuario son ms
amigables que los casos
Descripcin:
de yuso
formales.
Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos)
de los
autores (nombre, e -
Historia de Usuario
mail, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la
correcta recepcin del artculo enviando un e -mail al autor de contacto con un userid y password para
que el autor pueda posteriormente acceder al artculo.
Descripcin:
Observaciones:
Observaciones:


Spike para Historia de Usuario
Las Historias de Usuario tienen tres

aspectos:
Tarjeta: en ella se almacena
suficiente informacin para
identificar y detallar la historia.
Conversacin: cliente y
programadores discuten la historia
para ampliar los detalles
(verbalmente cuando sea posible,
pero documentada cuando se
requiera confirmacin)
Pruebas de Aceptacin: permite
confirmar que la historia ha sido
implementada correctamente.

Tarea de Ingeniera
Task Card (tarea de

ingeniera)
Las task card se usan
para describir las
tareas
se realizan
Tarea que
de Ingeniera
sobre el proyecto.
Las tareas pueden ser:
Historia de Usuario (Nro. y Nombre):
Nmero Tarea:
desarrollo, correccin,
mejora, etc.
Nombre Tarea:
Estas tareas tienen
relacin con una
historia de usuario; se
Tipo de Tarea :
especifica la fecha de
Desarrollo / Correccin / Puntos Estimados:
inicio y
Mejora / Otra (especificar)
fin de la tarea, se
nombra al programador
Fecha Fin:
responsable de
Fecha Inicio:
cumplirla y describimos
que se
Programador Responsable:
tratara de hacer en la
tarea.
Descripcin:

Modelo de tarjeta CRC

(Clase - Responsabilidad Colaborador).
Estas tarjetas contienen

la informacin del nombre
de la clase, sus
responsabilidades y sus
colaboradores.
Los pasos a seguir para llenar

las tarjetas son
los encontrar
siguientes: las clases debemos pensar qu
Para
Encontrar clases
cosas interactan con el sistema (en nuestro caso
Encontrar
el usuario), y qu cosas son parte del sistema, as
responsabilidades
Una clase es cualquier
Definir colaboradores
como las pantallas tiles a la aplicacin (un
persona, cosa, evento,
Disponer
las tarjetas de datos, una entrada de parmetros
despliegue
concepto, pantalla o
y una pantalla general, entre otros). Una vezreporte.
que Las
las clases principales han sido encontradasresponsabilidades
se
de
procede a buscar los atributos y las una clase son las cosas
que conoce
y las que
responsabilidades, para esto se puede formular
la
realiza, sus atributos y
pregunta Qu sabe la clase? y Qu hace
la
mtodos.
Los
clase? Finalmente se buscan los colaboradores
colaboradores de una
En la prctica conviene tener
clase son las dems
deque
la lista
pequeas tarjetasdentro
de cartn,
se de clases que se tenga.
clases
con
las que
llenarn y que son mostradas al
trabaja en conjunto para
cliente, de manera que se pueda
llevar a cabo sus
llegar a un acuerdo sobre la validez
responsabilidades.
de las abstracciones propuestas.


Pruebas de Aceptacin
10


Prueba de Aceptacin
Caso de Prueba de Aceptacin
Numero caso de Prueba (Cdigo):
Historia de Usuario (Nro. y Nombre):
Nombre Caso de prueba:
Descripcin:
Condiciones de Ejecucin:
Entrada / Pasos de ejecucin:
Resultado Esperado:
Evaluacin de la Prueba:


Prueba Unitarias y de Integracin

Planificacin de la Entrega

Escenarios en XP : Exploracin
11


Escenarios en XP : Comenzar Iteracin


Escenarios en XP : Programacin
Entorno y Clima de trabajo en la
eXtreme Programming
Entorno y clima de trabajo

Espacio de trabajo XP


Entorno y clima de trabajoReunin diaria XP
12


Entorno y clima de trabajo Gantt de Pared
www.agiletek.com


Fases y Metodologas
eXtreme Programming

Funcionamiento de la Metodologa XP
Diseo simple
Cartas CRC
Historias del usuario

valores
Criterios de las pruebas de iteracin
Plan de iteracin
AC
NIFIC
PLA
HistoriasParadigmas
del Usuariode la ingeniera del software
Planificacin
Soluciones punta
prototipos
Iteraciones
Velocidad del Proyecto
DISE
ION
Programacin en Pareja
Reuniones diarias
Rediseo
COD
C
IFICA
ION
XP
(Programacin
extrema)
Diseos simples
Glosario de trminos
Riesgos
Funcionalidad Extra
Lanzamiento
Incremento de software
Velocidad calculada del
proyecto
PR U
EB A
Programacin en
pareja
Prueba de unitaria
Integracin continua
Tarjetas CRC
Test de aceptacin
Pruebas de aceptacin
13

14

Tema 2. Metodologia XP - Parte 3 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tema 2. Metodologia XP - Parte 3 PDF

Uploaded by

Copyright:

Available Formats

Ing.

Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

En 1989, Cunningham form un equipo que

Pero se reconoce a Kent Beck como el

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Las ideas primordiales de su sistema las comunic en la revista C++

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Principios, practicas y roles de la

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

El Juego de la planificacin.Reunin diaria XP

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

No debe existir ninguna

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Todo el cdigo de produccin

Ing. Ronald Huanca Calle

Cualquiera puede aportar

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Si queremos estar frescos y

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Si los programadores van a estar

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Las cuatro valores

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle

Ing. Ronald Huanca Calle