Hola amigas y amigos del Consultorio Cobol.
Como sabéis, hace tiempo que no escribo artículos de COBOL porque hace ya un tiempo que no programo. Pero es que ahora ni siquiera trabajo en un proyecto COBOL. Me he cambiado de bando...
Últimamente estoy trabajando con equipos Scrum que programan en java (o algo parecido), con su control de versiones con Bitbucket, sus branchs y demás.
El caso es que cada vez que digo:
"recordad que lo prioritario es completar el sprint goal. Si terminamos lo nuestro, vemos de ayudar a los demás para asegurar que cumplimos el sprint goal."
Me responden: "es que no podemos trabajar más de una persona en un ticket."
Y si digo: "vale, pero hay 2 tickets."
Entonces me dicen: "no, es que todos afectan a la misma clase. Solo puede tocar uno."
Y claro, yo que no estoy metida en la parte técnica, y que además soy de cobol-mainframe, no lo entiendo del todo.
Porque en cobol, recuerdo perfectamente repartirnos los programas (y rutinas) que había q tocar/crear. Incluso una persona podía hacer el JCL (en la versión Java el equivalente imagino que será un script) y otro el programa. O si había que tocar alguna tabla para añadir datos (parametría por ejemplo) lo podía hacer otra persona.
Y sí, claro que para implantar/testear teníamos que ponernos de acuerdo si eran cosas enlazadas, pero podíamos trabajar varios en la misma funcionalidad. Digamos que el código estaba lo bastante troceado como para poder trabajar varios a la vez.
Eso ayudaba mucho a trabajar conjuntamente en el objetivo del sprint (cuando alguien terminaba, podía ponerse a ayudar al resto).
Entonces yo me pregunto, ¿esto es una cosa de la aplicación en cuestión con la que trabaja mi actual equipo? ¿Es que el código no está bien hecho y por eso todo está metido en el mismo "archivo"?
¿Es porque no estamos dividiendo bien las features? ¿O soy yo que no me entero?
Otra cosa que me dicen es que claro, que si cada uno se crea una branch, luego hay conflictos. Y yo me pregunto, ¿y eso es un problema? Te detecta los conflictos a la hora de hacer el merge y los "resuelves", ¿no?
¿Tan complicado es o es que buscamos la comodidad?
Por favor java developers, arrojad algo de luz... Mi objetivo sólo es terminar las cosas en curso antes de empezar otras nuevas...
#thisistheway
2 comentarios:
Hola Tania..se que es un poco tarde a este post. Soy Veronica ambas hemos trabajado juntas en Cobol y y yo cambie a desarrolladora Java hace casi 11 años.
Te cuento, las funcionalidades JAVA tambien pueden repartirse entre todo el equipo la cuestion es que el trabajo a nivel funcional este bien divivido. Y se hafan las cosas comunes lo antes posible.
Yo lo que hago para gestionar esto es una rama feature que tratamos como padre y X ramas ffeatures hijas de esta rama padre segun el numero de desarrolladores o personaa en las que se divide la tarea.
Por ejemplo hay 3 programadores
feature/funcionalidadCRUD es la rama padre
De esta rama sacanoa una feataure paea cada programador siendo esta la rama desde la que se crean
feature/hija1
feature/hija2
feature/hija3
Cuando alguno de los desarrolladores termino de programar algo que es comun al restto de personas la sube a la rama padre y avisa a sus compañeros, asi el resto de personas lo mergean en au rama. Asi no hay codigo duplicado y todos tienen el mismo codigo fuente
Efectivamente surgiran conflictos porque todos pueden estar tocando las mismas clases. Pero si hay comunicacion entre el equipo y van mezclando codigo cada poco esos conflictos son triviales
Es posible es factible y los conflictos no son un problema. Solo hace falta organizacio y saber manejar Git.
Cuánto tiempo Vero! Muchas gracias por la repuesta.
Me queda claro que poder se puede, que es cuestión de organización. Pero es verdad que hay que montar bien las ramas de git. Me lo apunto para la próxima crisis :-P