La pull request aperta da tre settimane: la review che aspetta il momento giusto

Narratore: Le voci di questo podcast sono generate sinteticamente. I personaggi sono immaginari, le situazioni, per chi lavora nell'IT aziendale, forse meno. È mercoledì mattina. Il Junior apre il sistema di code review. La sua pull request è ancora lì: due cambi, dieci righe, un test in più. Aperta tre settimane fa. Assignee: il Senior.

Junior Developer: Tre settimane. Sono dieci righe, comunque. Dieci. Ho controllato anche il diff due volte, nel caso si fossero allungate da sole. Il test è verde, la pipeline è verde, è tutto verde tranne lo stato: in attesa di review.

Narratore: Entra il Senior, di ritorno dal sistema legacy, dove passa le giornate come un guardiano di un parco che ha smesso di essere divertente.

Junior Developer: Scusa, quando puoi guardare la review? Nessuna fretta, lo dico solo perché... sono tre settimane.

Senior Developer: È nel mio backlog. Le ho già viste, le dieci righe. In dettaglio. Martedì scorso, mentre scivolavano nella notifica. Poi è arrivato un'altra notifica, e quella l'ho persa.

Junior Developer: Quindi la hai già fatta, la review. Solo... nel cuore, non nel sistema.

Senior Developer: La review che non è nel sistema non esiste. Prima regola del legacy: se non è scritto, non è successo.

Junior Developer: Ok, ma allora me lo dici. Mi basta un sì o un no sulle dieci righe. Anche un no. Un no lo gestisco, il silenzio no, il silenzio non ha un colore sulla board.

Senior Developer: Un no, su dieci righe buone, sarebbe un no a te. Un silenzio è un no a nessuno. Nel legacy il silenzio è la risposta più onesta che c'è.

Narratore: Entra il Product Owner, con in mano la domanda che tutti temono.

Product Owner: Domanda veloce. Il cliente ha visto la feature in demo, l'ha applaudita, letteralmente applaudita. Perché non è in produzione? Me lo ha scritto il cliente, con due punti esclamativi.

Junior Developer: Perché serve la seconda approvazione. La policy obbliga a due reviewer. Ho la prima, attesa tre settimane. La seconda non è mai arrivata, e senza la seconda il merge è bloccato. La feature è finita, l'approvazione no.

Product Owner: Aspetta. La cosa è finita, ma non può uscire perché due persone non hanno premuto due pulsanti? Qual è il pulsante mancante?

Junior Developer: Il secondo. E il primo serve a premere il secondo, in un certo senso.

Product Owner: Chiaro. Quindi se il cliente mi chiama, io gli dico che il codice è pronto, la pipeline è verde, e manca solo la firma di un collega che magari non sa nemmeno di essere il firmatario. Fantastico, ci metto due settimane a spiegarlo, e la spiegazione dura di più della feature.

Senior Developer: La spiegazione è il costo reale. La feature era il sconto.

Narratore: Il Senior, che nel frattempo è tornato a schermi pieni di verde e di dolore, alza lo sguardo.

Senior Developer: C'è una soluzione pulita. La disapprovo, chiudo la pull request, e la riapriamo come nuovo item di sprint. Così esce dal limbo e rientra nella pianificazione. Al prossimo refinement la stima, la riprendiamo, la rilancio io.

Junior Developer: Ma il codice non è cambiato. Sono le stesse dieci righe. Le riaprivo, e il sistema si riaccorge che... sono buone?

Senior Developer: Il sistema non si accorge di niente. Si accorge solo dello stato. E lo stato, ora, è sbagliato nel modo giusto.

Product Owner: Va bene, propongo questa al planning. Ma scrivete qualcosa, perché io al cliente devo dire che la feature finita non è finita per un motivo che ora ho capito e che non so spiegare.

Narratore: Alla call si aggiunge lo Scrum Master, che ha visto la discussione muoversi sulla board e ha deciso di non lasciarla muovere senza di lui.

Scrum Master: Ho visto il blocco, ottima occasione! Tre proposte: una sessione di pairing sulla review culture, una board dedicata alle review pendenti con owner e colore, e un cantiere per definire una policy di SLA delle review. Non serve molto, un workshop a settimana, e ce ne usciamo tutti allineati.

Senior Developer: Lo SLA esiste già. È scritto nel documento di team, pagina quattro. Ventiquattr'ore per la prima review. Mai rispettato da quando è stato scritto, che è anche l'ultima volta che è stato aperto.

Scrum Master: Perfetto, allora lo cantiere diventa un aggiornamento dello SLA esistente, con retrospettiva sulle cause del mancato rispetto. Anche questa è struttura, non burocrazia.

Junior Developer: Perché non mettiamo solo... qualcuno a fare la review? La seconda, intanto. Invece della board della review che aspetta la review.

Scrum Master: Bella osservazione, la mettiamo come action item dell'action item. Chi la prende?

Senior Developer: Torno sul legacy. Lì almeno gli errori sono miei.

Product Owner: Prima che tu vada, il numero per giovedì. Il cliente vuole sapere se la feature è in ritardo o solo... in attesa. Sono due parole diverse, ma il cliente non le distingue.

Scrum Master: Ottimo punto, lo trasformo in ticket di comunicazione con il cliente, con owner e data. Così la domanda ha un posto dove stare, e il posto è un altro ticket.

Junior Developer: Quindi ora ho una pull request che aspetta, un ticket che aspetta la pull request, e un cliente che aspetta il ticket. A questo punto anche il cliente è una scheda sulla board.

Narratore: Tre settimane dopo, la stessa call. Stesso link, stesso orario, probabilmente stessi partecipanti.

Junior Developer: Notizie positive. La pull request è stata finalmente approvata. Brutto colpo: tra l'approvazione e il merge è nato un conflitto, qualcuno ha toccato le stesse righe. La revisione riparte da capo, e la policy indica un nuovo reviewer. Terzo, credo. Il primo l'ho perso di vista.

Senior Developer: Nel frattempo il bug originale l'abbiamo aggirato con un workaround in produzione. Sedici righe, commentate. Non approvate, ma attive.

Junior Developer: Quindi il problema che la pull request risolveva non esiste più, e la pull request sta ancora aspettando di risolverlo. Se è temporaneo, quando lo togliamo, il workaround?

Senior Developer: Temporaneo è una parola. In produzione, le cose temporanee sono quelle che hanno più tempo davanti.

Product Owner: Ok, mi serve una stima. Quanto manca, all'andare in produzione? Il cliente chiama giovedì, e giovedì gli serve un numero, anche sbagliato, ma un numero.

Senior Developer: Ti propongo di toglierla dalla board. Il problema che risolveva non esiste più. La pull request, invece, lasciamola aperta. Ormai è l'unico documento storico di quelle dieci righe.

Narratore: La pull request resta aperta. Le dieci righe, ovunque siano, aspettano. Nel frattempo lo Scrum Master ha creato la board delle review pendenti. Nessuna review è ancora passata da lì.