Equipo de desarrollo enfocado a producto

Cuando se crea un equipo de desarrollo enfocado a desarrollar producto es necesario que se cumplan una serie de buenas prácticas que garanticen no solo que el producto va a desarrollarse en tiempo y forma definidos, sino que además cumple con una serie de prácticas, arquitecturas y metodologías que garanticen que el producto sea mantenible y escalable en el tiempo.

Lo primero, escoger la metodología de desarrollo para el marco del trabajo

Dentro de los marcos de trabajo los más utilizados son los basados en metodologías ágiles (como SCRUM) o predictivas (waterfall).

Si el proyecto a desarrollar fuese orientado a modelo agencia (cliente), donde los requisitos y el objetivo están muy claros desde antes de empezar con el desarrollo, el marco de trabajo que mejor encaja es el predictivo.

Sin embargo, en el desarrollo de producto es posible que lo único que tengamos claro sea el desarrollo de un producto mínimo sobre el que ir iterando buscando el mejor market-fit posible. En este caso el marco de trabajo que mejor encaja con este enfoque es el basado en metodologías ágiles como SCRUM, en donde se desarrollan entregables basados en iteraciones (sprints) y el producto va evolucionando sprint a sprint.

El lenguaje en el que se desarrolle da igual, lo importante es la arquitectura y metodología utilizada

No importa el lenguaje en el que se desarrolle el producto, importan los procedimientos, las buenas prácticas, la arquitectura y la metodología que se decidan desde un inicio. Un producto mínimo puede desarrollarse sin seguir nada de esto, pero una vez que el MVP ha sido validado es necesario que cuente con unas bases sólidas que permitan que el equipo se sienta cómodo desarrollándolo, y que además sea fácil de mantener y que escale con cierta facilidad.

En Ipglobal nuestros productos se desarrollan con arquitecturas basadas en microservicios, con lo que es relativamente sencillo reaprovechar ciertos servicios ya desarrollados en otros productos o proyectos, con lo que en cierto modo se acelera el desarrollo de algunas partes de la aplicación.

La base de todo son las buenas prácticas, procuramos que en nuestros desarrollos se utilicen principios SOLID, patrones de diseño (como factorías, observables, máquinas de estado, facades, modelo-vista-controlador…) y, por encima de todo esto, procuramos que nuestros nuevos desarrollos apliquen un nuevo enfoque de desarrollo denominado DDD: domain driven development.

En este enfoque de desarrollo se busca una interconexión entre la implementación y los conceptos de negocio a través de un lenguaje ubicuo, de forma que la implementación está mucho más enfocada al negocio que a través de un desarrollo tradicional. En el DDD buscamos que la arquitectura de nuestra aplicación se separe en capas: la capa de lógica de negocio, la capa de aplicación, la capa de infraestructura, la capa de interfaz… lo que aplica más semántica y contexto a la aplicación, a la vez que facilita desacoplar partes de la aplicación para sustituirlas por otras de una forma más sencilla.

Automatiza todo lo que puedas

Una de las normas de las buenas prácticas desarrollando producto es que se debe minimizar al máximo lo que llega a producción. Como muchas veces el producto itera buscando su market-fit, hacer despliegues manuales con muchas funcionalidades en cada despliegue es una práctica poco recomendable. Para solventar eso lo que nosotros recomendamos es hacer varios despliegues a producción de pocas cosas cada vez.

Además, cada cosa que se sube a producción debe ir correctamente probada. Para ello nos valemos de varias procesos automatizados.

Lo primero que hemos automatizado son los tests. Probamos nuestro código de varias formas: unitariamente (el código fuente y sus ramificaciones), funcionalmente (las entradas y salidas de una funcionalidad determinada) y de comportamiento (como se ve y comporta esa funcionalidad en el conjunto de otras).

Cada vez que se sube una funcionalidad a la rama de desarrollo, un sistema de integración continua corre todos los tests escritos para la aplicación. De esta forma evitamos que una funcionalidad colisione con otra, ya que en el caso de existir problemas el sistema de integración continua no permitiría que esa funcionalidad llegue a producción y avisaría al equipo de desarrollo para que lo corrija.

Para el sistema de integración continua usamos los runners de Gitlab, que montan un entorno muy parecido al de producción en imágenes de Docker, donde se corre toda la batería de pruebas que el equipo de desarrollo ha desarrollado.

Otro aspecto importante a automatizar son los despliegues. Como hemos dicho antes, es importante desplegar pocas funcionalidades a la vez, y para no tener que hacer despliegues manuales diarios, hemos automatizado esta parte para que el propio sistema de integración continua realice los despliegues a los distintos entornos (preproducción, producción…).

El propio sistema de despliegue continuo se encarga de hacer backups, de forma que sea posible hacer un rollback inmediato en caso de que el despliegue falle.