Tips útiles para trabajar en equipos de desarrollo

Cuando empecé mi carrera profesional como desarrollador de software me encontré con desafíos interesantes más allá de lo técnico: el trabajar en equipo. Lograr esto no solo nos da la capacidad de alcanzar objetivos mayores y ambiciosos que estando por nuestra cuenta, sino de nutrirnos de la experiencia de nuestros pares, aprender nuevas dinámicas y conocer gente en el camino.

Espero que estos tips, basados en mi experiencia personal, puedan llegar a serte de utilidad a la hora de entrar en un equipo nuevo.

Pair Programming

Es una buena instancia para transmitir el conocimiento, para conocer a tus camaradas de equipo, entender cómo piensan o tomar mejores decisiones de diseño. En resumen, hay muchísimas buenas razones para siempre fomentar el pairing. Si estás trabajando en un equipo con diferentes zonas horarias, te recomiendo que sigas tu lectura por acá.

Desbloquear a tu equipo

Algo que considero importante a la hora de realizar una tarea que involucra a distintas áreas o especialidades es detectar cuáles podrían ser los futuros cuellos de botella, ¿por qué? Muchas veces puede suceder que para terminar una historia quizás se necesite la coacción con diferentes actores, del mismo equipo o externos.

Un ejemplo donde ocurre esto es en las integraciones entre backend y frontend:

En nuestro caso, el equipo de desarrollo estaba dividido por especialidades, backend y frontend. Entonces, algo que hicimos y nos funcionó como primer etapa fue diseñar el contrato, que en este caso era por API, para luego, desde backend, desplegar una implementación fake de ese contrato. Se logró así que Frontend comenzara a integrarse cuanto antes y detectar con antelación un cambio en dicho contrato.

Antes de desarrollar

Cuando toca sentarse a desarrollar, el primer problema grande que se suele encontrar es “no logro entender la tarea”. Esto ocurre a veces porque la tarea no es fácilmente legible, no se sabe cuál es el alcance o aparecieron bloqueos que antes no estaban considerados. Puede ocurrir aunque esté refinado el proceso de definición de las historias.

Es muy útil que el equipo se siente, al menos unos minutos, para analizar si una tarea es realizable: que no nos esté faltando información y que estemos en la misma página con respecto a la necesidad planteada.

Desarrollando de manera iterativa e incremental

La filosofía de TDD aplica a diferentes escalas y niveles, ¿podemos seguir esta metodología para validar hipótesis de negocio?. La idea es poder dar pasos pequeños que se puedan integrar con éxito en el producto.

Hay funcionalidades que sabemos que pueden ser fraccionables y eso nos da una gran ventaja para ir validando cada paso que damos.

También ocurre que cuando un flujo no está 100% definido y da mucha libertad para accionar, es buena idea (además de refinarla para seguir bajando a tierra) poder validar el flujo y luego quizás dar pie a experimentar o terminar de pulir la interfaz, más que nada sabiendo que esa parte que ya validamos se puede integrar con tranquilidad.

Intercambiando ideas

Teniendo en cuenta todo lo anterior, al momento de tomar una nueva historia, es una buena idea tomarse 5 minutos en equipo para debatir las ideas de implementación, sobre todo cuando la funcionalidad a desarrollar no es trivial. Además, si entrás a un proyecto nuevo es probable que no tengas todo el contexto del desarrollo, y muchas veces algunas decisiones son guiadas por el conocimiento del mismo. Si ese es tu caso, te recomiendo leer este post.

Levantando la mano

La daily/standup no es el único momento para comunicar un bloqueo. El equipo está ahí para ayudarse. Es fundamental que la comunicación sea fluida en el equipo y la confianza aún más.