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
Top Related