Charla de introducción a XP para Ágiles Rosario dentro la semana de la Agilidad del 2020

1. Introducción a
eXtreme
Programming

2. Andres Joaquin
andresjoaquin@gmail.com
@andrescjoaquin
Camilo Garaventa
camilogaraventa@gmail.com

3. 1 – Presentación
2 – ¿Por que eXtreme Programming?
3 – Audiencia
4 – Historia y origenes
5 – Valores, Principios y Practicas
6 – Unit Testing
7 – TDD
8 – Integración Continua (si el tiempo lo permite)
9 – Cierre
Agenda

4. ¿Por qué elegimos eXtreme
Programming para esta sesión?

5. ¿Audiencia?

6. Historia de eXtreme Programming
La programación
orientada a
objetos emerge
como paradigma
dominante
El Proyecto C3
empieza en
Chrysler y lo
llevan a Kent
Beck como lider.
Ward
Cunningham y
Ron Jeffries se
suman
Martin Fowler
también colaboro.
Primer
publicación de
eXtreme
Programming
Explained
Se cancela el
Proyecto C3
cuando Daimler-
Benz compra
Crysler
Estuvo en
producción desde
1997
Se firma el
manifiesto agil.
Beck,
Cunningham y
Jeffries son
firmantes.
También Martin
Fowler.
Segunda
publicación de
eXtreme
Programming

7. Kent Beck en estos días

8. XP según su creador
“XP es un estilo de desarrollo de software que
se enfoca en una excelente aplicación de
técnicas de programación, comunicación clara y
trabajo en equipo lo que nos permite lograr
cosas que antes ni siquiera podíamos imaginar”

9. Valores, Principios y Practicas
Comunicación
Simplicidad
Feedback
Valentía (Courage)
Respeto (2004)
Cambios incrementales (Flow)
Calidad
Humanidad (2004)
Diversidad
Mejora
Reflexion
…
Equipo Completo (Whole Team)
Pair Programming
Ciclos semanales
Integración Continua
Refactoring
TDD
Semana de 40hs
Diseño Incremental
Slack
…
Ejemplo: Comunicación, Feedback >> Humanidad >> Pair Programming

10. Unit Testing
Es una forma de comprobar el correcto
funcionamiento de una unidad de código.
Se utiliza para verificar una unidad mínima de
código fuente. Su propósito es aislar la parte
más pequeña y testeable de una API y verificar
que funciona de forma adecuada.
Es código que prueba otro código.

11. Unit Testing – Características
[F]ast
[I]solated
[R]epeatable
[S]elf-validating
[T]imely

12. Test-Driven Development
1. No escribir código productivo hasta que no
se haya escrito un test unitario fallido.
2. No escribir más de un test unitario que falle
su resultado o que falle al compilar.
3. No escribir más código productivo que el
mínimo necesario para hacer pasar el test
que falla.

13. Test-Driven Development - RGB
TDD
1 – Escribir un test y
verlo fallar
2 – Escribir el Código
mínimo necesario para
que el test pase
3 – Mejorar el código sin
cambiar su comportamiento

14. Continuous Integration
Los programadores integran su código
múltiples veces por día.
Luego de cada integración se compila el
sistema de punta a punta, se corren todos los
tests y se despliega a un ambiente de prueba.

15. Bibliografia

16. Links
Github del ejemplo de TDD
https://github.com/andresjoaquin/Introduccion-TDD
Azure DevOps del ejemplo de CI
https://andresjoaquin.visualstudio.com/Introducci%C3%B3n%20CI/
Telegram de Agiles Rosario
https://t.me/AgilesRosario

17. Andres Joaquin
andresjoaquin@gmail.com
@andrescjoaquin
Camilo Garaventa
camilogaraventa@gmail.com
¡Gracias!

18. Equipo Completo (Whole Team)
Managers, clientes, desarrolladores trabajan
juntos, cerca unos de otros, conociendo los
problemas de todos y colaborando para
resolverlos.
Para XP el cliente es parte del equipo y por
ende debe estar disponible para el mismo.

19. User Stories
Una user story es un recordatorio de una
conversación en curso sobre un
requerimiento. Es una herramienta de
planificación que el cliente utiliza para
planificar la implementación de un
requerimiento en base a su prioridad y su
costo estimado.

20. Short Cycles
Un proyecto XP entrega software funcionando
cada dos semanas. Al final de cada iteración el
sistema es mostrado a los stakeholders para
recibir feedback.

21. Pair Programming
El código se escribe por un par de
programadores trabajando juntos en el mismo
puesto de trabajo. Uno maneja el teclado y
codifica y el otro mira lo que se está
escribiendo encontrando errores y mejoras.
Interactúan intensamente. Cambian de roles
frecuentemente.

22. Collective Ownership
Cualquier miembro del equipo puede tomar
un módulo y mejorarlo. Ningún programador
es responsable individualmente por un
módulo o tecnología en particular.

23. Energized Work (Semana de 40hs)
El equipo debe ir a una marcha moderada
sostenida. No se permite que el equipo
trabaje tiempo extra.

24. Sit Together
El equipo trabaja todo junto en una misma
habitación.
Todos tienen la oportunidad de escuchar
cuando alguno tiene algún problema.
Las paredes se encuentran cubiertas con
gráficos de estado, diagramas, etc.

25. Simple Design
Utilizar el diseño más simple posible.
1. Considerar la cosa más simple que podría
funcionar.
2. No vas a necesitarlo. Enfocarse sólo en las
necesidades de las user stories involucradas
en la iteración actual.
3. Una única vez. No se tolera la duplicación de
código.

26. Refactoring
Realizar series de pequeñas transformaciones
para mejorar la estructura del sistema sin
afectar su comportamiento.

27. Metaphor
Es una gran imagen que une a todo el sistema.
Es la visión del sistema que hace la
localización y la forma de todos los módulos
individuales obvia.