12 herramientas obligatorias para trabajar en equipo

A la hora de abordar un proyecto pequeño, como un portafolio o una app sin muchas funcionalidades, es relativamente fácil de llevar por una sola persona. No tiene mucho secreto, solo hay que tener una buena organización personal, una comunicación fluida con el cliente y respetar los tiempos acordados. Es importante saber decir que no. En caso contrario estarás diciendo que a muchas otras cosas: trabajar más horas, rechazar otros proyectos y tener menos tiempo libre para tu vida personal. También es necesario la suficiente paciencia para obtener los requisitos auténticos del cliente. Porque muchas veces viene con una idea vaga de lo que desea. Y acordar unas fechas de entrega que sea razonables para el desarrollo. Además de asumible por el cliente. Cuando las 3 características se alinean hablamos de un buen proyecto. Pero el problema está cuando las características empiezan a crecer tanto que se te salen de la hoja. Y lo quiere en un espacio de tiempo que escapa de las manos más rápidas. Necesitas trabajar con más gente.

En nuestro estudio somos 8 personas trabajando al unísono con diferentes roles: 3 programadores de Backend, 1 programdor de Fronend, 1 diseñadora gráfica, 1 experta en SEO, 1 comercial y 1 gestor de proyectos (mi puesto). Nos dedicamos a realizar proyectos complejos. Desde Apps para cargar coches eléctricos hasta redes sociales. Son objetivos inalcanzables para una sola persona. Por lo que hemos aprendido a estar juntos.

Después de varios años trabajando todos juntos hemos aprendido mucho. Más de nuestros fracasos que de nuestras victorias. Ya no solo sirve una buena comunicación, que la hay, sino utilizar unas herramientas que nos vuelvan productivos y minimicen los problemas. Por ello voy a compartir las 12 herramientas que consideramos obligatorias para el día a día de cualquier equipo. Probadas con profundidad y el día a día.

Preproducción

Antes de empezar cualquier trabajo hay que realizar unas tareas previas. Muchas veces costosas por parte del equipo. No por el esfuerzo, sino por la poca diversión que implica. Las cuales no solo van a servir a trabajar más cómodamente en el futuro, sino a que el cliente tenga claro que esta comprando.

Prototipado

Después de varias reuniones, ya se tiene recopilado las características que pensamos que desea el cliente. Saben lo que quieren, pero no como. Por lo que hay que guiarles.

El siguiente paso es darles un boceto donde puedan ver una aproximación de todas las páginas o pantallas. Acompañado de una explicación en cada uno de los botones. De esta etapa suelen salir más necesidades que antes no se veían. Si es así, se añaden y se vuelve a organizar otra reunión hasta que el cliente quede satisfecho.

Diseño

Con los planos anteriores, el diseñador gráfico empieza a mantener comunicación con el cliente para desarrollar el aspecto final, la marca y todo el material visual. De esta etapa debe salir cada una de las páginas/pantallas con el aspecto final. No más características, sino solo su aspecto. Por muy insignificante que sea: E-mails, ventanas emergentes, mensajes de error…. Se intentará aproximar lo máximo posible consultando siempre con el diseñador si hubiera que realizar algún cambio.

UML

Con los diseños acabados, nos disponemos a plasmar todo sobre algunos esquemas UML. Normalmente, por tiempo, hacemos los casos de uso y el de secuencia. Nos ayudará muchas veces a confirmar, de nuevo, con el cliente el funcionamiento y librarnos de sus cambios caprichosos venideros (los desarrollos son muy largos…). Si esta firmado, mucho mejor. Además es una excelente documentación para que el equipo pueda llevar una misma idea del proceso. Menos dudas, menos reuniones, menos errores y mayor productividad.

Framework en común

Cuando ya esta claro que vamos a hacer y con el orden de prioridades, llega el momento de elegir el conjunto de herramientas que vamos a utilizar para el desarrollo.

Backend

Si hay que realizar una web muy personalizable solemos utilizar Django. Dispone de casi todo lo que podemos desear: motor de plantillas, internalización, buena documentación, ORM, Unit Test, Sockets, panel de administración, plugins y una estructura personalizable. No brilla por su velocidad en el servidor, pero si por su productividad. Y bueno, que en el equipo adoramos trabajar con Python.

Si necesitamos un gran rendimiento nada mejor que Revel escrito en Go. Es un lenguaje muy interesante con un rendimiento rozando el C.

Frontend

Si es sencillo, Javascript puro. Si necesitamos algo más potente JQuery. Si ya hablamos de gran dependencia del Frontend o un webapp, vamos directos a Angular 2. Hay una cantidad ingente de posibilidades con Javascript. Pero estas opciones funcionan realmente bien. Typescript también nos gusta.

Producción

Scrum

El problema cuando trabajas con varias personas siempre es el mismo: evitar cuellos de botella. Y lo más sencillo es utilizar una estrategia de desarrollo ágil como Scrum. Mejorará la comunicación entre los miembros, quedará documentado los estados de las características, el propio equipo se autorganizará, habrá un seguimiento seguro por parte del cliente y no se darán palos de ciego. Hay cientos de libros que te enseñarán a trabajar con ese marco. Funciona en grandes empresas con desarrollos muy grandes. No reinventes la rueda, usa lo que ya va bien.

Nosotros usamos Redmine en un VPS. Aunque Jira es una opción estupenda.

Git

El código debe estar versionado. Si o si. A la hora de desarrollar entre diferentes miembros, cada uno debe poder descargarse la última versión, de subir sus actualizaciones sin comprometer la del resto, crear ramas para experimentar, poder colaborar en características en desarrollo, volver a versiones anteriores, etc. Si no se usa, tendrás grandes problemas.

Usamos Gitlab en un VPS propio porque nos permite tener un número ilimitado de usuarios. Pero Bitbucket es una gran alternativa de pago.

Git-flow

Cada tarea debe ser una rama. De ese modo es fácil que otros puedan aportar su trabajo o desecharla sin comprometer el repositorio. Con Git-flow tendrás este sistema de forma automatizada y sin pelearle con Git.

Comunicación

Si se quiere una buena comunicación hace falta software que esté a la altura. Slack es el que más nos convence. Tiene una integración perfecta con los respositorios Git y Redmine. Su App de smartphone trabaja a la perfección. Nos permite compartir archivos de forma sencilla, y podemos destacar mensajes.

Cuando debemos hacer llamadas grupales, Slack se vuelve de pago. Y no se escucha del todo bien con Linux. Por lo que usamos Skype o Hangout.

Calidad de software

Es bastante común que por las prisas los desarrolladores empiecen a aumentar los bugs. Se acerca la fechas de entrega y las tareas no acaban nunca. Por ello se tiende a no testear. No de forma consciente, por supuesto. Por lo que la mejor forma es hacer un doble check. Por un lado indicar al autor de la nueva característica que valide si esta acabada (lo cual hace siempre con Scrum o Git flow), y por otra pasar esa tarea a otro desarrollador para que la valide. De ese modo, los dos serán responsables si no funciona correctamente.

Por otro lado puedes mejorar la calidad del código con los code review. Si obligas a que dejen comentarios en las líneas de código, casi cualquier gestor web de Git te lo permite, podrás mejorar la calidad. Por vergüenza o miedo a la réplica, estarán más atentos a no ensuciar el código y mantenerlo comentado. Lo aconsejable es asignar parejas aleatorias una vez por semana.

Integración continua

Cuando se esta en fase de desarrollo, se suele contar con 3 tipos de entornos. El primero es el servidor de pruebas, o en el que trabajas en tu ordenador. Cada uno de los miembros se instala el software necesario para imitar las mismas funcionalidades del final. Por ejemplo, si trabajas con Wordpress, te instalarías Apache, MySQL y PHP. El segundo es el servidor de ensayo (Staging). Es accesible por todos, y es donde se suben cada una de las tareas acabadas. Sirve para probar que todo funciona bien y donde el cliente aprobará las tareas acabadas. Y por último, producción. Abierto a cualquier persona. Donde estará las versiones más estables.

Volcar los cambios de Git, testear que todo funciona bien, y por último notificar si se ha producido algún error; es costoso y repetitivo. Por lo que es trabajo de una máquina. En concreto de los software de integración continua. Se encargará de vigilar si hay algún cambio, actualizar los servidores adecuados, y avisar si no se han pasado los test o ha caído algo.

E-mail

Todo lo importante debe pasar por E-mail. No todo, para eso ya tenemos Slack. Solo temas delicados como monetarios o acuerdos entre partes. Y con los clientes, si es posible, cualquier cosa. Aunque luego hables con ellos por teléfono, después debe enviarse un mensaje con el resumen de la conversación. Te ayudará a resolver malentendidos y cubrirte las espaldas. Por otro lado tiene un peso legal por si las cosas se pusieran muy feas. Un historial universal que nunca pasa de moda.

Google Docs

La documentación es preferible que esté en línea y no dependa del ninguna versión de ningún programa. Google Docs lo hace todo sencillo. De forma gratuita te otorga una suite office. Todo se puede editar por varios miembros a la vez, se pueden compartir con diferentes roles… y no se puede borrar.

Postproducción

Una vez logrado que la columna de tareas esté vacía, lo ideal es configurar para que el software de continua integración vigile si se cae producción y negociar con el cliente una tarifa de mantenimiento. Se acabó el trabajo y por lo tanto el software.

Y si hay muchos beneficios, no seas tacaño e invitar al equipo a una cena.

Versión escritorio