Cobol VS Java: vuelve el debate

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

Ansiedad VS Motivación: epílogo por S.F.

Antes de empezar, si no lo has hecho ya, te recomiendo leer el artículo "Ansiedad VS Motivación: el estado de fluidez" para dar contexto a lo que te voy a contar a continuación.

¿Alguna vez habéis estado en un traspaso de conocimiento? Me refiero a cuando una empresa sale y entra otra a quedarse con una aplicación de software.

Es decir, cuando las personas que llevan años trabajando en una aplicación se van, y llegan otras que no la conocen en absoluto para tomar el relevo.

¿Esto os suena? 
Si tú que estás leyendo esto lo has vivido, sabrás que es imposible "traspasar el conocimiento".

  
Lo que va a ocurrir, es que las personas que acaban de llegar y que no tienen ni idea de lo que se van a encontrar, van a pasar tal vez 2-3 meses con este traspaso, y luego 1 año fácilmente de sufrimiento hasta "entender algo" de lo que tienen que hacer. 

¿¿¿Cómo se sobrevive a 1 año en la zona de ansiedad??? 

Muchas personas no sobreviven. No tengo una estadística más allá que la experiencia de mi amiga S.F. y la mía propia, pero en algunos casos puede llegar al 50%. 
Esto no es normal. Esto no es vida. 

Os dejo aquí el testimonio de mi amiga que lleva ya 3 proyectos de traspaso. Es bastante ilustrativo...
 
Traspaso A: 2022

"Con traspaso de 1 mes llevamos un infarto, una baja por jaquecas diarias, el equipo X empastillado porque no pueden dormir. Y en el mío hay una persona de baja por ansiedad, y ha llorado ya medio equipo en plan ataque de ansiedad.

Otro chico acudió a la psicóloga de riesgos laborales de la empresa y tras darle las pastillas correspondientes le dijo: no te preocupes, que las toma la mitad de la empresa."

Traspaso B: 2021

"Con traspaso de 3 meses tuvimos: un jefe de baja por amago de infarto, un ataque de ansiedad con salida de proyecto por petición propia (obviamente), un chico con varios meses de baja por ansiedad y varias bajas voluntarias. Todo en año y pico."

 
Traspaso C: 2018

"Fueron 3 meses de traspaso con 12 horas de curro al día, pero aquí no recuerdo que mucha gente se pirara. El jefe cayó una vez acabó el proyecto, pero este ya era repetidor, ya estando en otro proyecto se había cogido un año de baja por ansiedad." 

Conclusiones de S.F. 

"Y contándolo así, la verdad que da gusto mi currículum, ¡qué buenos proyectos! 😂😂😂"

¿Os imagináis en qué tipo de proyecto estaba yo cuando caí en la zona de ansiedad en 2011?

Cooorrecto.

This is NOT the way!!!!

El camino hacia el dominio (capítulo final): el mecanismo de la suerte

Antes de empezar si no lo has hecho ya, te recomiendo leer los anteriores artículos de la serie: "Ansiedad VS Motivación: el estado de fluidez"  , "El camino hacia el dominio I: el test de egoísmo" y "El camino hacia el dominio II: un equipo con 11 delanteros" para dar contexto a lo que te voy a contar a continuación.

Capítulo final: el mecanismo de la suerte.
Ya solo quedan 125 chicos de los 300 que empezaron en Bluelock. Después de la última prueba que Ego les ha puesto, solo quedarán 35.

En un momento de esta última prueba, el equipo de Isagi pierde un partido de 4 contra 4 en el último segundo, digamos que "por mala suerte". En un contraataque, Isagui consigue parar el disparo del rival. Pero el balón sale disparado y nadie sabe dónde va a caer. 

Casualmente, el balón le cae en los pies a otro jugador del equipo contrario, que inevitablemente marca gol.

Isagi no entiende por qué si él hizo todo bien, la suerte le ha hecho perder. 

Entonces aparece Ego para explicarles el mecanismo de la suerte.

¿Alguna vez os ha cagado una paloma encima? 

Qué… mala suerte, ¿no? 🤣

Pero justo después os fijáis en que el suelo estaba lleno de caca de paloma. Y cuando miráis hacia arriba veis a un montón de palomas revoloteando. Si os hubieseis fijado antes, lo podríais haber evitado. 

¿Sigue siendo cosa de la suerte?

Dice Ego que existe una zona donde hay más probabilidad de que tengas suerte si estás preparado. Es lo que llama “el epicentro de la suerte”.
Y aquéllos que solo se sienten a mirar van, inevitablemente, a perder su oportunidad de “tener suerte”.

Este chico que marca gol estaba en el lugar adecuado para que en caso de que un balón llegase a sus pies, pudiese marcar gol. Si hubiese estado en otro sitio, por mucho que le llegase un balón, a lo mejor no marcaba. Porque estaba demasiado lejos, o porque aparecerían unos defensas a cortarle el paso.

Y es que ya lo decía Séneca. La suerte es lo que sucede cuando la preparación y la oportunidad se encuentran.

Tal vez no te habías dado cuenta, y esto te había pasado alguna vez...

En mi caso diría que varias veces. 

La primera vez fue cuando surgió un proyecto para reescribir todo el código de la aplicación en la que trabajábamos (para optimizarla). Cuando empecé a oír hablar del tema tuve claro que me interesaba. Por un lado iba a trabajar con dos personas del cliente que eran digamos "referentes" en Cobol, y por otro lado íbamos a trabajar con el departamento de calidad para buscar cómo optimizar el código. Siendo la última en llegar al proyecto, pasaría a ser la que se conociese mejor la aplicación.

Así que preparé mis argumentos para que, en caso de que pidiesen voluntarios, poder ofrecer mis servicios :-P

Otra ocasión sería cuando fui Scrum Master por primera vez. El cliente quería que nuestro proyecto pasase a trabajar en agilidad. Yo de aquella ni sabía lo que era eso pero según nos fueron explicando en qué iba a consistir tuve claro que me interesaba. Me puse a leer por mi cuenta para que, en caso de que el jefe no pudiese ser el Scrum Master y necesitasen "a alguien", levantar la mano. Esto me permitió tener más formación por parte del cliente y más acompañamiento del coach agile.

Con esta última pieza de la suerte, Isagi ya puede completar la fórmula para ser el mejor delantero del mundo. Es decir, para alcanzar el dominio:

Así que recordad:

• No dejéis que el ego bloquee vuestro aprendizaje.
• No os dejéis limitar por vuestros roles.
• Y preparaos, y colocaos, donde haya más probabilidad de que esa paloma os cague encima ;-) 

#thisistheway