Slide 1
Slide 1 text
Agile Methods
y
eXtreme Programming
Javier Garzás
[email protected]
[email protected]
Slide 2
Slide 2 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
De Nada a lo Monumental y a lo Ágil
§ La mayoría del desarrollo software
actual se caracteriza por…
Actividad Caótica
“Code and Fix”
Esto no
funciona en
proyectos
grandes
Slide 3
Slide 3 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
De Nada a lo Monumental y a lo Ágil
§ La Metodología:
- Nace para
solucionar los
problemas
anteriores
- Produce disciplina
- Mas predecible
- Más eficiente
Todo resuelto
…
(¿Seguro?)
Slide 4
Slide 4 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
De Nada a lo Monumental y a lo Ágil
Por lo anterior se les denomina
“Metodologías pesadas (hightweight)” o
“Metodologías Monumentales” (J. Highsmith).
Principal crítica:
Burocracia: tantas cosas que desarrollar que la
velocidad de desarrollo baja.
Slide 5
Slide 5 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
De Nada a lo Monumental y a lo Ágil
Para reaccionar al anterior problema
aparecen otras metodologías, denominadas
“Metodologías de peso ligero” y ahora
“Metodologías Ágiles”
Reacción ante la burocracia.
Compromiso entre el no proceso y el
proceso monumental.
No están orientadas por la documentación,
enfatizan poca documentación.
Slide 6
Slide 6 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Diferencias entre lo Pesado y lo Ágil
Ágiles
Pesados
Predictivos Adaptativos
Bienvenido el cambio,
adaptación y
evolución en el
cambio.
Orientados a la gente
Orientados al proceso
Trabajan bien hasta que
cambian las cosas, su
naturaleza es restringir el
cambio.
Plan largo y
documental
Plan corto y casi
sin documentos
Slide 7
Slide 7 text
El error de lo predecible
Slide 8
Slide 8 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Error 1: Separación de Diseño y Construcción
§ La inspiración inicial partió de las ingenierías clásicas
(mecánica, civil, etc.):
- Enfatizan la planificación antes de la construcción.
- Planos precisos.
- La construcción tiene poca destreza intelectual y más manual, por
tanto existen dos actividades diferenciadas: el diseño y la
construcción (fácil de predecir).
§ Está es la aproximación de muchas metodologías
software
- El diseño pretende controlar la implementación
- En software las notaciones de diseño, como UML, pretenden hacer
todas las decisiones de diseño y construir un plan de construcción
Slide 9
Slide 9 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Cuestiones cruciales
§ ¿Se puede conseguir un diseño capaz de poder moldear
la codificación en la actividad de construcción?
§ ¿Cómo de difícil es conseguir un diseño UML en un
estado para poder pasarse a los programadores?
El diseño UML puede ser correcto en papel, pero
erróneo para la codificación.
A los diseños mecánicos no les sucede esto pues están
soportados por las matemáticas.
§ Además, en software, el tiempo (coste) de codificación es
menor al de diseñar, esto no ocurre en otras ingenierías
Slide 10
Slide 10 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Conclusiones
§ En Software el diseño requiere creatividad y talento.
§ Los procesos creativos no son fáciles de planificar,
§ La predictibilidad puede ser imposible.
Deberíamos ser muy cuidadosos a la
hora de hacer símiles entre
ingenierías clásicas e ingeniería del
software. Son actividades diferentes
y requieren procesos diferentes
Slide 11
Slide 11 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Error 2: Lo impredecible de los requisitos
§ Comprender los requisitos es duro
§ Uno de los motivos es la naturaleza intangible del
software: sólo cuando se usa una primera versión se
comprende qué es valioso y qué no lo es
§ Si esperásemos a tener un conjunto de requisitos
estables estaríamos muertos
Economía, principal fuerza del negocio
Buenos requisitos ahora no lo serán mañana
Algunos requisitos de negocios son impredicibles
Slide 12
Slide 12 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Error 2: Lo impredecible de los requisitos
Si los requisitos no son
estables…
¡No se puede predecir un plan!
Slide 13
Slide 13 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Cómo controlar un proceso impredecible
§ Entonces, si no tiene sentido un proceso
predecible… ¿cómo controlar?
- Lo más difícil es saber dónde estamos.
- Necesitamos un mecanismo de feedback que nos diga donde
estamos a intervalos frecuentes,
- la clave de este feedback es el desarrollo iterativo (esto no es
nuevo, ha tenido muchos nombres, espiral, evolucional,
incremental, etc.).
- Producir versiones de trabajo con un subconjunto de las
características requeridas.
- Cómo de largas son las iteraciones: En XP de 1 a 3 semanas, en
SCRUM un mes, etc.
Slide 14
Slide 14 text
El mito de la metodología única
Slide 15
Slide 15 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Mito: "A methodology per project"
§ Son necesarias múltiples metodologías
dependiendo del tamaño del proyecto (gente a
coordinar), lo crítico del sistema y las prioridades
del proyecto.
§ Cada proyecto merece su propia metodología y
a medida.
§ “Peso ligero” y comunicación cara a cara son
atributos deseables.
Slide 16
Slide 16 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
4 principios en el diseño de una metodología
§ Grandes metodologías para grandes equipos.
§ Densas metodologías para los proyectos más críticos.
§ El peso es costoso.
§ La comunicación interactiva y cara a cara es la más
efectiva.
Slide 17
Slide 17 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Una metodología precisa un alcance definido
envisioning proposal sales setup requirements design & code test deploy train alter
Project Lifecycle
designer/programmer
writer
tester
reuse point
UI expert
lead designer
business expert
expert user
project manager
project sponsor
trainer
secretary
contractor
night watchman
janitor
Roles
Activities rest and recreation
project development
timesheets
technical education
vacations and basic business
Slide 18
Slide 18 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Metodología, seleccionar en función de…
Number of people involved
Criticality (defects cause loss of...)
Comfort
(C)
Essential
money
(E)
Life
(L)
+20%
. . . Prioritized for Legal Liability
1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000
C6 C20 C40 C100 C200 C500 C1000
D6 D20 D40 D100 D200 D50 D1000
E6 E20 E40 E100 E200 E500 E1000
L6 L20 L40 L100 L200 L500 L1000
Prioritized for Productivity & Tolerance
Discretionary
money
(D)
XP
Slide 19
Slide 19 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Errores estándars
1. Sólo un tamaño de metodología… los
proyectos varían
2. Metodología intolerante… la gente varía
3. Embellecer
4. Pesado… menos escribir
5. No probada
Slide 20
Slide 20 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Principales metodologías Ágiles
§ XP (Extreme Programming)
§ Crystal Family
§ Adaptive Software Development
§ SCRUM
§ Feature Driven Development
§ DSDM (Dynamic System Development
Method)
Slide 21
Slide 21 text
eXtreme Programming
Slide 22
Slide 22 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Definición
§ XP es una deliberada y disciplinada aproximación
light al desarrollo software
§ Formada por pequeñas reglas o guidelines que
juntas crean una nueva disciplina de desarrollo
§ Principal autor:
- Kent Beck
§ Proyecto origen:
- “Chrysler Comprehensive Compensation” (C3),
iniciado en 1990 y convertido a XP en 1997. Para el
salario de 10000 empleados
Slide 23
Slide 23 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
“XP es el movimiento más importante
hoy en nuestro campo. Predigo que
será tan esencial para la presente
generación como el SEI y su CMM lo
fueron en el pasado”
Tom DeMarco
Slide 24
Slide 24 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La polémica XP
§ XP cambia las asunciones comunes sobre el desarrollo
software
§ NO al desarrollo up-front (Análisis, Diseño, etc.)
§ NO escribir y mantener documentación
NO a los CASEs
§ NO a las técnicas de diseño cómo UML, principios y
patrones
§ Para sus detractores es volver al “code and fix”
Slide 25
Slide 25 text
La asunción fundamental de XP
y
el error de un proceso predecible
Slide 26
Slide 26 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste : cambio de asunción
§ La histórica curva del cambio
Cambio cuando hay un
error
Los métodos
tradicionales se han
centrado en la
prevención de errores
en fases tempranas
Slide 27
Slide 27 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste: cambio de asunción
§ El diseño anticipado (antes de codificar)
- crea facilidades extra para anticipar futuros
requisitos (cambios)
- Invertir tiempo presente para tiempo futuro.
- Asume que un poco de tiempo ahora ahorrará
mucho después
Pero, pudiera ser más rápido diseñar después
(rediseñar el código), cuando ya sabemos de verdad
que es lo que hay que cambiar y no tenemos que
adivinarlo
Slide 28
Slide 28 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste: cambio de asunción
§ La nueva curva del cambio
En los entornos de
hoy NO podemos
prevenir lo que no
conocemos
Los cambios
aparecen
iterativamente
Slide 29
Slide 29 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste: cambio de asunción
§ Diseñar después…Rediseñar…Refactoring
§ Refactoring: “cambio hecho a la estructura
interna del software para hacerlo más fácil de
entender y más barato de modificar sin cambiar
su comportamiento observable” (Fowler)
§ Si los cambios son continuos nunca
completaremos un desarrollo software
tradicional
§ ¡¡Cuánto más impredecibles sean los cambios
más diseño anticipado derrocharemos!!
Slide 30
Slide 30 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste: cambio de asunción
§ Era pre-Internet:
Ratio de cambio bajo
Más Anticipatory
Design
que Refactoring
puede ser razonable
Slide 31
Slide 31 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La curva del coste: cambio de asunción
§ En la actualidad
Ratio de cambio
alto
Se impone el diseño
a posteriori, el
Refactoring
Según esta idea el
Diseño (UML)
pierde sentido
Slide 32
Slide 32 text
Sobre la Planificación / Gestión
de
proyectos XP
(Planning XP)
Slide 33
Slide 33 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La idea subyacente en XP: Riesgo
§ El calendario varía: “el software no estará hasta dentro de 6
meses”
§ Proyecto cancelado.
§ Ratio de defectos: tantos defectos que el software deja de
usarse
§ Incomprensión del negocio: el software es puesto en
producción pero no soluciona el problema de negocio para el
que se propuso
§ Rotación de personal: los programadores empiezan a odiar el
programa y se van
El problema básico del desarrollo software es
el RIESGO
Slide 34
Slide 34 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
La idea subyacente en XP: Riesgo
“El desarrollo software falla en las entregas,
y falla al entregar valor. Este fallo tiene
terrible impacto económico y humano.
Necesitamos otra manera de desarrollar
software”
Kent Beck
Slide 35
Slide 35 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
XP, el Miedo
§ Debido al miedo debe imponerse
un proceso software
El desarrollo software es un riesgo. La gente
involucrada tiene miedo de lo que pueda salir mal.
Para desarrollar eficientemente necesitamos
reconocer ese miedo
Slide 36
Slide 36 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Explicitación de los miedos
Miedos del Cliente
No conseguir lo que pidieron
De pedir algo equivocado
Pagar demasiado
A técnicas que no controlan
Nunca ver un plan significativo
No saber que ocurre
No poder rehacer sus decisiones
No saber la verdad
Miedos del Desarrollador
Se les pedirá más de lo que saben hacer
Se les pedirán cosas sin sentido
De ser muy estúpidos
Caer por la técnica
Tomar responsabilidad sin autoridad
Definiciones no claras
Sacrificar calidad por plazos
Solucionar problemas complejos sin ayuda
No tener tiempo para finalizar con éxito
Slide 37
Slide 37 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El cliente tiene derecho a…
§ un plan general, a saber qué puede realizarse, cuándo y
a qué coste.
§ conseguir el mayor valor posible de cada semana de
programación
§ ver la evolución en un sistema ejecutable,
§ cambiar de opinión, sustituir funcionalidad, y cambiar
prioridades sin pagar un coste exagerado
§ ser informado de cambios en la agenda, en tiempo para
escoger como reducir el alcance para retornar a la fecha
original.
§ Puede cancelar en cualquier momento y quedarse con
un sistema que trabaje de forma útil que refleje la
inversión hasta la fecha.
Slide 38
Slide 38 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El programador tiene derecho a…
§ saber lo que es necesario, con claras declaraciones
de prioridad
§ producir trabajo de calidad en todo momento.
§ pedir y recibir ayuda de iguales, managers y clientes.
§ hacer y modificar sus propias estimaciones.
§ aprobar sus responsabilidades en vez de que sean
asignadas.
Slide 39
Slide 39 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las cuatro variables
§ Para controlar un proyecto software
existen cuatro variables:
Coste
Tiempo
Calidad
Alcance
Slide 40
Slide 40 text
El proceso de desarrollo XP
Slide 41
Slide 41 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Los cuatro valores
§ Comunicación:
- XP enfoca construir persona a persona, mutua comprensión
del entorno del problema mediante mínima información
documental y máxima interacción cara a cara
§ Simplicidad
- Hacer las cosas lo más simple posibles
- YAGNI (You aren’t going need it)
- Trabajar en una cosa errónea temprano es más derrochador
que trabajar en la solución correcta después
- Diseño complejo = dificil de entender = dificil de modificar
- Según esto… ¿los patrones no tienen sentido?
Slide 42
Slide 42 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Los cuatro valores
§ Feedback
- La aceptación del cambio ocurre por el constante
feedback
- Feedback vs feedforward
§ Coraje
Slide 43
Slide 43 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las 12 prácticas
§ Planning Game: Tres semanas por ciclo
y asignando historias (características
requeridas)
§ Small release: los más pequeñas y con
el mayor valor de negocio
§ Metaphor: descripción general del
proyecto
Slide 44
Slide 44 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las 12 prácticas
§ Diseño simple:
- Diseñar sólo la funcionalidad requerida, NADA de futura
funcionalidad
- Crear el diseño que mejor pueda comunicar esa
funcionalidad
- “Si el futuro es incierto y puedes cambiar tus
pensamientos fácilmente entonces poner funcionalidad
especulante es de locos”
§ Refactoring:
- El rediseño continuo mejora la respuesta al cambio
§ Testing
Slide 45
Slide 45 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las 12 prácticas
§ Pair Programming
§ Posesión colectiva:
- Cualquiera del proyecto puede cambiar cualquier
código en cualquier momento
§ Integración Continua
§ 40 horas por semana:
- “Don´t burn out the troops” (Hightsmit)
- No más de una semana con sobre tiempo
Slide 46
Slide 46 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las 12 prácticas
§ On-site Customer
§ Coding standars
Slide 47
Slide 47 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El ciclo XP
Slide 48
Slide 48 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El ciclo XP
Slide 49
Slide 49 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El ciclo XP
Slide 50
Slide 50 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
El ciclo XP
Slide 51
Slide 51 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Valores y prácticas
“El éxito de XP no vendrá sólo de
cosas como el pair programming o 40
hour work for week, dependerá de que
principios y valores se alineen con la
organización”
Jim Hightsmit
Slide 52
Slide 52 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
¿Son los patrones 23 errores en XP?
§ La esencia de este argumento es que los patrones son con
frecuencia sobre usados.
§ Son buenas ideas, el problema está en su mal uso.
§ XP puede tratar de otra forma el uso de patrones pero no
los elimina.
§ Los patrones son de vital importancia. Los patrones son las
espina dorsal del conocimiento de diseño, tan
importante como pueda serlo el proceso.
§ Diferentes procesos pueden enfocar el uso de patrones de
diferente manera. XP enfatiza no usar patrones hasta que
sea necesario.
Slide 53
Slide 53 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
¿XP contra UML?
§ Slogan XP:
- “Úselo si es útil” con el sub-texto “Xper no hacen
diagramas”
¡¿Ya no tiene sentido el uso de UML?!
Slide 54
Slide 54 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
XP y UML
§ El problema tiene dos causas:
- Algunas personas encuentran útiles los diagramas
software, otras no. Esto debe ser aceptado.
- Diagramas software tienden a asociarse con procesos
pesados que gastan mucho tiempo dibujando diagramas
que no ayudan y que pueden ser dañinos.
Slide 55
Slide 55 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Cómo usar bien los diagramas
§ Dibujar diagramas para una comunicación efectiva:
- Seleccionar las cosas importantes y pasar por alto cosas menos
importantes:
§ Un problema común con los diagramas es que la gente
tiende ha hacerlos comprensivos. El código es la mejor
fuente de información comprensiva.
§ Cambiar el diseño no implica necesariamente cambiar los
diagramas.
§ Es razonable el dibujar diagramas para comprender el
diseño y después tirarlos. Los diagramas no pueden ser
artefactos.
Slide 56
Slide 56 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
¿XP contra los CASEs?
§ Otro uso de diagramas UML es la documentación,
que generalmente reside en un CASE.
§ La idea es que mantener esta documentación
ayuda a la gente a trabajar en el sistema.
§ Esto en la práctica no funciona:
- Demasiado grandes para actualizarse, mala
sincronización con el código.
- Quedan ocultos en el CASE y nadie los mira.
Slide 57
Slide 57 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Aspectos perniciosos del CASE (R.Devis)
§ Suele ser preferible empezar una determinada técnica “a
mano”, para una tarea o rango de tareas, y después
abordar su automatización.
§ Un procesador de textos no convierte a su usuario en
escritor
§ Claro que “esperar al Mesías” es esperar a alguien que
ya llegó.
§ Se pretende producir menos, no más, software de baja
calidad.
Slide 58
Slide 58 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Aspectos perniciosos del CASE (R.Devis)
§ Las herramientas CASE deben ser adquiridas-usadas
por su adecuación a cada proyecto software concreto.
§ El costo “CASE” debe asimilarse como parte del tributo
por estar en el negocio software.
§ Cuando se analizan e imputan costos CASE a
proyectos software ha de tenerse en cuenta no sólo el
costo directo de la compra, sino también los altos costos
que se hubieran generado de no haber realizado tales
compras.
Slide 59
Slide 59 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
¿Está muerto el Diseño?
§ NO, pero su naturaleza a cambiado. En XP
el diseño:
- Deseo constante por mantener el código lo más claro
posible.
- Refactoring permite hacer las mejoras necesarias de forma
confiada
- Buen conocimiento de patrones: no sólo las soluciones,
también cuando usarlos y cómo evolucionan
- Conocer cómo comunicar el diseño a quien necesita
comprenderlo, usando código, diagramas y lo mejor…
conversando.
Slide 60
Slide 60 text
Conclusiones
Slide 61
Slide 61 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
A tener en cuenta sobre los procesos Ágiles
§ No deben ser usados por todo el mundo,
aunque si deberían usarse por más gente de lo
que ahora los usa.
§ Donde se utiliza mucho un “codifica y prueba”
es más fácil implantar un Ágil que un Pesado.
§ Problema: equipos grandes
§ Deben usarse cuando los requisitos son
volátiles.
§ Barrera importante: el cliente.
Slide 62
Slide 62 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
A tener en cuenta sobre los procesos Ágiles
§ Problema: ¿proyecto grande y requisitos cambiantes?
§ Se debe apostar por los desarrolladores: si estos
están poco preparados y con poca motivación entonces
es preferible un proceso predecible.
§ Si los requisitos son volátiles o inciertos, los
desarrolladores están motivados y son responsables y el
cliente comprende y se involucra, entonces Adaptativo.
§ Con equipos de más de 50 personas, precios fijos o
alcance fijo y contrato cerrado, entonces Predictivo.
Slide 63
Slide 63 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
Las light son mejores pero tienen límites
Light
methodology
Medium
methodology
Heavy
methodology
Personas para
Lograr con éxito el
proyecto
Slide 64
Slide 64 text
Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
“Un experimento nunca puede
ser un fracaso pues siempre
viene a demostrar algo”
T. Alva Edison