Cómo trabajamos. Parte 1:
Comunicación continua
Como equipo recién creado y en proceso de darse a conocer, resulta común que la gente nos pregunte cómo trabajamos. Para un posible cliente, muchas de las metodologías de desarrollo de software les resultan ajenas y se hace necesaria una labor didáctica para explicar nuestra forma de trabajo, que está basada en filosofía y prácticas de XP (Extreme Programming), en metodologías ágiles y en diseño centrado en el usuario.
“Dime cómo trabajas y te diré quién eres”
Hay gran dificultad de comunicar nuestro método de trabajo ya que está en continua evolución: Cambia porque nosotros, como equipo, cambiamos. Porque la tecnología que usamos cambia a gran rapidez. Porque los productos o servicios que diseñamos y construimos cambian cada semana. Y, finalmente, porque la forma en la que los usuarios utilizan nuestros productos, y los cambios del mercado, nos dan indicadores que nos obligan a adaptarnos a nuevas necesidades.
Si hubiese que reducir nuestra metodología a una sola premisa, ésta sería: “Nos adaptamos al cambio trabajando de una forma que, cada dos semanas, intenta establecer las cosas que funcionan y descartar las que no”.
Procuramos no estar tan apegados a nuestra forma de ver las cosas que nos impida deshacernos de lo que no funciona. Dedicamos tiempo, en nuestras reuniones semanales, a criticar constructivamente nuestra forma de trabajar, mediante conversaciones y dinámicas de grupo.
Sabemos que la forma en la que trabajamos en este proyecto será diferente a la del próximo. Lo que no cambia tan rápido es la filosofía de trabajo, que se centra en estar adaptado al contexto cambiante con una base sólida de buenas prácticas.
Para adaptarnos al contexto nuestras estrategias se pueden resumir en varios puntos:
- Comunicación continua entre el equipo
- Integración continua
- Retros cada dos semanas
- Trabajamos por iteraciones
- Reparto de pasta con conversaciones
- UX antes, durante y después
En siguientes posts iremos desarrollando cada uno de estos temas. Por, ahora si tenéis curiosidad de cómo hemos estructurado algunos pasos de nuestra metodología de trabajo aquí tenéis una muestra.
En este post nos centraremos en el primer punto: La comunicación continua entre el equipo. ¡Allá vamos!
Herramientas de comunicación del equipo
He hablado de reuniones semanales del equipo, en vez de reuniones diarias porque no tenemos aún un espacio de trabajo conjunto, sino varios. Trabajamos cada uno en nuestro espacio, en mi caso en un espacio de coworking, en el caso de Javi y Dani, en una oficina compartida y el resto en casa. Nuestras reuniones de equipo son, normalmente, los martes. Además de esta reunión, diferentes parejas se juntan los Viernes u otra mañana de la semana.
El trabajar cada uno en nuestro espacio privado nos permite tener momentos de gran concentración diaria y hace que nuestra quedada semanal y las sesiones de pair programming sean de gran concentración.
El no utilizar diariamente un espacio de trabajo conjunto, hace que dediquemos un especial mimo a nuestras herramientas de comunicación, que son:
Slack con diferentes canales
Intentamos no hacer demasiado ruido en canales donde no les corresponde, por eso tenemos uno de #random con conversaciones chorras y enlaces. Tenemos algún RSS o algún IFTTT que mete info interesante en ese canal (en mi caso mis bookmarks). Tenemos configurado el Slack de forma que la actividad del board del Trello de nuestro proyecto actual se publique automáticamente en un canal y también los resultados de las builds que hacemos de integración contínua con CircleCi cada vez que pusheamos nuestros commits en el repositorio del proyecto.
Trello con diferentes boards
Tenemos uno llamado Action Points en el que apuntamos cosas que nos hemos comprometido a hacer a nivel de equipo, independientemente del proyecto en curso. Por ejemplo: escribir aqui, preparar camisetas y pegatinas, investigar nueva integración Trello-Slack, hacer una propuesta para algún evento… Este board tiene las columnas: Backlog, Planned, Doing, Done y Parado por ahora.
Otro board le llamamos Leads y es la gestión de personas que nos han contactado, que nos han escrito para pedirnos presupuesto o que pueden suponer un futuro proyecto. En cada tarjeta apuntamos los emails, conversaciones mantenidas entre estos posibles clientes y el equipo, apuntes de reuniones, enlaces relacionados… Este board tiene las columnas: Recibidos, En proceso, Presupuestados y enviados, Aceptados, Rechazados, En la nevera y Done.
Por último tenemos el board del proyecto actual. Cada tarjeta corresponde a una historia de usuario. En el proyecto en el que estamos actualmente tenemos varias columnas:
Columnas de trabajo: Planned, Doing, Done (actual iteración) y Done Pasadas Iteraciones. Aquí hacemos Kanban de forma habitual.
Por otro lado tenemos un conjunto de Columnas de Backlog, cada Épica tiene su propia columna con historias de usuario relativas a esta que esperan a ser añadidas al Planned de la siguiente iteración. Por ejemplo: Épica: Listado de asuntos, Épica: Agrupación de asuntos, Épica: Administración, Épica: Superadministración…
Y por último tenemos dos columnas especiales: Columnas de Concerns. Tenemos una llamada símplemente Concerns, y otra llamada UX. La primera de Concerns está compuesta por tarjetas que describen bugs, problemas de programación o cosas a mejorar que requieren solución o refactorizar en el código. La de UX, son cosas que no están bien resueltas o dan problemas a nivel de interacción, usabilidad o experiencia de usuario. Estas tarjetas o historias de usuario que van apareciendo a medida que avanza el proyecto, las vamos metiendo a Planned en cada iteración a un ritmo asumible, de esta forma vamos refinando el frontend y el backend, sin posponer las mejoras.
Dailies a las 4:00pm
Son reuniones cortas que hacemos cada día a las 16:00 por videoconferencia. En ellas hacemos una ronda que empieza por el que más tarde se ha conectado. En la ronda, cada miembro del equipo cuenta qué ha hecho la tarde anterior y la mañana del día actual. Y también cuenta el plan de qué va a hacer lo que le queda de día. Intentamos ser breves, que no se alarguen más de 10 minutos, lo cual supone unos 2 minutos por persona.
A veces también aprovechamos para hablar o decidir sobre un lead o un tema en concreto. Nos hacemos preguntas que nos pueden ayudar a continuar nuestro trabajo. Es común que tras la daily, se quede una pareja para acabar de hablar o para pairear con un tema en concreto en el que uno está atascado y necesita la ayuda del otro.
Pair Programming los Viernes
Es común entre nosotros que realicemos hangouts en parejas o llamadas rápidas con audio en Slack para ayudarnos unos a otros, también para programar en parejas haciendo pair programming. Esto nos permite tener un conocimiento compartido del proyecto.
Code Reviews dentro y fuera
A veces no basta con que dos personas vean el código. Cada semana algún miembro del equipo ha tirado millas con un tema técnico y ha resuelto cosas como: rutas de Angular o documentado el API con Swagger, o ha creado un faker para el DNI, lo que sea…
En esos casos hacemos una sesión conjunta en la que, el que se lo ha currado, explica a los demás cómo lo ha hecho, enseña código, presenta dudas, recibe sugerencias para mejorar, etc…
Estas revisiones de código, a veces, las hacemos con los compañeros de NoFlopSquad. Nos enseñamos cómo hemos resuelto algunos temas de nuestros proyectos mediante videoconferencia y nos permite salir del aislamiento del trabajo interno y aprender mucho unos de otros.
Reunión semanal los Martes
Como he comentado, cada martes, nos juntamos en el local de alguno de nosotros o en un bar con wifi. Allí trabajamos juntos, a veces organizados en parejas y hacemos las code reviews y más cosas. Si coincide con el final de una iteración (cada dos semanas) preparamos temas para la demo con el cliente y nos repartimos la pasta con fichas de póker si ya hemos cobrado la iteración (esto lo explicaremos en otro post). Solemos comer ese día en un restaurante japonés y, allí, hablamos de posibles leads y reuniones pendientes. Y no es raro que, tras tanta concentración, terminemos la jornada con una buena cerveza en la mano.
Otras herramientas colaborativas
Como repositorio de documentos compartidos usamos Google Drive. Allí tenemos plantillas de presupuestos, entregables de presentación del equipo (nuestro info-pack) y otros documentos de apoyo que puedan ayudar a vender nuestros servicios, trabajar en las inceptions o comunicación externa.
Para compartir elementos gráficos de nuestra marca usamos Invision, así como para compartir pantallazos de bugs, etc…
Para tomar apuntes en las reuniones y para hacer esquemas de nuestra metodología, listas to-do, apuntes de libros y otras listas colaborativas, usamos Workflowy.
También usamos muchas otras herramientas destinadas a código, repositorios como Github y mucho más, pero eso daría para otro post completo.
Hasta aquí una primera aproximación de cómo trabajamos como equipo, que iremos completando con más posts. ¿Y vosotros cómo trabajáis?
