Sei sulla pagina 1di 64

USMP

Programacin Extrema

Max Ugaz (Ma.)


Director de CORVUS-USMP

Origen de Extreme
Programming (XP)

XP no es una metodologa que se diseo con un

gran plan maestro, sino que fue un estilo de


programacin que se destil con el paso de los
aos hasta convertirse en lo que conocemos
ahora por eXtreme Programming (XP).
Sus orgenes se remontan a principios de la
dcada de los 80s dentro de la comunidad de
Smalltalk, aunque no se formaliz como
metodologa hasta 1996 cuando uno de sus
precursores, Kent Beck, la puso en prctica
para un desarrollo de Chrysler (*).

(*)http://www.xprogramming.com/publications/dc9810cs.pdf

El Problema
El desarrollo de software falla en las
entregas y falla en la entrega de valor.
Esta falla tiene un enorme impacto tanto
humano como econmico.
Necesitamos encontrar una nueva
manera de desarrollar el software
Kent Beck (y muchos ms!!!)

Riesgo: El problema bsico


El problema bsico del desarrollo de
software es EL RIESGO.
ALGUNOS EJEMPLOS DE RIESGO:
Atrasos en los calendarios.
Cancelaciones de
proyectos.
Aplicaciones que envejecen
muy pronto.
Tasa alta de defectos.

Falta de comprensin del


negocio.
Cambios en el negocio.
Caractersticas atractivas
pero con poco valor.
Rotacin de los
programadores.

Nuestra misin
Si aceptamos el RIESGO del proyecto como
el problema a ser resuelto,
Dnde vamos a buscar la solucin?
Lo que necesitamos es inventar un estilo
de desarrollo de software que enfrenta
esos riesgos.
Debemos comunicarla a:
Programadores, gerentes y clientes.

Economa del Software de


Necesitamos hacer que nuestro desarrollo
Desarrollo
de software sea econmicamente
MS VALIOSO:

Gastando el dinero necesario ms lentamente.

Generando ganancias ms rpidamente.

Aumentando la expectativa de vida de nuestro


proyecto.

Opciones
La gerencia del proyecto de software tiene las
siguientes cuatro opciones:
Opcin de abandono: podemos lograr algo de valor si lo
cancelamos ahora.
Opcin de cambiar: cambiar la direccin del proyecto a
pedido del cliente. Mientras ms frecuentemente cambien
los requerimientos, mejor.
Opcin de diferir: podemos esperar hasta que la
situacin se ordene. Mientras ms se difiera la inversin,
mejor.
Opcin de crecer: si el mercado parece que despega
podemos crecer rpidamente para sacar ventaja. Mientras
ms rpidamente crezca el proyecto, mejor.

Cuatro variables
Controlaremos cuatro variables en
nuestros proyectos:
Costo
Tiempo
Calidad
Alcance

Cuatro variables
Algunos gerentes y clientes presionan por
lograr lo mximo de cada variable, con eso
slo se logra sacrificar la calidad:
Costo

CLIENTES

Tiempo
Calidad

GERENTES

Alcance

De todas ellas, el ALCANCE es la variable de


MAYOR CONTROL!!

Cuatro variables
La solucin es hacer visibles las cuatro
variables.
Si todos (programadores, clientes y
gerentes) pueden ver las cuatro variables,
ellos elegirn concientemente que variables
controlar.
Costo
Tiempo
Calidad
Alcance

Interaccin entre variables

Costo: ni que falta ni que sobre, ambos extremos


traern problemas.

Tiempo: mucho tiempo retrasa la retroalimentacin


de la produccin, poco tiempo hace peligrar la
calidad y a veces el alcance e incluso los costos.

Calidad: es terrible como variable de control. Se


logran pocas ganancias (das o semanas)
sacrificando la calidad con enormes costos
(humanos, de negocios y tcnicos).

Alcance: menos alcance hace posible entregar una


mejor calidad, a tiempo y a menor costo.

Enfocndose en el ALCANCE
Mucha gente entiende que el costo, calidad y
tiempo son variables de control, pocas
comprenden la cuarta variable: EL ALCANCE.
Una de las decisiones ms poderosas en la
gerencia de proyectos es la gestin del
ALCANCE.
Si administramos activamente el ALCANCE,
podemos brindarles a los clientes y gerentes
control sobre el costo, la calidad y el tiempo.

Enfocndose en el ALCANCE
Una de las mejores cosas que pasan con el
ALCANCE es que es una variable que VARIA
mucho.
Los clientes no nos pueden decir que es lo
que ellos quieren. Cuando les entregamos lo
que ello dijeron que queran, no les gusta.
Esto es totalmente cierto!
Los requerimientos nunca estn claros al inicio
porque los clientes nunca pueden decirte
exactamente lo que quieren.

Enfocndose en el ALCANCE
El desarrollo de una pieza de software
cambia a sus propios requerimientos!
Tan pronto como el cliente ve el primer
release, ellos aprenden que es lo que
ellos desean en el siguiente release
o
QUE ES LO QUE REALMENTE QUERIAN EN
EL PRIMER RELEASE

Enfocndose en el ALCANCE
Podramos ver esta poca firmeza de los
requerimientos del cliente como una
oportunidad y no como un problema?
Si es as, el ALCANCE se convertira en la
variable ms sencilla de las cuatro variables
de control.
Si creamos una disciplina de desarrollo de
software basada en este modelo, podramos
resolver los problemas de tiempo, calidad y
costo de cada pieza de software.

Enfocndose en el ALCANCE
En esa nueva disciplina de desarrollo de
software, conforme el desarrollo progrese,
podramos ajustar el continuamente el
ALCANCE para que coincida con las
condiciones conforme las vayamos
encontrando.
Debe TOLERAR el CAMBIO fcilmente
porque el proyecto podra cambiar de
direccin con frecuencia.

Enfocndose en el ALCANCE
Para lograr eso la Programacin Extrema (XP)
usa dos estrategias:

Consigues mucha prctica haciendo estimados y


retroalimentndote de los resultados actuales.
Mejores estimados reducen las probabilidades de
dejar de lado funcionalidad.

Implementas primero los requerimientos ms


importantes del cliente.
As, si hay que dejar funcionalidad de lado, ser
menos importante que la que ya estara corriendo
en el sistema.

El Costo del Cambio


Una de los supuestos universales de la Ingeniera de
Software es que los costos de cambio de un programa
crecen exponencialmente en el tiempo.

El Costo del Cambio


Un problema que puede costar arreglarlo $1 si se
encuentra en la etapa del anlisis de requerimientos
puede costar arreglarlo miles de dlares una vez que
el software est en produccin.

El Costo del Cambio


EL PROBLEMA ES QUE ESTA CURVA YA
NO ES VLIDA.

Con una combinacin de tecnologa y prcticas de


programacin es posible experimentar una curva
totalmente opuesta.

El Costo del Cambio


Ahora son posibles historias como la que siguen:
17:00 Descubrimos que en nuestro sistema no es

necesario que cada transaccin tenga dbitos y


crditos en varias cuentas a la vez.

17:02 Le pido a mi compaero de programacin que

examinemos la situacin. De 300,000 transacciones en


el sistema, confirmamos que todas usan una sla
cuenta de dbito y una sla cuenta de crdito.

17:05 - Cmo corregimos el error? Cambiando la

INTERFASE de la transaccin y cambiando la


IMPLEMENTACIN. Escribimos los cuatro mtodos
necesarios y empezamos las pruebas.

Continuar

El Costo del Cambio


17:15 Las pruebas (ms de 1000 pruebas unitarias

y funcionales) corren al 100%. No hay razn para


creer que los cambios no funcionarn bien.
Empezamos la migracin en la base de datos.

17:20 Los bacheros de respaldo han terminado.

Instalamos la nueva versin y ejecutamos la


migracin.

17:30 Ejecutamos algunas pruebas de lgica, todo

funciona bien. No se nos ocurre nada ms que hacer.


Nos vamos a casa.

Al da siguiente: Las bitcoras de error estn limpias.

No hay quejas de los usuarios. El cambio funcion.

El Costo del Cambio


La comunidad de desarrollo de software ha
invertido enormes cantidades de recursos
en las dcadas recientes para reducir el
costo del cambio:
Mejores lenguajes.
Mejor tecnologa de bases de datos.
Mejores prcticas de programacin.
Mejores ambientes y herramientas.
Nuevas notaciones.

El Costo del Cambio


Qu podra suceder si toda esta inversin reportara
sus beneficios? Qu pasara si el costo de cambio
no subiese exponencialmente con el tiempo?

Esta es una de las premisas de la Programacin Extrema (XP).


ES LA PREMISA TCNICA DE LA PROGRAMACION EXTREMA (XP).

El Costo del Cambio


Si el costo de cambio sube lentamente con el
tiempo, nosotros podramos actuar de manera muy
distinta de cmo ahora nos obligan nuestro actual
supuesto de que el costo crece exponencialmente
en el tiempo.

El Costo del Cambio

Podramos tomar las grandes decisiones lo ms

tarde posible

Difiriendo el costo de decidir y teniendo la mayor

posibilidad de que las decisiones sean correctas.

Podramos implementar slo lo que tenemos que

implementar

Esperando que las necesidades que anticipamos para

maana no sean ciertas.

El Costo del Cambio

Si una curva de costos aplanada hace posible la


Programacin Extrema (XP), una curva de costos
ascendente la hara totalmente imposible.

Los Cuatro Valores de la XP


Las metas de corto plazo suelen entrar en
conflicto con las metas de largo plazo. Las
sociedades han aprendido a enfrentar este
problema desarrollando un conjunto de
valores. Los cuatro valores de la Programacin
Extrema son:
Comunicacin
Simplicidad
Retroalimentacin
Coraje

Los Cuatro Valores de la XP


COMUNICACIN (i)
Los problemas con los proyectos pueden casi
indefectiblemente rastrearse hasta el
momento en que alguien no est
conversando con alguien ms acerca de algo
importante.
Esto no pasa slo por azar.

Hay muchas circunstancias que conducen


a la ruptura de las comunicaciones.

Los Cuatro Valores de la XP


COMUNICACIN (ii)
La Programacin Extrema (XP) mantiene la
comunicacin fluida empleando muchas
prcticas que no se podran hacer sin
comunicacin fluida.
Prueba unitaria.
Programacin por pares.
Estimacin de tareas.

El efecto de probar, emparejar y estimar es que


los programadores y los clientes tienen que
comunicarse.

Los Cuatro Valores de la XP


SIMPLICIDAD(i)
Cul es la cosa ms simple que podra
funcionar para este requerimiento?
La simplicidad no es fcil.
Lo ms difcil es dejar de mirar las cosas que
necesitaremos implementar maana, la
prxima semana, el prximo mes.
Pensar compulsivamente en el futuro es hacerle
caso al miedo a la curva de costos de cambio
exponenciales!

Los Cuatro Valores de la XP


SIMPLICIDAD(ii)
La Programacin Extrema (XP) es hacer una
apuesta: apostar que es mejor hacer una
cosa simple hoy y pagar un poco ms
maana por cambiarla si se hace necesario,
en lugar de hacer algo ms complicado hoy
que podra no usarse nunca maana.

Los Cuatro Valores de la XP


RETROALIMENTACIN
No me preguntes a m, pregntale al
sistema!
La retroalimentacin concreta sobre el estado
actual del sistema es absolutamente
invalorable.
El optimismo es una amenaza ocupacional en el
desarrollo de software. La retroalimentacin es
el tratamiento.

Los Cuatro Valores de la XP


CORAJE
Si no ests yendo a tu mxima velocidad,
alguien ms lo har, y ellos se comern tu
almuerzo.
Cada cierto tiempo alguien en el equipo
tendr una idea descabellada que podra
reducir la complejidad de todo el sistema a la
mitad. Si tienen CORAJE, la probarn.
Funcionar (A VECES). Si tienen CORAJE, la
pondrn en produccin.

Principios bsicos
Los cuatro valores nos dan un criterio para
una solucin exitosa, pero son muy vagos
an para indicarnos qu prcticas utilizar.
Necesitamos destilar los valores en principios
concretos que podamos usar.
Estos principios nos ayudarn a elegir entre
las alternativas. Preferiremos las alternativas
que cumplan ms con los principios que
aquellas que no lo hacen.

Principios bsicos
Estos son los principios fundamentales de
la Programacin Extrema (XP):
Rpida retroalimentacin
Adoptar la simplicidad

Cambio incremental
Adoptar el cambio
Trabajo de calidad

Rpida retroalimentacin
La psicologa del aprendizaje ensea que el tiempo

entre la accin y la retroalimentacin es crtica para


el aprendizaje.
Los experimentos en animales demuestran que
incluso pequeas diferencias de tiempo en la
retroalimentacin resultan en grandes diferencias en
el aprendizaje.
Una pequea demora entre el estmulo y la respuesta
y el ratn no aprende que el botn rojo significa
comida.
Por eso uno de los principios es conseguir
retroalimentacin, interpretarla e incluir lo aprendido
dentro del sistema tan pronto como sea posible.
La retroalimentacin debe ser en segundo o minutos
en lugar de das, semanas o meses.

Adoptar la simplicidad
Trate cada problema como si pudiese ser resuelto

con una simplicidad casi ridcula.


El tiempo que ahorraremos as en el 98% de
problemas nos darn los recursos para aplicarlos al
otro 2%.
En muchos casos este es el principio ms difcil de
digerir por parte de los programadores. Nos han
dicho tradicionalmente que planeemos para el
futuro, que diseemos para reusar.
En lugar de eso, la Programacin Extrema (XP)
nos dice que resolvamos el problema de hoy y
confiemos en nuestra habilidad para aadirle
complejidad en el futuro, cuando sea necesario.

Cambio incremental
Los grandes cambios hechos todos a la vez
simplemente no funcionan.
Encontraremos que el cambio incremental es
aplicable a la Programacin Extrema (XP) de
muchas maneras.
El diseo cambia un poco en cada vez, el plan
cambia un poco en cada vez, el equipo
cambio un poco en cada vez.
Incluso la adopcin de la Programacin
Extrema (XP) debe ser hecha en pequeos
pasos.

Adoptar el cambio

La mejor estrategia es aquella que


preserva la mayora de las opciones
mientras que resuelve
inmediatamente tu problema ms
apremiante.

Trabajo de calidad
A nadie le gusta trabajar con negligencia.
A todos nos gusta hacer un buen trabajo.
De las cuatro variables del desarrollo de

proyectos alcance, costo, tiempo y calidad


la calidad no es realmente una variable
gratuita.
Las nicas notas posibles son excelente o
demencialmente excelente, dependiendo
slo de s hay vidas en juego o no.
De otra forma nadie disfrutar del trabajo,
nadie trabajar bien y el proyecto se ir por
el drenaje.

Otros principios menos


bsicos
Ensear a aprender.
Inversiones iniciales pequeas.
Jugar a ganar.
Experimentos concretos.
Comunicacin abierta y honesta.
Trabajar con el instinto de la gente, no contra el.
Responsabilidad aceptada.
Adaptacin local.
Viajar ligero.
Medicin honesta.

Las Prcticas
El juego del planeamiento: rpidamente determine

el alcance de la prxima entrega combinando las


prioridades del negocio y los estimados tcnicos.
Conforma la realidad sobrepase al plan, actualice el
plan.
Pequeas entregas: ponga sistemas simples en

produccin rpidamente, luego libere nuevas versiones


durante ciclos muy cortos.
Metfora: conduzca todo el desarrollo usando y

compartiendo una historia simple de cmo todo el


sistema funcionar.

Las Prcticas
Diseo simple: el sistema debe disearse tan

simple como sea posible en un momento dado. La


complejidad extra debe removerse tan pronto
como se descubra.
Prueba: los programadores continuamente
escriben pruebas unitarias, que deben correr sin
falla para que el desarrollo contine. Los clientes
escriben pruebas que demuestren que las
caractersticas estn terminadas.
Mejora interna: los programadores reestructuran
el sistema sin cambiar su comportamiento, para
remover duplicidades, mejorar la comunicacin,
simplificar y agregar flexibilidad.

Las Prcticas
toda la produccin
de cdigo es escrita con dos programadores en
cada mquina.
Propiedad colectiva: cualquiera puede
cambiar cualquier cdigo en cualquier parte del
sistema en cualquier momento.
Integracin continua: integrar y construir el
sistema muchas veces al da, cada vez que una
tarea sea terminada.
Programacin por pares:

Las Prcticas
40 horas a la semana: como regla, no

trabaje ms de 40 horas a la semana. Nunca


trabaje con sobretiempo dos semanas
seguidas.
Cliente en el lugar: incluya un usuario real,
en persona, dentro del equipo, disponible a
tiempo completo para responder preguntas.
Estndares de programacin: los
programadores escriben cdigo de acuerdo con
reglas que enfatizan la comunicacin a travs
del propio cdigo.

El ciclo de vida de un proyecto


ideal
El proyecto ideal de la Programacin Extrema
(XP) pasa a travs de una muy corta fase de
desarrollo inicial, seguida por aos de un soporte
de produccin y refinamiento simultneos, y
finalmente un elegante retiro cuando el proyecto
ya no tiene mayor sentido.
Exploracin
Planeamiento
Iteracciones para la primera versin

Produccionamiento (Produccin y Refinamiento)

Mantenimiento
Muerte

El ciclo de vida de un proyecto


ideal
EXPLORACIN
No estar en produccin es estar gastando
dinero sin estar haciendo dinero.
Antes de ir a produccin, sin embargo, uno
debe estar seguro que puede ir a produccin,
tener suficiente confianza en las herramientas
que utilizar y que se tienen las habilidades
necesarias.
En la fase de exploracin es cuando todo esto
sucede y dura una pocas semanas.

El ciclo de vida de un proyecto


ideal
PLANEAMIENTO
El propsito de la fase de planeamiento es que
los clientes y programadores lleguen a un
acuerdo confiable sobre una fecha, la ms
corta posible, en la que las caractersticas ms
valiosas estn concluidas.
Si ha habido una buena preparacin durante la
exploracin, el planeamiento (produccin del
calendario de compromisos) debe tomar un da
o dos.

El ciclo de vida de un proyecto


ideal
ITERACIONES PARA LA 1ra. VERSIN

El calendario de compromisos se divide entre


1 a 4 cuatro iteraciones de una semana. Cada
iteracin produce un juego de casos de
pruebas funcionales para cada caracterstica
incluida en el calendario para esa iteracin.
Al final de la ltima iteracin estamos listos
para ir a produccin.

El ciclo de vida de un proyecto


ideal
PRODUCCIONAMIENTO
(PRODUCCION Y REFINAMIENTO)

El juego final de una versin enfrenta un


intenso ciclo de retroalimentacin. Se deberan
tener reuniones diarias para que todos sepan
en que estn trabajando los dems.
Durante esta fase se desacelera la evolucin
del software y se valora ms el riesgo que
cualquier modificacin pueda introducir.

El ciclo de vida de un proyecto


ideal
MANTENIMIENTO
El mantenimiento es el estado normal de
cualquier proyecto de Programacin Extrema.
Se debe simultneamente producir nueva
funcionalidad, mantener el sistema actual en
ejecucin e incorporar nueva gente al equipo.

El ciclo de vida de un proyecto


ideal
MUERTE
Morir bien es tan importante como vivir bien.
Si al cliente ya no se le ocurren nuevas
caractersticas que introducir, es tiempo de
poner el sistema en naftalina.
Hay otras razones para salir de circulacin, el
sistema ya no se justifica econmicamente.

Roles para la gente

Programadores
Clientes
Probadores
Rastreadores
Entrenadores
Consultores
Gran jefe

Qu hace tan difcil la Programacin


Extrema (XP)?
An cuando las prcticas individuales
pueden ser ejecutadas por programadores
obreros, poner todas las piezas juntas y
mantenerlas juntas es difcil.
Son principalmente las emociones
especialmente el miedo lo que hace la
Programacin Extrema (XP) difcil de adoptar.

Cundo no intentar usar la


Programacin Extrema (XP)?
Los lmites exactos de la Programacin
Extrema an no estn del todo claros.
Pero hay algunos casos destacables en los
que es mejor evitar su uso: equipos muy
grandes, clientes desconfiados y
tecnologas que no soporten el cambio
elegantemente.

Cmo organizarnos para


Programacin Extrema (XP)?

CASO PRCTICO

Modelo de Organizacin

Los 6
Elementos
4

Modelo de Organizacin

Comit de
Direccin

Comit de
Riesgos

rea de produccin a
rea de produccin b
rea de produccin c
.
rea de produccin d

rea de investigacin f
rea de investigacin g
rea de investigacin h
rea de investigacin i

Canales de comunicacin

Comit de
Talento

TO
N
E
L
A

1
Lder 9

Lder 8

Lder 7

Lder 6

Lder 5

Lder 4

Lder 3

Lder 2

Canales de Comunicacin
Lder 1

Produccin
Investigacin

Comit de
Cliente

Canales de Comunicacin

rea de produccin e

T
E
M

T
I
C
A
S

Comit de
TI

Canales de comunicacin

R
E
A
S

COMITS

LDERES DE PROYECTO

Tutor A
Tutor B
Tutor C
Tutor D
Tutor E

Tutor F
Tutor G
Tutor H
Tutor I

T
U
T
O
R
E
S

Conclusiones
Todas las metodologas estn basadas en el
miedo. Uno trata de establecer hbitos que
eviten que nuestros temores se hagan realidad.
La diferencia est en los miedos que estn
incrustados en la Programacin Extrema (XP).
Yo tengo miedo a:
Hacer el trabajo que no importe.
Tener proyectos cancelados por falta de progreso
tcnico.
Tomar malas decisiones en el negocio.
Tener gente del negocio tomando malas decisiones
tcnicas.
Hacer un trabajo del que no me sienta orgulloso.

Conclusiones
La Programacin Extrema (XP) tambin
refleja cosas a las que no les tengo
miedo:
Codificar.

Cambiar mi mente.
Proceder sin saber todo respecto al futuro.
Confiar en otra gente.
Cambiar el anlisis y diseo de un sistema en

ejecucin.
Escribir pruebas.

Enlaces de inters
Historia y orgenes de la Programacin
Extrema (XP)
http://www.agilespain.com/modules.php?op=modload&
name=Sections&file=index&req=viewarticle&artid=1&
page=1
http://gmodulo.sourceforge.net/docs/html/manual/ch
02s04.html#manual-methodology-312

corvus@usmp.edu.pe
Si deseas una copia de estas diapositivas
ingresa a: http://

es.mayeticvillage.com/corvus
Luego ingresa a la opcin Transferencias
Pblicas para descargar este archivo.

USMP

Programacin Extrema

Max Ugaz (Ma.)


Director de CORVUS-USMP
corvus@usmp.edu.pe