La forma en la que tu equipo de desarrollo se organiza dice mucho de la arquitectura de tu aplicación.
Y no sólo eso, sino cómo se comunica e incluso la cercanía física entre
ellos determina el proceso de comunicación que se proyecta a tu
software. Para pasar de un planteamiento monolítico a otro más cercano
al buzzword del momento, como los
microservicios, es necesario un esfuerzo organizativo, también dentro de tu departamento de desarrollo. Ser ágil ya no basta.
Bajo el modelo clásico, cada uno trabaja en su propia sección o capa del problema.
Resuelve de la mejor forma posible con su colección de tecnologías de
dominio e intenta juntar esas piezas con el resto de equipos.
¿La relación entre tus equipos de desarrollo y la arquitectura de tu aplicación?
Ninguno de los equipos tiene un entregable válido sino que se proyecta esa disrupción entre los propios componentes de la aplicación.
Para conseguir un build entregable es necesario resolver a veces
complejos puzzles. Es muy sencillo romper el build al mínimo cambio de
alguna de las capas al estar todas de una forma bastante acoplada dentro
de una arquitectura monolítica al igual que todo el equipo de
desarrollo está organizado.
Existen dependencias cruzadas entre equipos que
representa la propia comunicación de la aplicación. Cada uno de los
miembros intentará tirar balones fuera haciendo responsable a otros
equipos del mal funcionamiento. Esto conlleva continuos bloqueos, como si se tratase de una cadena de montaje cuyo cinta transportadora se rompe constantemente.
Planteamiento de equipos autónomos, guerrilla tech
Del planteamiento clásico de tener equipos divididos según tu stack
tecnologico: front, backend, sistemas, Android, iOS, etc.. hemos pasado a
tener equipos que conforman un mínimo producto en sí.
Equipos autónomos en sí mismos compuestos por desarrolladores
multidisciplinares o que saben entender a sus colegas de equipo que
hablan en otros lenguajes o tecnologías. Lo importante es el producto,
el componente que se está construyendo.
Cada equipo de desarrollo, siguiendo este planteamiento, es autónomo y lo conforman programadores de diferentes perfiles:
front, backend, sistemas, etc… Trabajan de forma independiente al resto
con su propio product owner y gente dedicada al equipo de
usabilidad/diseño. Tienen plena capacidad para decidir cómo trabajar. El
líder de este tipo de equipos empuja al resto, pero es el equipo el que
fija la forma de abordar el objetivo planteado.
De aquí a un tiempo lleva circulando el ejemplo organizativo de Spotify,
ampliamente documentado, en el que cada equipo cumple una funcionalidad
completa de la plataforma (la aplicación vista de forma global).
Más allá de que la forma en la que trabaje tu equipo sea ágil o no es fundamental la organización de tus equipos ¿Cuánto influye en cómo se organiza tu equipo de desarrollo con la arquitectura de tu aplicación?
Google+
@durbon
Editor en Genbetadev
