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?
En Genbeta Dev | Trabajar con microservicios: evitando la frustración de las (enormes) aplicaciones monolíticas
Ver todos los comentarios en https://www.genbeta.com
VER 0 Comentario