Cómo llevar un equipo ágil de Product Development

EasyBroker en númerosEl code base tiene 10 años (empezó con Rails 1)

Más de 1,000 empresas usan EasyBroker

~5 millones de requests por semana

46,995 líneas de código

Lanzamos ~400 releases en 2016 - ~1.5 por día

El Equipo

Me frustraba mucho

Proceso Ideal

Calidad antes de todo

40 horas a la semana

Movemos rápidos

Todos contentos

Es imposible estimar…

Es imposible estimar… precisamente

¿Cómo planeamos?

Metas trimestralesAgregar mensajes

Diseñar un dashboard

Actualizar el flow de signup

Actualizar a Rails 5

Sprint PlanningNos juntamos cada martes

Planeamos esta y la siguiente semana

¿Qué es un Sprint para EB?

Una semana de trabajo

No es un release

Tiene metas semanales

Todos participan

Usamos Pivotal Tracker

Workflow con Pivotal Tracker

Features, Bugs, ChoresBugs siempre tienen prioridad

No puedes mover features al Current/Backlog

Releases

Releases

Lanza releases frecuentemente

Usamos Capistrano para los deploys

Cualquier persona puede hacer un release

No lanzamos el viernes en la noche

Story points0 - cosas super sencillas

1 - cosas sencillas; max 2 horas

2 - sencillas; max 4 horas

3 - media complicadas; max un día

>3 - hay que dividirlo en más stories

Pruebas y QASiempre escribimos pruebas

El autor prueba localmente y en staging antes de entregar

Alguien más tiene que probar el story y aceptarlo

Hacemos pruebas con usuarios

Git Flow

"master" estable

"develop" para el siguiente release

Ramas para features y epics

Code Reviews

Tiempo para refactor

Bueno todavía…Nos olvidamos de dividir los stories complicados

Debemos lanzar suficiente

A veces nadie revisa PRs o acepta stories

ResumenEstamos más contentos

Entregamos muy frecuentemente

Mantenemos una buena calidad de código

Casi nunca trabajamos horarios extras

Gracias@enortham