Algunas reflexiones sobre el trabajo distribuido. Estaba pensando como mejorar la problemática del trabajo distribuido. Supongamos el hipotético caso de dos grupos trabajando en diferentes países en un gran proyecto que engloba un desarrollo Core y una extensión para el país.
Llamaremos a los grupos Core y País. Core tiene que desarrollar la funcionalidad general de tal manera que sea extensible, customizable en cada país y dentro de cada país en cada desarrollo particular. Les recuerdo que éste es un caso hipotético que no tiene ningún basamento en la realidad, sólo nos sirve para ver distintas implicancias del trabajo distribuido.
El equipo Core desarrolla tres tipos de tareas principalmente: agregar funcionalidad Core nueva, eliminar bugs y prestar soporte al equipo País, dado que puede tener menor conocimiento técnico y metodológico.
El equipo Pais por su parte realiza las siguientes tareas: extiende la capa país, corrige bugs en su capa, carga solicitudes de solución de bugs en la capa Core, implementa su producto.
Ahora visitemos un poco lo técnico, el equipo Core cada vez que agrega nueva funcionalidad compila, integra, corre tests, realiza pruebas automatizadas y publica una versión al equipo País, el cual toma las DLL del producto y pisa en su librería Core y continúa su extensión. Cada vez que el equipo País, agrega cierta funcionalidad realiza un proceso análogo.
Con los bugs es algo similiar, con la diferencia que cuando se resuelven un grupos de bugs y los mismos integran una versión, la misma puede ser sólo de solución de bugs, el número de versión sólo cambia el build y no el minor como cuando se publica nueva funcionalidad.
Hasta aquí un mundo bastante ideal.
Compliquemos las cosas
Ahora supongamos, siguiendo en el campo de la irrealidad, que el equipo Core (que es el que tiene el conocimiento técnico) se ve diezmado por temas de actualidad laboral.
Entonces la delgada línea que separaba los equipos se disuelve. Todos pueden tocar cualquiera de los dos proyectos.(Primer error se pierde administración y governance)
Compliquemos un poco más. El equipo País decide que dado que pueden tocar el Core, entonces porqué esperar una versión de Core, si podemos actualizarnos las DLL cada vez que modificamos algo en Core? (Segundo error se pierde traza, se genera inestabilidad)
Siguiendo la línea del caos (no el creativo o interesante y ágil), el equipo País realiza modificaciones en Core que les son suficientes para su capa País, pero se despreocupan por el estado de Core (compila, pero no necesariamente pasa test, se integra o simplemente sigue funcionando, se rompen interfaces) (Tercer error se piede la integración, consistencia y producto)
Conclusión
Siguiendo en ésta línea se podría continuar, pero creo que es ejemplo suficiente. A partir de éste momento hay que tomar muchas decisiones. ¿Que harías vos con éste hipotético caso? Me gustaría tener opiniones.
Disclaimer
Todo surge de una febril imaginación del autor, ningún personaje o situación tiene relación con la realidad. No fueron dañados animales en la realización del post.
Entradas
0 comentarios: