Somos una empresa extremadamente productiva que pasa la mayor parte del tiempo desarrollando. Por este motivo, en los últimos años hemos refinado una metodología de desarrollo propia, para ser lo más eficientes posible sin sacrificar ni un ápice en felicidad.

Seguimos un enfoque basado en metodologías ágiles para organizar nuestros proyectos, con tal de permitir la mayor flexibilidad posible, y para poder planificar cada semana con las necesidades reales de cada momento. La planificación convencional no se adecua completamente a los proyectos de desarrollo web actuales, por ser demasiado estricta y porque asume que todo está perfectamente definido desde el inicio del proyecto.

A menos que nuestros clientes digan lo contrario, usamos Github para almacenar nuestro código. Recomendamos encarecidamente trabajar con Git por su naturaleza distribuida, su alto rendimiento y porque goza de una comunidad muy numerosa y de altísima calidad.

Normalmente usamos Github también para gestionar nuestras tareas y tenerlas organizadas, pero nos adaptaremos a tus herramientas, ya sean Basecamp, Trello, JIRA, Asana o cualquier otra.

Ciclo de desarrollo

En primer lugar, empezamos con una primera fase en la que definimos a muy alto nivel el alcance del proyecto, y lo dividimos en distintos milestones (o entregables), donde cada uno contiene una serie de tareas. Nuestros milestones raramente duran más de 3 o 4 semanas de trabajo. Cada uno de ellos es un Github Project (un board con distintas columnas de estado) y cada tarea es una Github Issue, con sus labels correspondientes, un título y una descripción.

El primer milestone empieza justo después del inicio del proyecto (kick-off). Cada semana, elegimos las tareas que creemos que podemos completar de la primera columna del board. Estas se mueven a la segunda columna, que se llama “Current Week” (Semana actual).

Nuestros desarrolladores acometerán las tareas de la columna “Current Week” por orden, de arriba a abajo. Entonces, se asignan cada una de las tareas, y cuando empiezan a trabajar en ellas, las mueven a “In Progress” (la columna que indica que una tarea está “en progreso”). Esta columna nos permite ver quién está trabajando en qué tarea en un momento determinado.

Es importante mencionar que creamos una nueva rama (branch) de un repositorio Git para cada tarea en la que estamos trabajando, para tener el código debidamente organizado y para evitar conflictos entre desarrolladores que trabajen con los mismos archivos.

Cuando una tarea se termina, el desarrollador crea una Pull Request, detallando los cambios que ésta contiene, y qué hay que saber. Entonces, se mueve la tarea a la columna de “Review Pending” (pendiente de revisión) y se asigna un supervisor (reviewer) de la Pull Request.

El supervisor es otro desarrollador, o alguien de perfil superior, que se encarga de revisar el código y los aspectos funcionales de la tarea en cuestión. Esta metodología nos permite crear código con una alta exigencia de calidad, reducir el número de errores y mejorar nuestras aptitudes de programación. A posteriori, se ejecutan una serie tests y sistemas de integración continua para asegurar que la Pull Request de turno no rompe nada, y que el código de esta cumple con nuestras guías de estilo.

Una vez la Pull Request es aprobada por el supervisor, el desarrollador de la tarea hace un merge de la rama con el código fuente de la aplicación y despliega la nueva funcionalidad. Solo entonces se completa el ciclo de desarrollo, y la tarjeta de la tarea se mueve al último estado, en la columna “Done” (completado).

A veces, el ciclo de desarrollo es más complejo, especialmente cuando trabajamos con aplicaciones en producción que tienen distintas versiones corriendo, múltiples entornos de testing e integración, o con otros workflows de branching. Sin embargo, nuestra metodología cubre el 90% de los casos, y es suficientemente flexible para adaptarse al 10% restante sin cambiar los conceptos base.

Entornos

Desde la primera etapa del proyecto, desplegamos distintos servidores de testing e incluso el mismo servidor de producción. Esta estrategia nos permite testear las funcionalidades a medida que vamos desarrollando, haciendo entregas con mucha frecuencia.

La mayoría de los proyectos inician con un diseño hecho en Sketch o Illustrator. Este diseño lo implementamos en HTML estático y CSS. Usamos frameworks como SASS y herramientas como Middleman para esta parte del proyecto. En este punto, configuramos un “servidor de diseño“: un entorno donde desplegamos la versión estática de la aplicación, que para todos los efectos, es navegable también.

En el servidor de diseño, el cliente puede ver cómo resulta la aplicación en un entorno realista. De este modo, se ve cómo la aplicación se visualiza y se comporta en distintos navegadores, y gracias a ello podemos recibir feedback mucho más valioso que el que recibiríamos mostrando los diseños en Illustrator o Sketch. Por eso mismo, podemos iterar en esta fase mucho más rápidamente que lo que lo haríamos una vez implementado, y así evitamos rehacer código.

Una vez hemos terminado la implementación estática, empezamos el desarrollo del backend. Es entonces cuando desplegamos otro servidor - en este caso, de testing - donde los clientes pueden ver las nuevas funcionalidades una vez estas se han implementado. Es también en este punto cuando ya preparamos el entorno de producción.

Como se puede observar, nunca esperamos a tener todo el proyecto entero para entregarlo a nuestros clientes ni para testearlo, ya que el testeo y el feedback continuado de nuestros clientes son parte fundamental de nuestro proceso de desarrollo.