Playbook - Metodologia
Come succede a molti, la metodologia che applichiamo non è presa alla lettera da un qualche manuale di riferimento.
Negli anni abbiamo fatto diverse esperienze e abbiamo scelto quello che funzionava meglio per noi, scartando ciò che non faceva al caso nostro.
La base di partenza sono i principi del Manifesto per lo Sviluppo Agile e la metodologia Scrum.
Da qui abbiamo poi strutturato il nostro metodo che ovviamente attinge ai nostri valori e si ispira a questa famosa citazione di Michael Jordan:
Talent wins games, but teamwork wins championships
Crediamo molto nella collaborazione di gruppo, dove il concetto di gruppo è allargato a tutti coloro che partecipano al progetto, siano essi individui che lavorano in Bitbull, il cliente o altri suoi fornitori.
Non a caso, spesso, siamo un punto di riferimento anche per questi ultimi, coordinando tutte le attività funzionali a raggiungere gli obiettivi di ogni cliente.
Distinguiamo due tipologie principali di progetti:
- Nuovi progetti - dove veniamo coinvolti dall’inizio, sono più sfidanti perché generalmente richiedono di gettare le basi per ottenere la fiducia di ogni cliente, a partire dalla fase di analisi per arrivare a quella di realizzazione. Generalmente questi progetti prevedono una quotazione a corpo ed è fondamentale il controllo di gestione, per non superare il budget.
- Progetti di business care - dove veniamo coinvolti nel prendere le redini di un progetto già avviato, il più delle volte perché ci sono problemi di qualità del codice e di performance generali. In questi casi, generalmente, la fiducia di ogni cliente la otteniamo in tempi più rapidi, mettendo in campo la nostra competenza e cominciando a risolvere problemi. Generalmente questi progetti prevedono una quotazione a consuntivo (detta anche time & materials).
Nelle sezioni seguenti, dettagliamo alcuni principi e metodologie che guidano il nostro lavoro quotidiano.
Lavoro in team
I progetti su cui lavoriamo prevedono il coinvolgimento di almeno tre tipi di figure, oltre a quella dell’Account Manager:
- Project Manager
- Team Leader
- Developer
A seconda della complessità del progetto e delle tecnologie utilizzate, possono essere coinvolte più figure per ogni tipo con diversi ambiti di specializzazione.
Strutturare il team e condividere un metodo di lavoro ci consente di governare al meglio i progetti, fare previsioni, anticipare o evitare criticità e avere i dati per affrontare il cambiamento consapevolmente.
Sprint
I nostri progetti si svolgono in sprint della durata di due settimane, un intervallo di tempo che ci consente di trovare il giusto equilibrio tra la raccolta di feedback dal cliente e l’efficienza dello sviluppo.
La raccolta di feedback è essenziale per adattare il progetto alle esigenze che cambiano nel tempo.
Lo sprint è orchestrato dal Project Manager, il cui compito è di garantire l’efficienza del processo, fluidificando il dialogo tra le parti e ottimizzando il lavoro del team.
L’analisi e la pianificazione delle attività che portano al cambiamento avvengono assieme al cliente all’inizio di ogni sprint.
Il rilascio di quanto sviluppiamo è continuo in ambiente di test e pianificato in ambiente di produzione al termine di ogni sprint.
Git workflow
Negli anni abbiamo sperimentato diversi Git workflow ma ultimamente adottiamo una nostra variante di Git Flow che abbiamo chiamato Bitflow.
Adottiamo inoltre le seguenti convenzioni:
- Il nome di un branch di sviluppo è così composto
[feature|fix]/[TASK-ID]-[short-description]. - I messaggi di commit li scriviamo con il verbo all’imperativo, per i motivi descritti qui.
ℹ Non imponiamo l’utilizzo di uno strumento specifico per l’utilizzo di Git. Alcune persone del team utilizzano i comandi da terminale, altre adottano tool come GitKraken, SmartGit o quelli integrati nel proprio ambiente di sviluppo.
Pair
Secondo la definiziona che si trova su Wikipedia, “il pair programming è una tecnica agile di sviluppo del software nella quale due programmatori lavorano insieme a una postazione di lavoro”.
Noi preferiamo allargare il concetto, chiamandolo semplicemente pair, estendendolo a tutte le attività in cui due o più persone possono portare un valore maggiore rispetto al singolo.
Ecco alcuni esempi:
- prendere decisioni tecniche
- fare analisi di progetto
- scrivere codice
- fare review di codice
- operare scelte organizzative
- pianificare il lavoro del team
Abbiamo sperimentato che lavorare insieme ci aiuta ad anticipare le decisioni migliori, a produrre risultati più robusti, a evitare errori che è più probabile commettere quando si è da soli ma anche a risolverli.
Quando dobbiamo risolvere un bug, ad esempio, dedichiamo un tempo prestabilito (mezz’ora, un’ora) alla ricerca della possibile soluzione. Se dopo quel tempo non ne siamo ancora venuti a capo, chiediamo aiuto a qualcuno del team per affiancarci.
Stime
La fase iniziale di un progetto è quella in cui l’incertezza è maggiore. Al tempo stesso, però, è in questa fase che siamo chiamati a prendere delle decisioni.
Le stime, perciò, hanno lo scopo di ingaggiare la discussione e incentivare l’analisi, per far emergere dettagli e criticità che possono diminuire il livello di incertezza generale.
È importante identificare gli obiettivi e le priorità di ogni cliente, perché fungeranno da supporto costante alle scelte che influenzeranno la stima.
Ad arricchire l’insieme di strumenti a supporto delle decisioni ci sono inoltre le cosiddette leve:
- Quality
- Scope
- Deadline
- Budget
A seconda dell’importanza attribuita dal cliente alle quattro leve, le stime possono variare.
Per approfondire l’argomento, rimandiamo a questo video di Francesco Strazzullo, in particolare al minuto 26 dove viene spiegato proprio il concetto delle leve.
È bene tenere presente un elemento molto importante: una stima può essere completamente sbagliata se non minimizziamo il più possibile ciò che può andare storto, la cosiddetta accidental complication, spiegata egregiamente in 7 minuti e 26 secondi da J. B. Rainsberger.
Di seguito un paio di articoli sul nostro blog a cui fare riferimento:
Living documentation
Abbiamo già trattato l’argomento di come oggi facciamo knowledge management nella sezione dedicata a Confluence.
Nell’ottica del miglioramento continuo, però, abbiamo iniziato a studiare nuovi approcci nella gestione della documentazione, abbracciando i principi fondamentali del living documentation descritti nell’omonimo libro di Cyrille Martraire:
- Affidabilità - la documentazione deve essere accurata e sincronizzata basandosi su una sorgente di verità univoca.
- Manutenibilità - la documentazione deve essere gestita in maniera da minimizzare il costo di manutenzione, affidandosi il più possibile a processi automatizzati.
- Collaboratività - la documentazione deve favorire il dialogo e la condivisione della conoscenza.
- Accuratezza - la documentazione deve essere accurata in modo da favorire il pensiero critico e aiutare a prendere le decisioni giuste.
Abbiamo sperimentato sulla nostra pelle quanto può costare avere una documentazione che non rispetti i principi sopra elencati in termini di tempo sprecato e decisioni subottimali.
All’inizio del 2022 abbiamo pertanto iniziato a ispirarci a tali principi con l’obiettivo di raggiungere una gestione strutturata e ottimizzata della conoscenza.