Una pratica che viene trascurata dai team di sviluppo è la revisione del lavoro tramite le pull-request. Ed è anche la più fraintesa.

Si crede che la pull-request sia per revisionare IL CODICE e far vedere quanto bravi siamo a dire agli altri quanto potrebbero fare meglio.

Ed è qui che si prende una cantonata pazzesca!

La pull-request è uno strumento di revisione del LAVORO svolto in generale (non solo del codice).

Chi prende in carico la PR e revisiona il lavoro svolto deve innanzitutto verificare le funzionalità USANDO il software e confrontando con quanto viene spiegato nella descrizione della PR o della user story relativa.

Il software fa quanto descritto? Quanto descritto è comprensibile e chiaro? L’esperienza d’uso è in linea con il resto dell’applicazione? Sono rispettati gli acceptance criteria?

SOLO DOPO aver passato le prove d’uso si passa alla parte del codice.

Anche perché, diciamolo, questo è uno scenario dove per il codice si farà sempre più uso di AI (funzionalità che GitHub implementa già) liberando quindi carico mentale e tempo per chi deve verificare il funzionamento.

Vantaggi di una pull-request ben fatta.

* Collaborazione strutturata: favoriscono il confronto tra sviluppatori, consentendo feedback e suggerimenti prima che il codice entri nella codebase. * Qualità del codice: molteplici occhi sullo stesso cambiamento identificano bug, violazioni di standard, problemi di performance e sicurezza. * Sicurezza del main branch: la PR agisce da filtro, evitando regressioni e integrazioni intempestive. * Riduzione dei rischi: la revisione preventiva permette di individuare errori o vulnerabilità prima che entrino in produzione * Condivisione della conoscenza: gli sviluppatori, anche non esperti in quell’area, leggono codice di altri moduli migliorando la comprensione della codebase . * Ownership collettiva: favoriscono responsabilità condivisa sulla qualità del codice, non relegata ai singoli. * Velocità di sviluppo: permettono modifiche in parallelo, mantenendo flusso continuo e merge efficienti. * Documentazione integrata: PR connesse a issue o ticket tracciano motivazioni, contesto e discussioni, migliorando la governance del progetto. * Debug e test più efficaci: PR ridotte in dimensioni permettono test incrementali e debugging più rapidi. * Feedback e crescita: offrire e ricevere feedback è occasione di mentoring e crescita reciproca, soprattutto per junior.

Vuoi migliorare l’efficacia delle PR del tuo team? Ecco come fare.

Struttura minima.

Le pull request (PR) sono tra gli strumenti più potenti per migliorare la qualità del codice e la collaborazione tra developer. Eppure, nella maggior parte dei team, dicevo, sono vissute come un rallentamento o un rituale inutile.

C’è un modo per ottere il massimo risultato col minimo sforzo? Certo che sì!

Il team deve istituire un processo di pull-request condiviso e che viene periodicamente migliorato.

Se non sai da dove partire, ti ho preparato una struttura minimale, efficace e sostenibile per trasformare l’esperienza delle PR.

1. Standardizza

• Crea una checklist di code review.
• Definisci un formato PR:
• Titolo chiaro
• Descrizione strutturata: _Why_, _What_, _How_
• Eventuali note specifiche per il reviewer.

2. Limita il WIP

• Ogni developer può avere una sola PR aperta alla volta.
• In Kanban, la colonna “In Review” ha WIP limitato.
• Se hai una PR aperta, non inizi un nuovo task: fai review.

3. Alloca tempo fisso

• Fascia oraria fissa (es. 11:30-12:00) riservata alla review.
• Niente review “al volo”. È lavoro, non favore.

4. Rendi la review asincrona efficace

• Se la PR supera le 300 righe, va divisa.
• Il reviewer deve:
• Fare domande in caso di ambiguità.
• Commentare su naming, performance o logica solo se bloccanti.
• Niente commenti estetici senza contesto.

5. Traccia una metrica settimanale

• Registra quanto tempo impieghi per fare la PR
• Registra la dimensione della PR (righe di codice)
• Registra l’effort (point) della user story revisionata (se possibile)
• Usa questa metrica per capire come stanno andando le PR.

Azioni

Crea una processo di pull-request, condividilo e mettilo alla prova col tuo team!

In questo modo il tuo team beneficerà di questa pratica senza rallentare troppo.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!