Scrum

• Le storie rappresentano funzionalità complete, che possano essere verificate dal cliente o dal product owner.
• Devono essere scritte in modo semplice e comprensibile seguendo la sintassi scrum.
• Evitiamo di fare storie che siano dei singoli task. Evitiamo di scrivere storie come se fossero dei “to do” personali. Favoriamo il lavoro di un piccolo team rispetto alla singola persona. Detto questo, capita di avere storie per una sola persona. Che il buon senso abbia il spravvento.
• La responsabilità della consegna di una storia è condivisa da tutti coloro che ci lavorano, indipendentemente dalla mole del lavoro di ognuno.
• In nessun caso si portano alla demo storie incomplete.

• Feature: è una storia che descrive una funzionalità verificabile.
• Bug: sono storie che descrivono malfunzionamenti. Seguono le stesse regole delle feature.
• Chore: sono storie non verificabili in modo evidente; installazione librerie, setup particolari ecc. I chore non seguono il normale flusso di accettazione, sono automaticamente accettati al momento in cui vengono completati. È preferibile evitare l'utilizzo dei chore includendo le attività di mantenimento nei task di una feature story.
• Release (o Goal) Sono storie che definiscono degli obiettivi; è possibile assegnare una data. Maggiori dettagli di seguito…

Release / Goal

Un approfondimento su questo tipo di storie.

È buona pratica definire un obiettivo per ogni sprint plan. Cosa vogliamo vedere la prossima settimana? Quando vogliamo rilasciare una beta? Quando andiamo live in produzione?

Il titolo della card deve essere “GOAL - [Data]”; nella descrizione viene scritto l'obiettivo da raggiungere. Tutte le storie utili al raggiungimento di quell'obiettivo devono precedere la release story. Se una storia non riguarda l'obiettivo, può essere spostata in modo che risulti successiva al goal. Questo aiuta a mantenere focus sulle cose importanti da fare.

I Goal possono essere anche generici, a lungo termine, e ci aiutano a definire una road map mentale per lo sviluppo del progetto.

Alcuni esempi:

• Goal 25 Settembre — Preparazione ambienti di staging e production e consegna visual design completi
• Goal 2 Ottobre — Deploy home page in staging e login admin
• Goal 1 Dicembre — GO LIVE!!! sito online in production

Elenco delle persone che lavorano ad una storia. Pivotal Tracker permette l'assegnazione a soli 3 utenti oltre al requester. Se una storia necessita più di quattro figure, probabilmente può essere divisa in più storie.

È la persona di riferimento per una specifica storia, non necessariamente quella che ha più competenza rispetto alla funzionalità da sviluppare e non necessariamente sono stakeholder e product owner.

• Verifica che tutti i task vengano completati per tempo e che la sotria venga deliverata.
• È un referente; è responsabile della buona riuscita tanto quanto gli altri, nè più, nè meno.
• Viene nominato e scelto dagli story owners, tra gli story owners.

I tasks sono l'elenco delle cose da fare, le cose necessarie per portare a termine l'obiettivo della storia. Per quanto possibile, i task andrebbero messi in ordine cronologico di esecuzione.

È importante scrivere anche i task più ovvi, quelli che solitamente vengono dati per scontati e ritenuti inutili e noiosi da inserire (test, deploy, installazione librerie, copia dei file su server ecc).

Definire i task in modo dettagliato ci aiuta a fare una mappa mentale delle cose da fare oltre a semplificare la stima dei punti per ogni singola attività, Ci aiuta inoltre a suddividere meglio i compiti (chi fa cosa).

• È la somma delle punti stimati per il completamento di tutti i task.
• La scala che usiamo è 0,1,2,4,6,8,12,16,24,32,100.
• Per avere un parametro comune a tutti, il valore dei punti corrisponde alle ore di lavoro, per cui 1 punto equivale ad 1 ora.
• Il valore 100 esprime la netta difficoltà nello stimare la storia; è un indicatore per cui, facilmente, la storia può essere divisa in due o più storie.
• L'associazione ore-punti non deve creare timori per cui “se ho detto 3 devo metterci 3 ore”; la stima, anche se sbagliata, serve proprio a valutare il focus-factor, serve ad imparare a valutare meglio le cose.
• È preferibile fare la valutazione in eccesso (40 minuti diventano 1 ora).

Il fatto di associare il punteggio alle ore farà inorridire i puristi di scrum; nel nostro caso specifico, gestendo più progetti contemporaneamente, con team differenti tra progetti, è necessario avere un parametro immediato e comune a tutti, che sia poi verificabile al fine di fare previsioni sempre più accurate.

Il pulsante di stato di una storia su pivotal indica l'azione successiva e non lo stato attuale.

• Quando uno qualunque degli story-owner inizia a lavorare su un task, clicca suSTART.
• Quando tutti i task di una storia sono completi, lo story-requester clicca suFINISH.
• Chi mette in condizione il cliente di verificare la storia, clicca su DELIVER.

L'accettazione o il rifiuto di una storia viene fatta in due modi:

• dal cliente, in autonomia, al momento in cui verifica
• dal product owner durante la demo

Type: feature
Title: Social login
Description: Come utente, cliccando sul bottone login nella topbar, voglio potermi loggare al sito con uno dei miei account social Facebook o twitter.
Tasks: 
    * setup gemma oauth
    * social connect facebook
    * social connect twitter
    * crud salvataggio utente
    * dev html / css
    * js per verifica errori frontend
    * testing
    * deploy
Requester: Alan
Owners: Joe, Ann, Dick
Points: 32
Status: Unstarted

In un mondo ideale, la velocity dovrebbe essere la stima dei punti realizzabili per ogni sprint. Poichè lavoriamo multiprogetto, con team variabili, non tutte le risorse lavorano in modo costante e questo rende difficile avere un parametro costante di valutazione.

Questo è il motivo per cui settiamo ogni progetto ad una velocity iniziale di 100 punti. Questo ci permette di impostare la velocity di uno sprint sulla base dell'esigenza e della disponibilità delle risorse. Poichè il 100% dell'effort corrisponde a 100 punti, se impostiamo il current al 23%, significherà che l'effort disponibile sarà di 23 ore, il che includerà nel current le storie che rientrano in quella stima.