equipos

Trabajar con un buen equipo es una de las mejores cosas que puede pasarnos, tener a nuestro lado a gente que sabe más que nosotros, que nos ayuda, nos guía, nos reta hace que cada día saquemos lo mejor de nosotros e intentemos superarnos. Todo lo que vamos a leer en este post son experiencias personales, sobre las características que creo debemos fomentar en los equipos de desarrollo software para que sean efectivos, abierto y por tanto mejores.

Formar un equipo no es algo que podamos hacer de la noche a la mañana fichando buenos profesionales, creo que crear un gran equipo de desarrollo es un camino que hacemos paso a paso, equivocándonos, fallando aprendiendo y mejorando. Ninguno de los siguiente puntos funcionan de la noche a la mañana y creo que funcionarán aun peor si son impuestos. Solo existe una cosa que podemos hacer y es trabajar, trabajar y trabajar para conseguir resultados, y no me refiero solo a entregas, proyectos, funcionalidades, sino a trabajar para mejorar el entorno de trabajo, las relaciones con los compañeros y en definitiva crear un clima de con de confianza en el que se mantenga la motivación con proyectos, planes e incentivos que nos hagan estar feliz en nuestro día a día.

Ahora vamos a desarrollar una serie de características que en mi humilde opinión deberían tenerse en cuenta cuando estamos trabajando en un equipo de desarrollo software y queremos mejorar, no son solo mejoras organizacionales o de procesos, sino son puntos que creo importantes a la hora de mantener el orden en nuestra labor de aportar valor a negocio.

Confianza y transparencia

Son las claves de todo el proceso, si no confiamos en nuestros compañeros, en nuestra compañía o en nuestros jefes, casi todo está perdido. Es necesaria esa **confianza* para poder proponer ideas, aportar valor y discutir sobre el proceso que llevamos a cabo. Esta característica debe ser bidireccional, es necesario que la dirección de la compañía confíe en todo el proceso, en el cambio y este abierto al dialogo. De la misma forma la transparencia debe ser parte del día a día. Saber porqué tomamos una decisión es importante para mantener al equipo unido y saber hacia donde nos dirigimos.

Retrospectivas

Da igual si trabajamos con Scrum, Kanban, Lean, o cualquier metodología de desarrollo; para mejorar es necesario tomar medidas, hacer cambios y ver si las acciones tomadas hacen que mejoremos. De la misma manera tenemos que preguntarnos si lo que estamos midiendo es lo justo y correcto. Las retrospectivas son el mejor lugar para pensar, conversar y decidir hacia donde vamos y si el camino que llevamos es el correcto. Por eso la confianza y transparencia son fundamentales ya que las retrospectivas son el momento y lugar adecuados para dialogar, obtener distintos puntos de vista, poner en común un plan de acción acciones y llevarlo a cabo para mejorar. Aportar valor a negocio y entregar software que funciona son los pilares de Scrum, así que para llegar a ese objetivo es necesario que aportemos feedback que nos haga mejorar. Creo que deben hacerse habitualmente al menos una vez al mes para poder estar al día de los cambios, mejoras y progresos llevados a cabo en el equipo.

Tareas, trabajo diario y gestión

El otro día hablando con un amigo sobre como abordar el trabajo no planificado dentro de Scrum o como hacer que el equipo no se disperse haciendo tareas urgentes comentamos una frase que puede ilustrarnos en todo este punto si no está en Jira, no existe. Da igual que sea Jira, Trello, o lo que cualquier otra herramienta, creo es necesario que todo (o la mayor parte) del trabajo que hagamos esté registrado. De cara a todo el equipo, es más fácil que ayudemos a un compañero si sabemos en que anda metido y de la misma manera también podemos poner foco en realizar en lo importante antes que lo urgente. Creo que este punto es lo suficientemente extenso como para que lo desglosemos un poco más

Gestión de tareas

Es necesario que tengamos un registro de las tareas tanto las que hemos hecho como las que tenemos que hacer. Ya que esa tarea será nuestra semilla para saber que hicimos, porqué, cuanto en esa parte, documentemos dicha funcionalidad, sepamos cual es la «definition of done», tengamos los test de aceptación,… tener una herramienta que nos ayude en todo esto es fundamental. Jira aunque es algo complejo de administrar, si se usa bien es una herramienta muy potente junto con Confluence para que mantengamos todo el conocimiento documentado. Existen otras herramientas como Redmine, Trello, podemos usar la que queramos pero teniendo en cuenta que son herramientas que nos ayudan, no son el pilar fundamental de toda la organización, así que mientras la herramienta aporte valor será bienvenida.

Ramas y commits

Una buena manera de ponerle nombre a las ramas es que las nombremos como el «id de Jira» (MOB-123,CRM-345,TEC-459,…) así está cubierto el punto anterior (si no está en Jira no existe) y gracias esto estamos podemos apoyarnos en Jira como herramienta de comunicación, para así poder conversar y amasar los requisitos para convertirlos software que funciona.

Del mismo modo, es necesario que tengamos una metodología para el branching, los tags, el proceso de releases,… cuando hablamos de metodología no me refiero a un proceso complicado sino a una serie de pasos documentados que podamos consultar y que no tengamos que explicar a un recién llegado, tan solo decirle aquí está la documentación vamos a seguirla para subir la próxima release.

Lo mismo con los commits, hacer buenos commits que nos ayuden en el futuro y nos expliquen el porqué se hizo esto de este modo.

Trabajo no planificado

¿Cómo resolvemos el trabajo no planificado cuando usamos Scrum? Normalmente el flujo de trabajo en Scrum es más o menos así: hacemos sprints de 2 semanas, en los que el product owner nos proporciona una lista ordenada de historias de usuario(Sprint backlog) que aportan el máximo valor al negocio. El equipo trabajamos en dichas tareas para al final del Sprint tener un software listo que cumpla con la mayor parte de los elementos de la lista. Pero… ¿qué hacemos con los bugs, con los cambios de ultima hora, o con bloqueos externos (una tarea depende de un proveedor externo…), etc.? Una solución que nos funciona de bastante bien es el «rol de soporte» o traga-bolas.

Durante el sprint, 1 miembro del equipo no realiza tareas del sprint, «solo» está de soporte para el resto de equipos, resolviendo incidencias, bugs, dudas, informes,… con esto hemos conseguido que todo el equipo mantenga el foco en el Sprint Backlof y solo tenga cabeza para aportar valor. Del mismo modo conseguimos dar una respuesta rápida al resto de equipos (comercial, producto, atención al cliente,…), así ellos pueden estar tranquilos ya que un miembro del equipo técnico les ayudará en todo lo posible y saben que si hay algo urgente tendrán como referente a alguien del equipo que pueda echarle un cable. Cabe destacar que para la persona de soporte esas 2 semanas a veces son algo estresantes, cambios de contexto, prioridades,… por lo que es un rol rotativo por el que pasamos todos(hago énfasis en todos) los miembros del equipo.

Una de las mayores ventajas que hemos ganado es que somo multidisciplinares, podemos trabajar en cualquier producto y eso hace que no haya silos de conocimiento ya que cuando eres soporte tendrás que tocar lo que salga. Del mismo modo hace que tengamos una documentación clara, concisa ordenada y útil. Ya que estando de «traga-bolas» necesitamos apoyarnos en documentación que de verdad nos ayuda a resolver las tareas.

Testing, CodeReview, TDD

Nuestro trabajo está basado en el código, pero está avalado por nuestro tests, debemos estar seguros y cómodos cuando realizamos cambios en nuestro código y la mejor forma de hacerlo es teniendo tests. No se trata de hacer TDD o BDD o lo que sea sino de hacer bien nuestro trabajo, manteniendo una calidad. Del mismo modo, para evitar los silos de información realizar code reviews del código nos ayuda a compartir mejor el conocimiento, poner en común decisiones y ayudarnos entre los miembros del equipo.

Autorganización

Como venimos hablando desde el principio del post, aunque no de manera explicita, un concepto clave para que mejoremos como equipo y alcancemos el éxito (maximizar el valor aportado sin que ello suponga un desgaste del equipo) es la autorganización. Dentro del equipo podemos decidir todas las características de nuestro trabajo y como lo realizamos, por ello podemos proponer y probar prácticas para intentar mejorar nuestra calidad. Es normal que durante algunas etapas pasemos por épocas de conflictos pero tenemos que aprender a superarlos con dialogo y paciencia, ya que forman parte nuestro día a día.

Compartir

Como equipo pasamos muchas horas juntos, creo que los pilares fundamentales a la hora de trabajar en un buen equipo de desarrollo es el poder compartir. Que podamos aprender los unos de los otros, colaborando e intentando que el código sea propiedad del equipo, es decir, que no escuchemos la frase << esto lo hizo XXX, será mejor que lo toque él/ella porque lo hará mejor/más rápido…>> ya que corremos el riesgo de que la frase derive en << eso lo hizo XXX, yo no lo toco ni con un palo>> Por ello mantener el conocimiento compartido es uno de los pilares fundamentales como equipo de desarrollo.

Perks

Creo que los beneficios no solo tienen que ser poder elegir PC o Mac, silla de trabajo, monitor, entradas a conferencias,…. Bajo mi punto de vista, somos personas que trabajamos en equipo, peros sobre todo personas que tenemos nuestra vida fuera del trabajo y queremos disfrutar de ella. Por ello creo que la compañía debe ser consciente de nuestra realidad personal y facilitarnos nuestro día a día. Perks como el teletrabajo, el poder salir a mitad de la mañana ha hacer algún recado (bancos, hacienda, fontanero,…), el poder elegir la mayor parte del horario de trabajo deberían ser algo normal dentro del equipo y la compañía. Por eso creo que una de las características principales de los buenos profesionales y de los grandes equipos es la honestidad y la confianza para que estos perks nos sean factibles.

Conclusiones

Como hemos dicho antes trabajar en un equipo de desarrollo en el que los miembros estemos motivados y alineados es una de las mejores experiencias que podemos tener en nuestra vida profesional. Las características que hemos desarrollado en este post son algunas de las que creo debería reunir un buen equipo de desarrollo. A modo de resumen podemos decir que tenemos 4 pilares: comunicación, gestión de proyectos, foco y aptitudes y actitudes técnicas y todas las mejoras que intentamos llevar a cabo en un equipo deberían apoyarse en estos pilares.

Del mismo modo un buen equipo de desarrollo no se hace de la noche a la mañana, sino que hay hacerlo madurar y mejorar manteniendo la confianza en el mismo y apostando claramente por sus miembros.

¿Y tú cuales piensan que son las características de una buen equipo de desarrollo? ¿Qué características echas en falta? ¿Y cuales sobran?