El Flujo de Desarrollo

Como todos en el mundo de Desarrollo de Software nos esmeramos por entregar Software funcional lo más pronto posible en cada entrega.

Para lograr esta meta utilizamos las mejores herramientas que podemos encontrar para cada proyecto.

Nuestro flujo de desarrollo está bien definido. Mientras una base de las herramientas que utilizamos es constante, la otra parte cambia muy constantemente. En cada iteración evaluamos la opción que le dará más valor lo más rápido posible a nuestro cliente y nuestro equipo.

Nuestra razón de ser es el Desarrollo de Aplicaciones. Sin importar que sean Plataformas Web, Aplicaciones Móviles o de Escritorio buscamos utilizar el mismo set de herramientas de nuestro Stack. De tal forma que sea más sencillo para nosotros como programadores cambiar de un proyecto a otro.

Facilitar el context switch o la transición entre proyectos, también ayuda a que los desarrolladores trabajen en más proyectos al mismo tiempo. A la vez que como Administrador de Proyectos te facilita la asignación de tareas.

La parte estándar del Flujo de Desarrollo

Dividimos todos los desarrollos en un backend, uno o varios front-ends y un número variable de servicios, que se pueden desarrollar y reemplazar de forma independiente.

Tanto para el desarrollo de Plataformas Web y para el desarrollo de nuestros backends preferimos CakePHP. Pueden leer aquí el por qué.

Para la parte del Front-end utilizamos Semantic nos brinda una UI limpia y completa. Aunque para mobile-first (apps y websites), hasta la fecha utilizamos Foundation for Sites, usualmente en conjunto con otro framework que termine de completar a la UI/UX.

Para la lógica del lado del front-end utilizamos mayormente Angular (v1). Lo utilizamos igual para Web Apps, que en Apps Móviles (con Trigger.io o Ionic) y Apps de Escritorio (con Electrón).

Siempre, nuestros repositorios están ligados a tres ambientes de “deployment” — Desarrollo, “Staging” y Producción. Para el control de código utilizamos Git y Subversion, dependiendo de los proyectos del cliente (o de sus necesidades específicas).

Desarrollo y Staging se publican automáticamente en cada commit. Producción solo cuando un cliente y el product owner han aceptado la versión en staging. Desarrollo es para que los miembro del equipo hagan pruebas.

Por medio de tags en los comentarios de los commits se actualizan las tareas, que pueden estar en Trello o en Springloops otra herramienta de tareas, orientada a desarrollo (al estilo de Jira o YouTrack).

Para la visibilidad del proyecto utilizamos Trello. Usualmente dos tableros. El primero para la visión general del proyecto, la forma en que vamos a dividirlo para cada iteración o entrega y división en user stories.

El segundo para llevar cada iteración. Dividido en un Backlog o Pendientes (que incluye la deuda técnica), un grupo de tareas En Desarrollo, un grupo de tareas Terminadas, listas para revisión. Otro grupo para las tareas Revisadas (Done done.). Y otros dos uno para tareas eliminadas que se trabajaron (para que el cliente vea qué se trabajó aún cuando no hayan llegado al producto final) y otra para las tareas que se posponen a “futuro” o ideas para releases futuros, pero que puede que nunca se hagan.

Se documenta solo lo suficiente para generar un “common understanding” del proyecto de forma que el equipo pueda tomar las decisiones que lo acerquen a hacia la meta del proyecto.

Como documentos del proyecto utilizamos Mind Maps para describir “la historia” del sistema y Personas para describir a los stackeholders o “usuarios” del sistema. La finalidad de ambos es crear una idea clara de hacía dónde se quiere llegar con el proyecto.

Dependiendo del proyecto y los desarrolladores, algunas veces también hacemos un Diagrama de Modelos/Relaciones (qué bien puede ser un clásico ER o pueden ser grahps dependiendo del Storage, leer más adelante) o un Diagrama de Secuencia UML.

La parte del Flujo de Desarrollo que cambia constantemente

Constantemente tratamos de mejorar. En este caso, mejorar significa utilizar herramientas que nos permitan ser más productivos, que tengamos mejor calidad o que ofrezcan una ventaja para nuestros proyectos y nuestros clientes.

La rapidez con la que un desarrollador se vuelve productivo con un framework, lenguaje o plataforma es uno de los factores decisivos para que lo hagamos parte de nuestro stack.

Hace un par de meses empezamos a probar Vue.js como la capa de lógica del front-end con excelentes resultados. Su mayor ventaja es lo simple e intuitivo que es para un nuevo desarrollador, comparado por ejemplo con Angular o React. Rápidamente está desplazando a Angular como el de facto para nuevos proyectos.

De igual forma, comenzamos a probar Laravel y Phalcon como opciones a CakePHP para nuestro backend en PHP. Y Sails y Loopback en NodeJS. Laravel lleva la delantera. Eloquent, su ORM, tiene más drivers que las demás opciones.

La persistencia de datos es otra de las áreas dónde, dependiendo del proyecto utilizamos una u otra solución según lo que sea más conveniente.

Usualmente es una mezcla de un RDBMS (Tenemos proyectos con MySQL, SQL Server o Informix) y otra opción para complementarlos.

Por ejemplo, estamos encantados con RethinkDB como Base de Datos NoSQL. Sus changefeeds nos permiten subscribirnos a eventos que se disparan cuando la información cambia, en lugar de tener que estar constantemente consultando la información. Además ofrece un lenguaje de consulta mucho más natural que MongoDB o Firebase. Lo combinamos constantemente con MySQL para crear micro-servicios.

Anterior mente utilizábamos Firebase para los proyectos que necesitaban datos en Tiempo Real, sin embargo estamos migrando también a RethinkDB para ello (con la ayuda de Horizon o Deepstream).

Para aplicaciones que generan toneladas de información utilizábamos MongoDB (por ejemplo para historico de información de GPS). Sin embargo, ahora estamos tratando de migrar a Dynamo o DocumentDB.

Los pet projects son el entorno ideal para crecer a nuestros programadores y probar nuevas tecnologías.

En nuestro último “pet project” de Geolocalización hicimos una combinación de H2, una base de datos en memoria, en la que implementé un trigger en Java que actualiza solo la última posición a una tabla en RethinkDB. La información “historica” es almacenada en DocumentDB (qué es compatible con Mongo) o en DynamoDB, lo que nos permite crecer desmesuradamente.

Los pet projects son el entorno ideal para crecer a nuestros programadores y probar nuevas tecnologías. En el proyecto actual estamos construyendo un recommendation engine con la ayuda de Neo4j. La primer iteración fue implementada con SQL estándar, la segunda iteración fue implementada en Neo4j. Un nuevo paradigma que encontramos muy útil para escenarios específicos.

El Stack crece día con día… El flujo de desarrollo se mantiene igual, una parte que cambia constantemente, una parte se mantiene más o menos estándar. Y la mejor herramienta, siempre será la que nos lleve a una mejor solución en alguno de los aspectos que definen la calidad de software.


De otros experimentos…

Además de el software hemos tenido la oportunidad de trabajar en varios proyectos donde interactuamos con Hardware.

Actualmente estamos desarrollando en una plataforma de IoT que incluye un lector de huellas digitales, sensores RFID, cámaras IP y nano-servidores como el Jetson TK1 o el Cubieboard.

Para otros proyectos hemos trabajado en interacciones con GPS dedicados, GPS portátiles (como el de los celulares), sensores de presencia, de agua, relays y modems GSM.

Gracias a la “ubiquidad” de la red hemos podido hacer interfaces con un sin número de plataformas distintas y al final llevarlas a la web. Simplemente son una herramienta más que hay que utilizar para llegar a la mejor solución para nuestros clientes (internos y externos).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.