Un día en un equipo ágil de desarrollo móvil

Javier ArmendárizMikel Elorz

¿De dónde venimos?

Tus tarjetas de fidelización en el móvil

¿Qué hacemos?

¿Qué vamos a contar?

● Metodología Ágil: Scrum● Test Driven Development (TDD)● Control de versiones

● Preguntas

Metodología Ágil Scrum

Herramientas

JIRA + JIRA Agile● 20$ - 10 usuarios

Herramientas

Tablón físico

Tareas

● Tipo○ Bugs○ Historias○ Improvements

● Historias desde un punto de vista● Bugs describen el problema

Iteraciones

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

Reunión Scrum diaria

● Hora fijada, 9:15am● De pie● Cada uno:

○ ¿Qué hice ayer?○ ¿Qué voy a hacer?○ Problemas

● Burndown

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!

Retrospectiva

¿Qué ha ido bien?¿Qué ha ido mal?

¿Qué se puede mejorar?

Planificación de Sprint

● Reordenar tareas● [Planning poker]● Valoramos los bugs: cantidad y dificultad● Elegimos cuánto entra

Planning Poker

● Leemos el nombre de la historia● Explicamos su alcance

○ Surgen preguntas interesantes● Estimación individual● Discusión de discrepancias● Acuerdo

Test Driven Development TDD

¿Porqué?

Al principio usábamos TDD siempre que podíamos

● Inexperiencia○ Al plantear los tests○ En el lenguaje de programación

TDD no es el Santo Grial de la programación

Tips (Do's & Don'ts)

Si nos excedemos en el uso de TDD, pueden darse malas prácticas.

Tips (Do's & don'ts)

● Abusar de los mocksa. Los test se vuelven tediosos de mantenerb. Acabamos probando el resultado de los mocks en

lugar del SUTc. Probablemente la clase a implementar tenga

demasiados parámetros.

Tips (Do's & Don'ts)

Esto nos lleva a tener clases poco usables (y que induce a errores)

Tips (Do's & Don'ts)

Over-engineering

Tips (Do's & Don'ts)

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)

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.

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

Single responsibility principle

ScanIM

CardPoints

RewardCatalog

Promos

CardImage

Open-Close principle

BaseActionBarActivity

DialogActivity

RequestHandlerActivity

Liskov substitution principle

Interface segregation principle

Dependency inversion principle

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

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

Control de versiones

¿Cuál escoger?

$ git + Bitbucket

Trabajo en equipo

● ¿Colaborar y compartir sin dolores de cabeza?

¿ ?

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»

Evitar:

conflictos++

Trabajo en equipo

Trabajo en equipo

Solución: rebase

Trabajo en equipo

Resultado:

conflictos--

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

● 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

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

Trucos

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

?¿?

?

¿ ?

¿?

¿?

?

¿

¿ ?

?¿??

??

¿

?

?

¿?

?¿?

¿

?¿

???

¿

¿?

?

Preguntas

Descarga: bit.ly/quomai-agile-slides