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.

1. Un día en un equipo ágil
de desarrollo móvil
Javier Armendáriz
Mikel Elorz

2. ¿De dónde venimos?
Tus tarjetas de fidelización en el móvil

3. ¿Qué hacemos?

4. ¿Qué vamos a contar?
● Metodología Ágil: Scrum
● Test Driven Development (TDD)
● Control de versiones
● Preguntas

5. Metodología Ágil
Scrum

6. Herramientas
JIRA + JIRA Agile
● 20$ - 10 usuarios

7. Herramientas
Tablón físico

8. Tareas
● Tipo
○ Bugs
○ Historias
○ Improvements
● Historias desde un punto de vista
● Bugs describen el problema

9. Iteraciones
1 semana
● Reunión Scrum diaria
● Demo
● Retrospectiva
● Planificación de Sprint

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!

12. Retrospectiva
¿Qué ha ido bien?
¿Qué ha ido mal?
¿Qué se puede mejorar?

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

15. Test Driven Development
TDD

17. ¿Porqué?
Al principio usábamos TDD siempre que
podíamos
● Inexperiencia
○ Al plantear los tests
○ En el lenguaje de programación

18. TDD no es el Santo Grial de la
programación

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)

22. Tips (Do's & Don'ts)
Over-engineering

23. Tips (Do's & Don'ts)

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

29. Single responsibility principle
ScanIM
CardPoints
RewardCatalog
Promos
CardImage

31. Open-Close principle
BaseActionBarActivity
DialogActivity
RequestHandlerActivity

33. Liskov substitution principle

35. Interface segregation principle

37. Dependency inversion principle

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...

40. Control de versiones

41. ¿Cuál escoger?
$ git + Bitbucket

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»

44. Trabajo en equipo
Evitar:
conflictos++

45. Trabajo en equipo
Solución: rebase

46. Trabajo en equipo
Resultado:
conflictos--

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

50. Trucos
git config --global alias.hist "log --color --graph --
pretty=format:'%Cred%h%Creset |%C(yellow)%d%Creset %s %
Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
git hist

51. ¿
¿?
? ?
?
¿ ?
?
¿?
¿?
?
¿
?
?
¿?
?
?
?
¿
?
¿?
?
¿?
¿
?
¿
?
?
¿
¿
?
?
Preguntas
Descarga: bit.ly/quomai-agile-slides