Este documento describe las prácticas ágiles utilizadas por un equipo de desarrollo móvil, incluyendo el uso de Scrum, iteraciones de una semana, reuniones diarias, demostraciones y retrospectivas semanales. También discute el uso de herramientas como JIRA y control de versiones git, así como técnicas de desarrollo como testeo dirigido por pruebas y principios de diseño de software.
10. Reunión Scrum diaria
● Hora fijada, 9:15am
● De pie
● Cada uno:
○ ¿Qué hice ayer?
○ ¿Qué voy a hacer?
○ Problemas
● Burndown
11. Demo
● Viernes a la tarde
● Compilar alphas de antemano
● Tarde: 1€/5 min
● Demostrar bugs
● Demostrar tareas
● Agrupar por funcionalidad
● Apuntar nuevos bugs
● ¡Cuidado con alargarse!
13. Planificación de Sprint
● Reordenar tareas
● [Planning poker]
● Valoramos los bugs: cantidad y dificultad
● Elegimos cuánto entra
14. Planning Poker
● Leemos el nombre de la historia
● Explicamos su alcance
○ Surgen preguntas interesantes
● Estimación individual
● Discusión de discrepancias
● Acuerdo
19. Tips (Do's & Don'ts)
Si nos excedemos en el uso de TDD, pueden
darse malas prácticas.
20. Tips (Do's & don'ts)
● Abusar de los mocks
a. Los test se vuelven tediosos de mantener
b. Acabamos probando el resultado de los mocks en
lugar del SUT
c. Probablemente la clase a implementar tenga
demasiados parámetros.
21. Tips (Do's & Don'ts)
Esto nos lleva a tener clases poco usables (y
que induce a errores)
24. Tips (Do's & Don'ts)
● Hacer tests de implementaciones concretas
en lugar de guiarnos por las
especificaciones
○ Suele ocurrir cuando hacemos tests después de
implementar
○ Por ejemplo: si una clase realiza acciones sobre un
Collection, no hacer los tests asumiendo que
recibiremos un ArrayList. Podríamos recibir un
TreeSet y debería funcionar (Principio de
sustitución de Liskov)
25. Tips (Do's & Don'ts)
● Otras malas prácticas:
○ Introducir dependencias entre tests
○ "Romper" las reglas para maximizar la cobertura de
los tests (ej: comprobar métodos privados)
○ Limitarse a probar los resultados esperables. Las
excepciones y los casos límite son importantes.
○ No refactorizar las clases de tests unitarios.
26. Lecciones positivas
Aplicar los principios del TDD en el día a día
nos ha enseñado valiosas lecciones
● Buenas prácticas de desarrollo
○ Principios SOLID
● Criterios de nombrado de clases,
métodos…
● El valor de hacer refactor
● Un estilo de programación común
38. En definitiva...
● TDD es una herramienta de trabajo
○ Bien usado ayuda a escribir buen código y facilita
su mantenimiento
○ Usado en exceso da lugar a problemas y se
convierte en una carga
● Si una herramienta resulta una carga, no
hay que temer en abandonarla
39. ¿Cuándo usaríamos TDD?
Librerías/APIs
● Código estable con pocos cambios en el
futuro
● Documentación para el cliente
Nuevos proyectos
● Utilidades: clases de peticiones a red, base
de datos, helpers...
42. Trabajo en equipo
● ¿Colaborar y compartir sin dolores de
cabeza?
¿ ?
43. Trabajo en equipo
● Modelo de ramas
git-flow
● Adaptado
○ Desarrollo: «3.5.x»
○ Maintenance: «3.4.x-maintenance
»
○ Cada funcionalidad
una rama:
«feature/user-list»
47. Trucos
● git merge --no-ff
○ Preserva la estructura de
ramas
○ Por defecto git aplasta
(squash) los commits
● git rebase -vip
○ [v] Verbose
○ [i] Previsualizar y modificar
qué commits se aplican
○ [p] Conservar el árbol de
commits
48. Trucos
● gitx
○ Interfaz visual
● git mergetool
○ Indispensable para resolver
conflictos
● git commit --amend
○ Arregla el último commit
○ Añadir cambios olvidados
○ Cambiar el nombre del commit
49. Trucos
● git cherry-pick
○ Intenta aplicar los cambios de un commit
cualquiera
○ Útil para aplicar un parche de una rama a otra
● git blame
○ ¡WTF! ¿Quién ha hecho semejante burrada?
○ Quién, cuándo y en qué commit se cambió
cada línea