Come condividere le esperienze fra team di sviluppo: le TPS Develer

Le Technical Project Stories di Develer: intervista a Lorenzo Savini

Le esperienze di un team di sviluppo raramente ne superano i confini e vengono condivise con altri team. Magari può accadere per caso, durante una pausa caffè, ma non in modo strutturato. Queste esperienze sono di solito frutto di tanto tempo e molto stress, e potrebbero portare enormi benefici anche per altri progetti.

Che cosa abbiamo pensato in Develer affinché tutti possano usufruire delle best practice adottate dai vari team?

Ce lo racconta oggi Lorenzo Savini, sviluppatore software e responsabile delle nostre TPS (acronimo che sta per Technical Projects Stories).

Ciao Lorenzo, che cosa sono le TPS e per quale esigenza nascono?

Le TPS sono appuntamenti a cadenza mensile e interni all’azienda, per fare in modo che ci si possa prendere tutta la libertà possibile di discutere tra colleghi.

Il loro scopo principale è condividere esperienze e scelte, fatte durante un progetto, con i membri di altri team che, altrimenti, non ne sarebbero mai venuti a conoscenza. Sono momenti di aggregazione e di discussione, nei quali si possono esaminare sia scelte tecniche (come tools e scelte architetturali) o di concetto (documentazione, pulizia del codice, organizzazione del lavoro), sia eventi specifici che hanno portato nuove conoscenze (c.d. incidenti).

Ci sono diversi tipi di TPS?

Noi dividiamo le TPS in 3 gruppi principali:

• Post Mortem: report a seguito di incidenti
• Retrospective: report a seguito di progetti conclusi
• Evergreen: report indipendenti da eventi del progetto (come un incidente o la conclusione)

Come sono strutturate le TPS?

Come dicevo già prima, le TPS hanno cadenza mensile e ciascuna può durare da mezz’ora a un massimo di un’ora. C’è un develeriano che presenta l’argomento prescelto alla platea interna e una parte del tempo è sempre riservata alle domande e alla discussione. 

Alla fine, viene chiesto allo speaker di redigere un documento dove si fa un resoconto di quello che è stato detto e che viene successivamente caricato sul Wiki aziendale, in modo che tutti i develeriani, anche i nostri colleghi futuri, possano consultarlo e trarre beneficio da questi incontri.

Quali sono i vantaggi del condividere esperienze fuori dal gruppo di lavoro?

I vantaggi sono davvero molti:

• i membri del team stesso possono ritrovare dettagli ogni qualvolta ne abbiano bisogno, anche nel bel mezzo della notte – e può servire davvero! Inoltre, anche i  nuovi membri del team possono avere dettagli sulla storia del progetto da questi documenti, che comunque avranno un vocabolario non troppo legato al progetto stesso (altrimenti non sarebbero comprensibili al di fuori della contingenza) e che, quindi, risulteranno più “digeribili” per qualcuno appena entrato nel team.
• si riduce il “bus factor” delle esperienze acquisite su un progetto.
• si crea un documento che può essere sempre facilmente consultato da tutti i develeriani sul Wiki.
• durante la presentazione di una TPS, viene allocato del tempo per avviare una discussione in merito alla TPS stessa. Questo momento, principalmente di chiarimento per i partecipanti, a volte può servire anche al presentatore per mettere in dubbio la propria soluzione e, magari, elaborare modifiche a seguito della discussione stessa.

C’è anche qualche lato negativo?

In realtà, non molti. Certo, talvolta scorporare una singola esperienza dalla storia di un intero progetto diventa difficile, e può richiedere un’introduzione più o meno complessa del progetto stesso, al fine di comprendere appieno la TPS. 

Inoltre, non è facile riuscire a condensare in mezz’ora quello che magari è stato il lavoro di mesi interi. In quest’ottica, le TPS risultano anche ottime “palestre” per formare dei validi speaker.

Siamo convinti che i vantaggi della condivisione di conoscenze ed esperienze fra i vari team di sviluppo creino un valore davvero prezioso.