Al mattino dopo una tazza di caffè abbiamo un cosiddetto stand-up meeting quotidiano. Ognuno di noi racconta la sua storia: "Ieri ho completato questo strumento, quindi sentitevi liberi di usarlo", "Ho fatto alcune modifiche alla pipeline CI, dovrebbe funzionare più velocemente, ma se avete problemi contattatemi", "Ho avuto un incontro con un cliente, quindi dobbiamo davvero rispettare la scadenza questa volta, ma possiamo rimandare l'implementazione della caratteristica X fino all'autunno", "Sono bloccato a causa di... Quindi sto facendo Y invece di Z". Così, chiunque è responsabile di far conoscere lo stato del suo lavoro ai compagni di squadra (non solo la direzione). In realtà, lo stand-up quotidiano non è l'unico modo per farlo, ma a volte funziona.
Il mio compagno di squadra ha finito un compito ieri sera, e sono invitato a fare una revisione per la richiesta di pull. Eseguo il codice e - ooops - viene lanciata una NullReferenceException. Sembra che lo sviluppatore non abbia testato a fondo il codice e abbia mancato alcuni casi limite. Scrivo un commento con le mie scoperte in modo che lo sviluppatore possa correggere il bug e aggiungere i test di unità/integrazione mancanti. Fare revisioni tra pari, testare il nostro codice, e fare del nostro meglio per fare un prodotto di buona qualità è anche parte delle nostre responsabilità.
Poi c'è una lunga e noiosa riunione di tutto il personale con un sacco di numeri. Le riunioni fanno schifo.
Dopo la riunione c'è una bella opportunità di lavorare sul design di una nuova funzionalità e infine di fare un po' di codifica. In realtà questa è la parte preferita del lavoro.
Poi un ingegnere di automazione dei test viene a discutere le possibili opzioni per testare una nuova serie di funzionalità. Lavoriamo insieme sul concetto che permette ai test di essere meno fragili e vediamo come gli sviluppatori possono assistere il team di test automation. Anche l'interazione tra diversi team fa parte delle responsabilità.
Allora dobbiamo discutere i nuovi requisiti con un proprietario del prodotto. Una nuova caratteristica sexy può compromettere la sicurezza del sistema, e probabilmente non è ciò di cui i clienti hanno effettivamente bisogno. Cercare di capire i requisiti effettivi fa parte del nostro lavoro, e non è il più facile. E dopo abbiamo un breve poker di pianificazione per stimare un paio di compiti nel backlog che probabilmente saranno presi per la prossima primavera. Chi se non gli sviluppatori può stimare gli sforzi. (Onestamente, gli sviluppatori fanno schifo nelle stime, chiedete a qualsiasi project manager)
La giornata è quasi finita, ho un po' di tempo per imparare la tecnologia che useremo presto, e per finalizzare il compito di codifica di oggi. Oh no, tutte le pipeline di compilazione sono rosse. Scorrendo i log vedo che le versioni degli artefatti sono completamente incasinate. Quel nuovo sistema di versioning automatico home-brew che usiamo si è rivelato essere un'eterna fonte di frustrazione. Dobbiamo riunire una nuova riunione per discutere cosa fare con esso (applicare un nuovo fix molto probabilmente e aspettare un mese fino a quando non rompe di nuovo le nostre pipeline).
In pratica, questo è quello che facciamo. Ok, ok, sarò onesto. Questo è quello che il nostro project manager pensa che facciamo. Quello che è nella realtà può essere una storia diversa da raccontare in un'altra occasione.