En los blogs sobre software o metodologías varias solemos contar las bondades del framework que usamos o filosofamos sobre el devenir de la industria pero pocas veces contamos qué tal nos va o qué estamos haciendo exactamente en nuestro trabajo diario. De eso va esta entrada, de cómo trabajamos y de qué hacemos para sacar adelante nuestros proyectos.
Trabajo en DESIC, una empresa de desarrollo de software canaria, en la que llevo trabajando en multitud de proyectos desde hace ya más de 10 años. Llevamos unos cuantos intentando ser un poco más ágiles en cada uno de esos proyectos. De unos se aprendió qué debíamos hacer, de otros aprendimos qué no había que hacer y de lo aprendido en todos ellos hemos llegado al estado actual (mejorable aún, eso seguro). Aquí van unas pinceladas sobre cómo trabajamos en DESIC:
Trac para planificar el sprint
No usamos una de esas populares herramientas de gestión de tableros kanban, ni siquiera tenemos un tablero físico con todas esas pegatinas de colores. Usamos Trac en su lugar. Ya sé que no suena tan cool y que tiene una pinta un poco, digamos, vintage, pero nos funciona y la verdad es que lo hace bastante bien.
Cada dos semanas planificamos las tareas a realizar durante las siguientes dos semanas y las introducimos como tickets en el trac para el sprint que vamos a comenzar. Cada vez que alguien resuelve un ticket entra en trac y lo marca como cerrado o lo pasa a un compañero para que continúe con su parte. De un simple vistazo todos vemos el trabajo pendiente que nos queda por acabar y la prioridad que tiene.
Si no hemos podido cerrar muchos tickets en este sprint nos quedamos algo preocupados porque llegaremos al día de demo y no tendremos mucho que enseñar. En cambio si todo ha ido bien y hemos terminado nuestros tickets e incluso comenzamos ya con los de la semana siguiente vamos a estar mucho más contentos (sí, a veces adelantamos lo previsto para el sprint).
Cómo planificamos el sprint
Normalmente tenemos sprints de dos semanas que en alguna ocasión han sido de 3 por vacaciones de parte del equipo de trabajo durante las navidades y en otras de solo una semana. Esto último no funcionó nada bien. Fue muy difícil planificar una demo, la planificación del siguiente sprint, pruebas y todo lo demás en sólo 5 días de trabajo.
Les pongo aquí cómo es el calendario habitual en un uno de nuestros sprints de dos semanas. Está copiado casi literalmente del panel de Google+ donde anunciamos lo que tenemos previsto para los próximos días:
Previsto en el sprint del proyecto para el paso por test, pre-demo y demo:
1. Miércoles de 2ª semana del sprint:
a) Test de la batería de tests de 8:00 a 12:00
b) Pre-demo de 12:00 a 13:30
2. Jueves de 2ª semana del sprint:
a) Correcciones a bugs/incidencias de 8:00 a 12:00
b) Subida a demo a las 13:00 (con lo que haya hasta ese momento. No será posible hacer nuevas subidas hasta la demo del día siguiente)
c) Después de demo correcciones que no hayan podido caber en esta demo y trabajo en siguiente sprint hasta la demo del día siguiente.
3. Viernes de demo
a) Demo a las 12:00
b) Planificación del siguiente sprint a las 13:00
En esta planificación que pueden ver ahí, hay algunas cosas que son particulares a nuestra forma de trabajar:
- Tenemos una pre-demo el miércoles antes de terminar el sprint. Se estableció así porque en las primeras demo de los viernes fallaban muchas cosas o no nos habíamos entendido bien. Se muestra sólo al Scrum Master lo que han hecho durante esas casi dos semanas que puede ya ir viendo cómo de bien o mal va a quedar el sprint. Esto sirve también de ensayo para lo que vamos a ver el viernes en la reunión de demo real.
- El último día del sprint, el viernes de la segunda semana tenemos una demo ante todo el equipo de trabajo, en la que no siempre está el Product Owner, nuestro cliente. Trabajamos en un entorno distribuido por lo que no podemos estar en las mismas oficinas que nuestro cliente cada dos semanas. La misma aplicación que hemos visto en demo la enviamos al product owner para que pueda comprobar el trabajo hecho en ese sprint y que valide o no el resultado.
- En clientes más recientes, que han adoptado la agilidad desde hace mucho, hacemos una demo por Skype y se le explica lo realizado en esas semanas. Al final hay una retrospectiva en el que nos cuenta su impresión de lo que hemos hecho y lo que le ha gustado o no y puede mejorarse. Es una demo ensayada y probada para intentar que todo quede casi cronometrado en una hora de duración.
Cómo informamos al cliente
Cada vez que termina un sprint enviamos al cliente un informe de estado con las tareas y tickets de trac que hemos cerrado en esas dos semanas. Así pueden saber qué se pudo completar de lo previsto. Del mismo modo enviamos también qué tickets tenemos previsto cerrar durante las próximas dos semanas. Si todo ha ido bien deberá ser muy parecido a lo que digamos en el siguiente informe de estado que hemos podido finalizar.
Estos correos van con copia a la cuenta de correo de todo el grupo de trabajo y en él le indicamos al cliente también la URL donde podrá probar la versión de la aplicación que acabamos de desplegar y que revisamos en nuestra demo interna del viernes. En el correo van también las instrucciones sobre cómo probar los cambios realizados o dónde pueden encontrarlos.
En todo momento los clientes tienen acceso al entorno de demo para hacer sus pruebas, indicarnos qué va mal o decirnos qué cambios quiere sobre lo que está probando. Este entorno ha resultado ser muy útil porque nos permite mostrar muy rápidamente cada cambio aunque no esté finalizado sin tener que esperar a despliegues programados en pre-explotación o en producción.
