#1: Tieni in ordine il tuo Backlog di progetto | Guida a Scrum in 10 Step

STEP 1: backlog di progetto. Cos’è e come implementarlo all’interno del tuo progetto.

Siamo dunque alla prima puntata della nostra Guida a SCRUM…

Eccoci qui: vuoi implementare Scrum, giusto? E ti piace l’idea di farlo in maniera semplice e lineare, corretto?

Dunque questo è il primo e principale punto della serie.
E’ lo step fondamentale, non solo perché è il primo, ma perché se non riesci ad implementare questo davvero non puoi proseguire oltre con i successivi.

Quindi, in caso stessi dicendo a te stesso “Ma sì, in fondo posso anche saltarlo” ecco, ti fermo subito: non farlo. Te ne pentiresti, credimi.

Chiarito ciò, partiamo dall’inizio e per l’appunto: da dove cominciare?

Allinea tutti al progetto

Prima di tutto, prima ancora di mettervi mano in alcun modo, devi allineare il team di sviluppo sul progetto.

Il che risulta semplice nel caso in cui tu faccia parte di un team di sviluppo ridotto, ma che può risultare ben più complesso se invece parliamo di un centro di sviluppo ampio organizzato su più gruppi. È fondamentale trovare in entrambe i casi una persona dedicata al prodotto/applicazione su cui stai per implementare Scrum.

Comincia dal BAU (Business As Usual)

Ovvero, scegli un progetto standard da cui cominciare, piuttosto che da progetti troppo estesi e complessi: sembra ovvio, ma è una scelta strategica non indifferente in questa fase in cui tu ed il tuo team vi state affacciando alle basi di Scrum.

Trovati un Product Owner

Il Product Owner è la persona che avrà la responsabilità di dettare le priorità sul progetto e del fatto che vengano rispettate: il Product Owner è la cosiddetta voce del cliente, colui che ne raccoglie e articola le richieste e che rimane il referente del successo economico del progetto stesso.
È una figura nodale, quindi dovrà avere precise caratteristiche:

• Dovrà avere una conoscenza accurata dei requisiti di progetto

• Dovrà essere un buon comunicatore ed avere la capacità di trasmettere in modo chiaro i requisiti del punto precedente

• Dovrà farsi carico del successo del progetto stesso

Se, per qualunque ragione, individuare questa persona dovesse essere un problema, semplicemente non andare oltre. Aspetta di trovarla.

Perché? Perché senza questa figura il tuo progetto rischia di diventare estremamente insidioso, francamente anche nel caso in cui tu non decidessi d’implementare Scrum.
Cosa potrebbe succedere? Molto semplicemente: incapacità di gestire una raffica di richieste, mancanza di una visione chiara delle priorità e di chiarezza su requisiti, solo per fare degli esempi.

Le naturali conseguenze? Non consegnare o consegnare in ritardo, con l’aggravante che tutti sono insoddisfatti: team di sviluppo e committente.
È una situazione molto comune in qualunque team di sviluppo, lo sappiamo: facciamo in modo che non accada e risolviamo il problema prima di procedere.

Agisci come un vero Scrum Master

Per prima cosa, devi creare il tuo Backlog di Progetto.

Se hai già individuato un Product Owner potrà farlo lui, nel caso invece in cui tu stia ancora selezionando la persona, puoi cominciare a stendere il piano tu stesso.
Ma cos’è un backlog di progetto?
Nella sua forma più semplice è una lista dei requisiti che il tuo prodotto dovrà avere, messi in ordine di priorità. Spesso è creato partendo da user story che vanno ad evidenziare le richieste e necessità principali.

Chiunque può inserire requisiti, perché un team agile si basa anche e soprattutto sulla collaborazione e sul senso d’inclusione, tuttavia, e questo è fondamentale, una sola persona può dettare l’ordine di priorità.

Il backlog si prioritizza non solo tenendo conto delle richieste del cliente, ma anche rispetto agli elementi bloccanti per lo sviluppo della user story prioritaria. Per questo motivo il product owner non può imporre le priorità in modo dogmatico, ma deve evincerle dal confronto con lo scrum team che possiede le competenze tecniche.

Quali tipi di requisiti possono rientrare nel backlog di prodotto?

La risposta è: tutti. Bugs, estensioni, migliorie di qualunque tipo, problemi di carattere strettamente tecnico, eventuali rischi.

Alla prima sprint generalmente troviamo le stories di partenza, dopo la prima entrano in gioco bug, migliorie e casistiche colte in corsa dagli steakolders.

Unico accorgimento: gli elementi del backlog devono essere espressi in termini non strettamente tecnici, ma come caratteristiche ed aspetti del progetto nel suo complesso.

Questo perché il backlog è qualcosa che si condivide non all’interno del solo team di sviluppo, ma anche con il cliente o committente.

In concreto?

“Il prodotto deve essere più veloce.”

“Verificare la sicurezza del prodotto.”

Sono buoni esempi di elementi da backlog.

Priorità

Come già accennato, è una sola persona a dettare le priorità, nella fattispecie il Product Owner, posto che non si contraddicano le dipendenze tecniche.
La priorità è quella nella lista di backlog.

Gli elementi in fondo al tuo backlog sono quelli più incerti, sono punti interrogativi, ambigui, che non sono necessariamente richiesti e che non è detto tu debba davvero implementare: non perderci troppo tempo, di conseguenza.

Fissa la tua attenzione alla parte alta della lista.
Se il Product Owner ritiene che alcuni elementi inseriti in backlog siano addirittura inutili può anche eliminarli, ma è indispensabile che ne giustifichi sempre la ragione al proprio team.
Se il Product Owner ha ben chiaro il proprio ruolo ed è supportato dal Manager, di solito la scelta delle priorità non crea problemi tra gli sviluppatori.

Inseriamo qui una nostra nota al testo originale: in realtà, per come la vediamo noi, non c’è una figura nel team core e non core che possa prendere decisioni in piena autonomia, soprattutto su aspetti importanti come la rimozione di una feature. Le funzionalità incerte, imprecisi o poco utili vengono poste in fondo ed affrontate qualora il cliente dia il via e ceda il relativo budget.

Un altro punto chiave per non generare malcontenti e insofferenze nel team di sviluppo è che la lista prioritizzata sia condivisa e chiara a tutti: troppo spesso malumori e incertezze nascono proprio dal fatto che ben pochi membri del team conoscono la lista nel suo complesso, rimanendo con una visione estremamente parziale degli step da seguire.

E’ interessante notare che il fatto di prioritizzare non è una questione puramente organizzativa ma diventa strategica ai fini commerciali: fare un passo più lungo della gamba significa aggiungere costi, pazientare e “attendere il turno” nella lista delle priorità equivale invece a restare entro i termini previsti dal progetto.

Pensa anche a quel task che secondo te -sviluppatore- rappresenta un rischio e che ti fa perdere il sonno ma non ti viene mai data l’opportunità di affrontarlo per tempo.

Se lo hai inserito nel backlog può darsi che il Product Owner lo metta in cima alla lista, o potrà invece considerarlo irrilevante e segnarlo in fondo: in questo caso, però, sarà stata una scelta consapevole e definita a priori, non una spada di Damocle pendente sul capo lungo tutto l’arco del progetto.

Step #2: Come fare la stima del tuo backlog di progetto
Step #3: Come pianificare lo Sprint – I requisiti
Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo
Step #6: Come implementare lo Sprint con Scrum
Step #7: Standup e… fai sentire la tua voce!
Step #8: Traccia i progressi con un diagramma quotidiano
Step #9: Consegna in tempo!
Step #10: Rivedi, rifletti, ripeti.

————————–

Ok: a questo punto dovresti avere tutto per cominciare, giusto?

Un team, uno Scrum Master, un Product Owner e il nostro buon backlog: il prossimo passo sarà fare una corretta stima di quest’ultimo.
Ma lo vedremo nella prossima puntata ;), stay tuned.