El documento proporciona una introducción al eXtreme Programming (XP), una metodología ágil para el desarrollo de software. Describe los principios fundamentales de XP como la comunicación, el feedback continuo, la simplicidad, el coraje y las pequeñas iteraciones. También explica prácticas clave como la programación en parejas, las pruebas unitarias, la integración continua y la propiedad colectiva del código. El documento sugiere que XP ha evolucionado en los últimos 10 años con la adopción de prácticas como la entrega
2. eXtreme Programming
Indice
- ¿Por qué XP?
- ¿Qué es XP?, principios y practicas
- Relación con otros métodos ágiles
- Evolución Importancia de profesionalidad y método
- Quiero saber más! frente a un framework o tecnología pasajera.
Esto te puede cambiar la vida, profesional
claro. No es ninguna exageración.
A mi me la ha cambiado, para mejor
obviamente!.
Alfredo Casado Bernardez
3. eXtreme Programming
Waterfall
No funcionan:
- demasiada documentación
- demasiada burocracia.
- separación de roles. gestores, arquitectos,
programadores, testers, operaciones/sistemas...
- rigidez, el cambio es un problema.
Alfredo Casado Bernardez - ciclo en cascada claramente no sirve.
4. eXtreme Programming
Waterfall
No funcionan:
- demasiada documentación
- demasiada burocracia.
- separación de roles. gestores, arquitectos,
Alfredo Casado Bernardez programadores, testers, operaciones/sistemas...
- rigidez, el cambio es un problema.
- ciclo en cascada claramente no sir ve.
11. eXtreme Programming
Waterfall
Consecuencias, dos posibilidades: Y lo peor no es esto, lo peor es
- Organizaciones grandes intentan seguir métodos cuando hay que hacer cambios!!
clasicos, el resultado son desarrollos que no
satisfacen a nadie.
- Organizaciones más pequeñas que no pueden
permitirse el gasto optan por no seguir estas
metodologias. El resultado es ASM/caos que de nuevo
no deja satisfecho a nadie.
Alfredo Casado Bernardez
12. eXtreme Programming
Kent Beck, el padre de eXtreme programming
Documentación -> la necesaria
Separación de roles -> whole team y comunicación
"..the problem [with software projects]
Mucho tiempo isn'tla primera versión -> se, because una
hasta change, per primera versión en change is
semana, dos como mucho.to happen; the problem, rather,
going
is the con el cambio, topromueve with change
XP no sólo es permisiva inability xp cope el cambio. El
when it comes."
cambio como beneficio no como problema.
Si usamos XP lo hacemos para producir soft ware que sirva mejor a
las necesidades de nuestros clientes, nunca perder esto de vista,
este es el objetivo.
Alfredo Casado Bernardez
13. eXtreme Programming
Valores, simplicidad
El mayor enemigo de cualquier sistema soft ware es la
complejidad. en XP mantener las cosas simples es un
objetivo prioritario. Diseño simple de kent beck:
- pasan los test.
- código revela sus intenciones.
- eliminar TODA duplicación.
- reducir el número de elementos.
Alfredo Casado Bernardez
14. eXtreme Programming
Valores de xp, comunicación
Un proyecto soft ware siempre se realiza en equipo, es
fundamental que los canales de comunicación sean de
banda ancha.
Comunicación entre:
cliente y equipo de desarrollo
entres miembros del equipo
entre programadores y testers
entre programadores y qa
Se trata de eliminar barreras y favorecer la
comunicación directa
Alfredo Casado Bernardez
15. eXtreme Programming
Valores de xp, feedback
Feedback continuo y temprano.
El cliente como parte del equipo esta constantemente
viendo el producto y dando feedback.
Los programadores que usan TDD tienen
constantemente feedback de que su trabajo es
correcto
La integración continua ofrece feedback constante de
que el código de todos se integra correctamente.
Se hacen iteraciones cortas, se obtiene feedback
después de cada iteración.
Alfredo Casado Bernardez
16. eXtreme Programming
Valores de xp, coraje
Hay que echarle huevos al asunto, así de claro. Nadie
dijo que esto fuera a ser fácil. nadie da duros a peseta.
Los grandes beneficios sólo se obtienen a través de
grandes esfuerzos.
Alfredo Casado Bernardez
17. eXtreme Programming
Practicas XP
Feedback Continuous Shared Wellfare
TDD CI Simple design
Planing Game System
Design Metaphor Sustainable
Whole Team Improvement Collective Pace
Small ownership
Pair
Programming releases Coding
Standard
Alfredo Casado Bernardez
18. eXtreme Programming
Whole team
El equipo cuena con todas las habilidades necesarias para
cumplir con su trabajo.
El cliente forma parte del equipo de trabajo. Punto más
polémico sin duda de xp (junto con PP quiza).
En scrum se relaja un poco, el clienete o product owner en
terminología scrum puede ser el propio cliente o un proxy de
este (algo así como un analista funcional o alguien de
nuestra empresa cuyo trabajo sea representar la posición
del cliente).
KB es más radical, si el cliente no quiere cederme a uno de
sus trabajadores para que el proyecto pueda avanzar
entonces no le interesa lo suficiente el proyecto, y en
consecuencia a mi tampoco. (con dos cojo...)
Alfredo Casado Bernardez
19. eXtreme Programming
Planning Game y Small releases
En este punto nos reunimos con el cliente y decidimos
las historias de usuario que van a entrar en la primera
iteración/release.
poner fotillo de nuestro tablon.
La idea es tener lo más rapido algo que funcione para
poder obtener feedback lo antes posible, todo lo
contrario de lo que sucedia en proyectos clásicos.
A veces se usan practicas de scrum o kanban/lean
mezcladas con xp en esta fase.
Alfredo Casado Bernardez
20. eXtreme Programming
System metaphor y walking skeleton
Consiste en empezar el desarrollo con un esqueleto
andante que cubra todos los puntos de la arquitectura
end-to-end. desde el UI hasta la bd por ejemplo en una
aplicación web típica.
El termino WS me parece mucho más acertado,
pertenece a alistair cockburn que lo definió como
parte de su metodología crystal. (este hombre también
se invento lo de la deuda técnica, un crack de las
buenas metaforas :P )
Alfredo Casado Bernardez
21. eXtreme Programming
pair programming
Ya tenemos la planificación de lo que vamos ha hacer y
una metáfora para construir la arquitectura.
El siguiente paso es ponernos ha hacer el trabajo, pero
eso si, no nos ponemos solos!.
Cuatro ojos ven más que dos. PP es revisión de código
llevado al extremo. Práctica polemica pero que da
grandes resultados en algunos contextos.
ayuda a la visión compartida
ayuda a miembros nuevos del equipo
evita relajaciones, hacer PP es cansado.
d
Alfredo Casado Bernardez
22. eXtreme Programming
TDD y simple design
Mi practica favorita, la que más me ha echo crecer como
programador en mi carrera profesional.
fundamental mezclar tdd con SD. En la fase refactor
seguimos las reglas de SD para mejorar nuestro código.
Algunos mitos:
- consume mucho tiempo
- es muy difícil
- no se pueden probar todos los casos
- no me dejan hacer test
Alfredo Casado Bernardez Superado el periodo de aprendizaje desaparecen los mitos
23. eXtreme Programming
Integración Continua
Práctica fundamental en combinación con tdd.
Si integrar frecuentemente es bueno integrar
continuamente es mejor. lógica aplastante...
Cada vez que hago un commit se compila todo el proyecto
y se pasan todos los test.
Hacer commit frecuentes, si haces TDD puedes hacer
commit cada vez que estes en verde.
No hacer commit-and-run, romper el build es entorpecer
al resto del equipo, se castiga con dureza (comprar
chucherias en nuestro caso).
Alfredo Casado Bernardez
24. eXtreme Programming
Collective Code Ownership
El codigo es de todos, no existen islas de conocimiento,
cualquiera puede hacer cualquier tarea.
Una práctica curiosa, poner las tarjetas al reves en la
pared y se escojen a boleo, evita que la gente tienda a
quedarse en su zona de conform.
reduce el factor camion, ¿cuantos miembros de tu equipo
tienen que ser atropellados por un camión para que tu
proyecto se vaya al garete?
Alfredo Casado Bernardez
25. eXtreme Programming
Design Improvement
La regla de los boy scout. deja el campo más limpio de
como lo encontraste.
Recuerda, el código es de todos, no vale eso de “esto esta
fatal lo hizo fulanito”, no amigo, ese código es tuyo, si no
te gusta lo arreglas.
Hace falta coraje.
Boy Scout rule:
Always leave a place cleaner than you found it
Alfredo Casado Bernardez
26. eXtreme Programming
Sustainable pace
Las 40 horas.
No se puede realizar un trabajo que exige un alto de
concentración y tiene un alto grado de complejidad sin
estar a tope de tus facultades.
En ocasiones puede ser razonable un esfuerzo extra, eso
pasa siempre y seguira pasando.
Lo que no es razonable es que ese esfuerzo “extra” se
convierta en norma. Decia KB, si llevas varias semanas
haciendo horas de más para resolver un problema ten una
cosa clara, tienes un problema que no se resuelve con más
horas!!.
Alfredo Casado Bernardez
27. eXtreme Programming
Nadie dijo que fuera fácil
Cuidado con el DIP!
Hay que superar la etapa de aprendizaje para
realmene sacarle beneficio, lo más importante es no
desanimarse.
Los beneficios que obtengas son normalmente
proporcionales al esfuerzo que dedicas en algo.
Exceptuando que te toque la loteria claro!.
Es importante contar con coraje para salir del bache.
Otras opciones es buscar ayuda mediante coaching
para pasar esta fase.
Los beneficios de verdad llegarán despues y merecen la
pena el esfuerzo
Alfredo Casado Bernardez
28. eXtreme Programming
Relación con otros métodos ágiles
ver com encaja xp con otras metodologias como scrum
o las ideas de lean.
No estoy muy seguro si poner esto o no, simplemente
un dibujo, o algo contando que xp es el core de las
practicas de ingeniería y que las practicas de gestión
de proyecto se suelen realizar utilizando ideas de
scrum o kanban/lean.
Alfredo Casado Bernardez
29. eXtreme Programming
En 10 años pasan muchas cosas...
Continuous delivery
10 años son mucho tiempo:
- BDD
- Continuous delivery
- DevOps
- Craftmanship
Alfredo Casado Bernardez
30. eXtreme Programming
En 10 años pasan muchas cosas...
Behavior Driven Development
Nombre Apellidos