Questo articolo descrive l’infrastruttura e le metodologie che abbiamo messo in atto per gestire la leadership tecnica di un progetto con:
- un team di 25 persone
- un pubblico di stakeholder di 270 persone
Inizialmente, il team di SpazioCodice era una cellula di sviluppo indipendente all’interno del progetto. Gradualmente, ci è stato chiesto di gestire l’intero ciclo di sviluppo in termini di:
- Pianificazione
- Monitoraggio
- Gestione del Repository Software
- Gestione del Rilascio e delle Versioni
- Testing Automatico
Ecco una descrizione dettagliata di come abbiamo organizzato quanto sopra.
Cosa si aspettava il cliente da noi?
Il cliente voleva che implementassimo un mix di competenze tecniche e gestionali.
- gestione del team
- gestione dei rilasci
- pianificazione
- monitoraggio e reporting
- ambienti osservabili e affidabili dove ogni funzionalità o correzione potesse essere facilmente verificata dopo l’implementazione
- reinstallazione automatica degli ambienti dopo il merge di una funzionalità
- build automatizzate, centralizzate, storicizzate e osservabili su tutti i rami (sviluppo, rilascio, lavoro)
- notifiche tramite un canale Slack
Come abbiamo soddisfatto queste richieste?
Nelle sezioni seguenti, abbiamo riassunto le principali cose che compongono il nostro approccio. Come potete notare, ognuna di esse è un argomento vasto, quindi ho scritto solo un riassunto essenziale che dovrebbe dare, credo, una buona idea a riguardo.
In ogni caso, mi piacerebbe ricevere domande, dubbi e feedback su di essi. Sentitevi liberi di contattarci in tal caso.
Sprint
Gli sprint sono un modo agile e flessibile per inserire traguardi verificabili di piccole dimensioni in un progetto di media/lunga durata.
Nella nostra esperienza, uno Sprint dovrebbe avere una durata ragionevole in termini di settimane, dove “ragionevole” significa:
- non troppo breve, altrimenti le riunioni (vedi sotto) sono inutili e troppo ravvicinate (ad es., le persone hanno poco o nulla da dire in una retrospettiva settimanale)
- non troppo lungo; uno Sprint lungo include necessariamente molto lavoro, che è difficile completare e verificare
Anche se il significato esatto di “breve” e “lungo” dipende dal contesto concreto del progetto, di solito impostiamo la durata dello Sprint a 3 settimane.
Pianifica, Traccia e Pubblica: JIRA
Atlassian JIRA è uno strumento molto potente per la gestione di un progetto software. Offre molte funzionalità (almeno più di quelle che usiamo) e integrazioni con strumenti esterni come repository software e sistemi di build.
Ogni stakeholder rilevante (inclusi gli sviluppatori) ha un account in JIRA. Il progetto è un progetto Scrum, organizzato in uno Sprint di 3 settimane.
Il flusso di lavoro di sviluppo è semplice. C’è un backlog, dove qualsiasi utente può creare ticket (bug, idee, richieste) in qualsiasi momento, e una bacheca che contiene la quantità di lavoro pianificata per lo Sprint attivo (cioè, spostata nello Sprint prima o durante la riunione di pianificazione).
La bacheca dello Sprint include quattro diversi stati dei ticket:
- DA FARE: Ticket in attesa di sviluppo
- IN CORSO: Ticket in lavorazione
- REVIEW: L’output del ticket (cioè, codice, analisi, risultati) è verificato da un’altra persona. Il revisore controlla il codice e la sua correttezza formale e assicura che ci sia una buona copertura (formale) dei test.
- VERIFICA: La funzionalità/correzione è stata implementata nell’ambiente verificabile; una persona dovrebbe verificare manualmente la sua correttezza. Prima di questa fase, l’assegnatario originale scrive passaggi di verifica dettagliati.
- COMPLETATO: funzionalità/correzione implementata, revisionata e verificata con successo. Il task è completato.
Nel caso di ticket di analisi, la fase di verifica viene saltata, mentre invece, per i ticket di codice, il passaggio da uno step all’altro può essere fatto solo dopo il cosiddetto “green build” (cioè, la suite di test automatici è eseguita dal sistema di build e tutti i test passano con successo).
Mappa del Progetto
Uno Sprint è un ottimo modo per organizzare impegni a breve termine. Tuttavia, i progetti di solito durano più di uno Sprint, e i clienti vogliono avere una panoramica ad alto livello dell’ammontare complessivo del lavoro in termini di:
- Cosa
- Quando
- Quanto (sforzo e costo)
Pertanto, la prima cosa che di solito facciamo in un progetto dove sono stati raccolti i requisiti funzionali è un’analisi tecnica dove analizziamo/discutiamo/esploriamo requisito per requisito e creiamo i corrispondenti ticket “tecnici” JIRA. Questo processo avviene a due livelli diversi.
Prima definiamo le aree funzionali e tecniche ad alto livello; per ciascuna, creiamo un tipo specifico di ticket JIRA chiamato Epic: qualsiasi altro ticket che creiamo deve appartenere a un Epic (cioè, a un’area di requisiti funzionali o tecnici). I ticket possono riguardare i seguenti tipi di lavoro:
- Analisi: di solito creati come “Storia” (un altro tipo di ticket JIRA), richiedono all’assegnatario di investigare un’area specifica e, alla fine, di creare i compiti di implementazione corrispondenti.
- Implementazione: il tipo di lavoro che gli sviluppatori amano; un compito di implementazione è qualcosa, ad esempio una funzionalità, che l’assegnatario deve implementare.
- Correzioni: I bug di solito non sono creati nella prima fase (non abbiamo un sistema testabile). Anche più tardi, sono molto difficili da prevedere e pianificare. Pertanto, non fanno parte della mappa del progetto.
Finora, tutto bene: abbiamo gli epic, e sono popolati con i ticket creati durante l’analisi tecnica. Ora, è il momento di distribuirli lungo una linea temporale.
JIRA interviene di nuovo con una funzione chiamata (non sorprendentemente) Timeline. Permette la creazione di una mappa del progetto che include gli epic e i compiti corrispondenti.
La colonna a sinistra elenca gli epic. Per ogni epic, una barra colorata indica la sua durata lungo la linea temporale. Sotto la linea temporale, puoi vedere diversi blocchi grigi che rappresentano gli Sprint e i pallini blu che rappresentano i rilasci (0.9 e 1.0 nell’esempio).
Sebbene questa prospettiva offra una buona panoramica ad alto livello del progetto, possiamo espandere gli epic e vedere i compiti concreti (analisi e/o implementazione) insieme alle loro dipendenze.
Vedi l’esempio seguente dove un epic è stato espanso.
Come potete immaginare, se apriamo tutti gli epic, la vista risultante è quasi illeggibile. Tuttavia, la prospettiva è molto utile perché include le dipendenze tra i compiti e, in caso di problemi, questi sono evidenziati in rosso (come nell’esempio).
Riunioni
Di solito abbiamo riunioni regolari e su richiesta. Mentre la seconda categoria include, come suggerisce il nome, riunioni che sono necessarie per una specifica esigenza, le riunioni regolari sono le seguenti:
Stand-up giornaliero (15 minuti)
Uno alla volta, i membri del team descrivono brevemente ciò che stanno facendo, insieme a potenziali sfide o ostacoli. In caso di sfide/ostacoli, viene programmata una riunione dedicata tra il reporter e le persone che possono aiutare.
Stima dei Ticket (1 ora)
Quando viene creato un nuovo ticket, indipendentemente dal suo tipo, entra nella coda del backlog. In questo momento, è senza stima e senza priorità.
Durante la riunione di dimensionamento, uno per uno, i ticket vengono discussi, migliorati nei loro dettagli (ad esempio, descrizione, versioni di fix, criteri di accettazione), stimati e prioritizzati.
Pianificazione (1 ora)
Prima che inizi un nuovo Sprint, il suo contenuto, inizialmente definito dalla roadmap, viene verificato e eventualmente aggiustato, considerando nuove priorità emerse. Questi cambiamenti possono implicare una (possibilmente piccola) reiterazione sulla roadmap.
Kick-off e Retrospettiva (1 ora)
All’inizio di ogni Sprint, di solito il primo giorno, prima di premere il pulsante “Inizio”, un breve incontro di kick-off è utile per assicurarsi che tutti siano allineati e soddisfatti del contenuto dello Sprint.
Tempo di demo: Se c’è una funzionalità, una correzione o un risultato di analisi utile da condividere con il team, l’assegnatario esegue una breve demo/presentazione.
Infine, ci sono 5 minuti in cui ogni membro del team può compilare un documento Google su:
- Ringraziamenti e congratulazioni
- Cosa è andato bene
- Cosa può essere migliorato (+ punti di azione)
Le cose scritte nel documento vengono poi lette e discusse insieme.
Ambienti Verificabili
Come detto sopra, un membro del team deve eseguire una verifica in un ambiente realistico prima che un compito possa essere considerato completato.
Questo ambiente deve includere l’intero set di moduli/componenti software. L’unica differenza è nei dati sottostanti, che dovrebbero essere:
- piccoli: l’ambiente è ricostruito/reinstallato più volte al giorno; questo processo dovrebbe essere il più rapido possibile.
- controllati e deterministici: i dati sono creati da esperti del dominio; quando il sistema si avvia, conosciamo esattamente il suo stato.
Ci sono due tipi di ambienti in cui avviene quella verifica:
- Test di Integrazione di Sistema (SIT): questo è l’ambiente direttamente collegato agli sviluppi. Ogni volta che una funzionalità/correzione viene unita nel ramo principale, service pack o hotfix, un corrispondente ambiente SIT viene ricostruito per includere tale cambiamento. Gli ambienti SIT contengono le ultime modifiche ma sono molto instabili perché vengono frequentemente riavviati/reinstallati.
- Test di Accettazione Utente (UAT): come suggerisce il nome, questo ambiente è principalmente per gli utenti finali/tester (dal lato cliente). È un luogo dove possono provare le ultime funzionalità stabili e verificate implementate nel progetto. L’ambiente viene costruito periodicamente (ad esempio, settimanalmente), quindi è stabile durante quel periodo.
Da notare che non esiste un solo SIT e UAT. Invece, ce n’è uno per ogni rilascio. Questo perché se una funzionalità è implementata solo in una specifica versione, dovrebbe esserci una coppia di ambienti verificabili (SIT e UAT) per quel specifico ramo.
Repository di Codice: BitBucket
C’è un progetto software senza codice? Codice, documentazione e artefatti correlati devono essere conservati, versionati, gestiti e manipolati.
Abbiamo scelto BitBucket come repository software per il progetto di cui stiamo discutendo. Essendo un prodotto Atlassian, si integra perfettamente con JIRA.
I cambiamenti sono gestiti, organizzati e applicati in rami, e ci sono diversi tipi di componenti:
- Rami di lavoro: sono i rami temporanei dove vengono implementate le funzionalità o le correzioni.
- Ramo principale: il ramo dove verrà rilasciata la prossima versione principale. Ogni funzionalità o correzione arriva qui per prima.
- Rami di Service Pack/Hotfix: subito dopo il primo rilascio (ad esempio, 1.0.0), il ramo di sviluppo non può più catturare le versioni installate nei diversi ambienti. Di conseguenza, abbiamo bisogno di due ulteriori tipi di rami nel repository software. I Service Packs sono destinati a catturare cose, funzionalità e anche correzioni che non rappresentano funzionalità rilevanti ma allo stesso tempo introducono cambiamenti bloccanti, non retro-compatibili. D’altra parte, gli Hotfix sono quelle cose che possiamo applicare immediatamente a un rilascio esistente, per lo più semplici correzioni di bug.
Registro di Pacchetti e Immagini
Gli artefatti software devono essere conservati e versionati. Purtroppo, Bitbucket non offre queste funzionalità, disponibili invece in GitHub e GitLab. Abbiamo scelto Gitlab senza un motivo particolare (i registri degli artefatti che offrono sono simili).
Gli artefatti del progetto sono:
- Librerie Java: conservate nel Registro Pacchetti Maven di Gitlab, sono utilizzate nel progetto come dipendenze
- Immagini Docker: conservate nel Registro Immagini di Gitlab, sono utilizzate per test e deploy
Integrazione Continua: Jenkins
Ogni volta che qualcuno effettua un cambiamento nel codice, un server dedicato all’Integrazione Continua, Jenkins, è incaricato di assicurare che tutto sia in ordine con la suite di integrazione.
Specificamente,
- Se il cambiamento è relativo a un ramo di lavoro, il codice viene prelevato e la suite di test di integrazione viene eseguita.
- Se il cambiamento viene unito al ramo principale, il codice viene prelevato, la suite di test di integrazione viene eseguita e l’ambiente di Test di Integrazione di Sistema (SIT) viene reinstallato da zero.
- Se il cambiamento viene unito a un ramo di service pack o di hotfix, il codice viene prelevato, la suite di test di integrazione viene eseguita e il Test di Integrazione di Sistema dell’ambiente corrispondente (SIT-SP, SIT-HOTFIX) viene reinstallato da zero.
Tutto ciò che Jenkins fa dovrebbe essere notificato agli utenti interessati. Per questo tipo di notifiche, abbiamo sostituito le email con un canale Slack dedicato:
Versioni Maggiori, Service Packs, Hotfixes
Abbiamo deciso di utilizzare un approccio semplice per gestire versioni e rilasci. Prima di tutto, abbiamo utilizzato un approccio di versionamento semantico, che identifica una data versione usando 3 numeri X.Y.Z:
- X, il numero più a sinistra, denota una versione maggiore, che è un insieme di funzionalità rilevanti (molto probabilmente che rompono l’API esistente).
- Y è la versione minore. Aumentiamo quel numero quando ci sono funzionalità isolate e bloccanti che dobbiamo rilasciare prima di una versione maggiore.
- Z è la versione della patch. Aumentiamo quel numero per applicare correzioni e cambiamenti non rilevanti e non bloccanti a un rilascio esistente.
Rapporto Sprint
Alla fine di ogni Sprint, il leader del team invia un rapporto riassuntivo informale che include:
- considerazioni generali
- aree di implementazione che sono state coperte
- sfide, ostacoli
- obiettivo principale del prossimo Sprint
Conclusioni
La Leadership Tecnica è una definizione per raggruppare un insieme di servizi che aiutano a guidare un progetto nella giusta direzione. Può essere implementata in diversi modi. Quello che abbiamo descritto in questo caso di studio è uno di questi ed è ciò che abbiamo scelto per gestire questo specifico progetto.
Come detto sopra, ci piacerebbe ricevere domande, dubbi e feedback su questo argomento. E non esitate a contattarci se volete farci gestire il vostro progetto tecnico.
