Buone pratiche, tips e consigli per sopravvivere a una settimana da developer
In questo breve articolo vogliamo raccontare come si lavora in un team IT: vedremo come si organizza il lavoro, come funzionano i rilasci e, cosa più importante, come si reagisce ai problemi che si presentano. Il tutto inserendo qualche suggerimento pratico.
Partiremo dalla fine di uno sprint* (vedi appendice alla fine) e dalla presentazione della demo del progetto al cliente: raccoglieremo i feedback, apriremo i ticket, stimeremo il tempo richiesto per risolverli, li chiuderemo, gestiremo le emergenze e rilasceremo. Il tutto si chiuderà con la fine del nuovo sprint e la demo successiva.
Table of content
- Demo Progetto
- Sprint Planning
- Affrontare un Ticket
- Gestire le Emergenze
- Demo e Rilascio
- Appendice: La Metodologia Agile
Demo Progetto
La demo del progetto rappresenta il momento in cui il team di sviluppo mostra il lavoro svolto durante lo sprint. È una fase importante per allineare gli stakeholder sugli avanzamenti e raccogliere i feedback dal Product Owner o dal cliente finale.
Cadenza: Generalmente, la demo si tiene alla fine dello sprint, a seconda della durata degli sprint (in questo caso, una settimana).
Partecipanti: Comprende tutti i membri del team di sviluppo, il Product Owner, e altri stakeholder interni o esterni, come clienti o manager di alto livello.
Scopo: Dimostrare le funzionalità o le modifiche apportate nel progetto e ottenere un feedback immediato, in modo da sapere se la direzione presa è quella giusta e se ci sono nuove features da aggiungere o bug da risolvere. La demo è anche un’opportunità per celebrare i progressi del team. Spesso vengono presentati prototipi funzionanti (minimum viable product – MVP) o build live del software.
Benefici: Mantiene un flusso di comunicazione costante tra il team e gli altri stakeholder, favorendo un miglior allineamento sugli obiettivi futuri.
Sprint Planning
A seguito della demo, avremo nuove features da aggiungere o bug da risolvere. La pianificazione dello sprint è un momento fondamentale in cui il team definisce quali attività verranno completate nel prossimo ciclo di lavoro e con quale urgenza.
Preparazione: Andiamo nella board di progetto su GitHub: nel nostro repository (possono esserci più repository associati a un singolo progetto) aggiungiamo le nuove issue, avendo cura di descrivere che cosa va fatto esattamente a livello di implementazione, in modo da non avere dubbi in seguito.
Selezione dei ticket e stime: Il team discute insieme quali ticket possono essere completati nel tempo assegnato: questo richiede di bilanciare la capacità del team con le priorità. Per esempio, se ci fossero dei bug tali da impedire la successiva release, questi dovrebbero essere risolti per primi.
Ogni ticket viene stimato in termini di effort: l’obiettivo è trovare una misura condivisa del carico di lavoro, cercando di suddividere le grandi attività in task più piccoli e gestibili. Si imposta anche una Definition of Done per assicurarsi che ogni attività sia chiaramente definita.
Il risultato dello sprint Planning sarà un elenco di ticket, ordinato per importanza, che contiene tutte le funzionalità o i bug che devono essere affrontati nel corso del nostro sprint. Ogni developer si assegnerà un ticket dalla ToDo List e la sposterà in Doing, in modo che il Tech Leader (TL) o il Project Manager (PM) sappia immediatamente chi sta lavorando a cosa.
Strumenti: Per le board di progetto usiamo solitamente GitHub, ma anche Jira, Trello o Asana sono ottimi strumenti per gestire il backlog e tenere traccia del flusso di lavoro e dei progressi.
Affrontare un Ticket
È il momento di iniziare a lavorare sul codice. Come già accennato, un ticket rappresenta una singola unità di lavoro, che può essere una user story (cioè una descrizione informale delle caratteristiche di un sistema software), un bug o un task tecnico. La gestione efficace di questi ticket è fondamentale per il workflow quotidiano del team.
Sviluppo: Il developer sposta il ticket assegnato nella colonna In Progress (o Doing) e inizia a lavorarci, seguendo le best practice del team. Generalmente, il nostro team adotta il Test Driven Development (TDD), un approccio in cui i test automatici vengono scritti prima del software che deve essere sottoposto a test. Questo metodo guida lo sviluppo, poiché l’obiettivo principale è fare in modo che il codice superi i test definiti in anticipo. Una volta scritti i test, il developer si dedica alla scrittura di codice pulito, leggibile e facilmente manutenibile, preferibilmente con commenti esplicativi. Le modifiche non vengono mai fatte direttamente sul branch principale (main), ma su un branch separato, solitamente chiamato feature branch, facilmente associabile al ticket da cui è scaturito.
Pull Request e Code Review: Completato il lavoro, viene pushato il codice, e lo sviluppatore crea una pull request (PR) per mergiare il branch di sviluppo con quello principale. Indipendentemente dallo strumento utilizzato (GitHub, GitLab, ecc.), è consigliato utilizzare un template per la PR, che guidi il programmatore a includere una breve descrizione delle modifiche e le istruzioni per testarle. Questo aiuta a rendere più chiaro il contenuto della PR a chi andrà poi a effettuare la review e a chi ci lavorerà in futuro. Un’altra buona pratica è fare riferimento alla issue collegata al ticket. Ad esempio, su GitHub, usando il simbolo #, è possibile collegare facilmente la PR alla issue corrispondente, creando automaticamente un link che unisce le due.
A questo punto, il ticket viene spostato in Review e i colleghi procedono alla revisione del codice, verificando che rispetti gli standard del team e che non contenga errori.
Testing: Una parte cruciale del processo consiste nel garantire che nessun test venga compromesso dalle modifiche. Su piattaforme come GitHub, utilizziamo un sistema di Continuous Integration (CI) che esegue i test e, in caso di fallimenti, blocca il merge verso main. I test automatici (come unit test e integration test) possono non essere esaustivi, quindi è buona pratica eseguire anche dei test manuali per individuare eventuali bug, che dovranno risolti prima di integrare il codice nel branch principale. (Se stai cercando un’infrastruttura di Continuous Integration, in questo webinar parliamo di Buldkite)
Completamento: Dopo che il codice ha superato la revisione e i test, il ticket viene marcato come completato (Done).
Gestire le Emergenze
Le emergenze ci sono sempre, questa è l’unica certezza nella vita di uno sviluppatore! 🙂 Possono essere bug critici in produzione o problemi che necessitano di un intervento immediato e sono eventi che interrompono il lavoro pianificato. Vanno messi sempre in conto e gestiti.
Identificazione e prioritizzazione: Quando emerge un problema urgente, il team deve valutare rapidamente l’impatto e la criticità. I problemi in produzione che compromettono il servizio vengono affrontati immediatamente.
Risoluzione rapida: I membri del team si concentrano su una soluzione rapida, solitamente bypassando i normali processi di sviluppo. Se il problema è un bug, può essere applicata una patch temporanea o il revert della modifica che l’ha introdotto.
Documentazione: Dopo aver risolto l’emergenza, si tiene una riunione per analizzare cosa è andato storto e come evitare situazioni simili in futuro. Questa fase è importante per il miglioramento continuo del team.
Retrospettiva: In molti casi, le emergenze vengono analizzate durante le retrospettive degli sprint per prevenire ricorrenze.
Strumenti: Sistemi di monitoraggio come Datadog o Sentry possono essere usati per rilevare anomalie.
Demo e Rilascio
Terminato lo sprint, ci prepariamo per la nuova demo. Il rilascio del software è il momento cruciale in cui il codice sviluppato viene distribuito agli utenti finali. Questo processo può avvenire attraverso rilasci programmati o tramite pratiche di integrazione e distribuzione continua (CI/CD).
La Demo: Una volta mergiati tutti i feature branch su main, si presenta agli stakeholder il software in esecuzione, andando a toccare le funzionalità aggiunte nello sprint. Come all’inizio, gli stakeholder daranno i loro feedback e tutto il processo ricomincerà daccapo.
Dopo la Demo, possiamo rilasciare il nostro software.
Il processo di rilascio: Apriamo un ticket di rilascio: se utilizziamo GitHub, accediamo alla pagina del nostro repository e creiamo una nuova release, assegnandole una tag, che rappresenta una “fotografia” dello stato attuale della codebase. Aggiungiamo anche un riepilogo delle modifiche incluse nella nuova versione, con GitHub che facilita questo processo generando automaticamente un changelog dalle pull request.
Questo è solo uno dei modi per gestire un rilascio. Ad esempio, nel mondo delle applicazioni web, possiamo avere un branch dedicato alla produzione. Dato che molti servizi web sono sempre live, le modifiche vengono distribuite direttamente in produzione (deploy), integrando le modifiche nel branch di produzione. Parte del flusso di CD (continuous delivery) include il deploy su piattaforme come AWS, dove le nuove funzionalità diventano immediatamente visibili dopo un aggiornamento della pagina. In altri contesti, come quello delle macchine industriali, il rilascio avviene tramite la creazione di installer. Esistono quindi molti approcci diversi per il rilascio del software, che variano a seconda del contesto e delle specifiche esigenze.
Pianificazione dei rilasci: In un team Agile, i rilasci possono essere continui (grazie a tecniche di continuous integration e continuous deployment) o possono avvenire al termine di uno sprint, come in questo caso.
Verifiche e testing: Prima di un rilascio, vengono eseguiti test approfonditi per assicurare che tutto funzioni come previsto. Questo include test automatici, QA manuale, e, a volte, rilasci in ambienti di staging.
Rilascio graduale: In molti casi, i rilasci vengono effettuati gradualmente, iniziando con una piccola parte degli utenti per monitorare eventuali problemi prima di una distribuzione completa.
Rollback: È essenziale avere una strategia di rollback (o revert) pronta nel caso in cui qualcosa vada storto durante il rilascio, con la possibilità di tornare a una versione stabile precedente.
Strumenti: Docker, Kubernetes, Jenkins, GitLab CI, Buildkite sono tra gli strumenti più utilizzati per automatizzare e monitorare i rilasci.
*Appendice: La Metodologia Agile
La metodologia Agile è un approccio alla gestione dei progetti che enfatizza la flessibilità, la collaborazione continua e l’incremento costante delle funzionalità del prodotto. In un contesto Agile, il lavoro è suddiviso in cicli brevi e iterativi chiamati sprint (solitamente di una o due settimane).
Valori chiave dell’Agile
1. Interazioni tra individui più che processi e strumenti.
2. Software funzionante più che documentazione esaustiva.
3. Collaborazione con il cliente più che negoziazione contrattuale.
4. Risposta al cambiamento più che seguire un piano.
I Ritmi dell’Agile
Daily Standup: Brevi riunioni giornaliere per discutere i progressi e le eventuali difficoltà.
Sprint: Riunione settimanale o bisettimanale dove si analizzano le richieste del prodotto e si creano i ticket corrispondenti.
Retrospettive: Dopo ogni sprint, il team analizza cosa ha funzionato bene e cosa potrebbe essere migliorato.
L’adozione di metodologie Agile consente ai team di sviluppo di migliorare costantemente, mantenendo alta la qualità del software e favorendo una rapida risposta ai cambiamenti.
Per approfondimenti sull’argomento, leggi il nostro articolo: Agile per team e progetti
Guarda il video: Workshop Lavoro in team IT: una settimana tipo – Alessandro Mamusa e Cristian Bianchi