metriche Agili

(secondo me…)

Le metriche agili misurano gli aspetti chiave di un processo quando si intende applicarle ad una iniziativa di trasformazione digitale. Tutti siamo stati coinvolti almeno una volta in un progetto e ci ricordiamo come il fatto di non avere tracciato fin dall’inizio i dati abbia reso poi difficoltoso rispondere, ad esempio, alla classica domanda: “siamo sulla buona strada per il rilascio?”. D’altro canto, raccogliere dati senza un obiettivo chiaro fin dall’inizio, potrebbe trasformare queste statistiche in un’arma, mettendo in competizione i team tra di loro o giustificando il lavoro extra nel fine settimana. Monitorare e condividere metriche agili può ridurre la confusione e far luce sui progressi (e sulle battute d’arresto) del team durante tutto il ciclo di sviluppo. Ma è fondamentale conoscere il proprio business, perché si tratta di costruire il prodotto giusto, al momento giusto, per il mercato giusto. Bisogna individuare i criteri di successo per ogni requisito di prodotto, ad esempio il tasso di adozione da parte degli utenti finali o la percentuale di codice coperta da test automatizzati. A prescindere che si adotti Scrum o Kanban, ognuna di queste metriche ti aiuterà a capire meglio il processo di sviluppo, rendendo più facile il rilascio del software.

Burndown Sprint

I team Scrum organizzano il lavoro in finestre temporali ben definite e prevedono quanto lavoro potranno portare a termine. Un report Burndown Sprint traccia sull’asse X il tempo mentre sull’asse Y la quantità di lavoro rimanente, misurata in story points oppure in ore. L’obiettivo è quello di completare tutti i lavori previsti entro la fine dello Sprint. La bravura di un team quindi sta nel rispettare le previsioni, non è sempre facile almeno all’inizio. L’importante è non cedere alla tentazione di alterare i numeri dichiarando un elemento completo prima che lo sia davvero. Può sembrare positivo a breve termine, ma a lungo termine ostacola solo l’apprendimento e il miglioramento.

Burndown Epic

Con questa metrica ci si concentra sul rilascio del lavoro, l’epica circoscrive un sotto insieme di attività su un corpo di lavoro più ampio rispetto a quello dello Sprint Burndown, e guida lo sviluppo sia per i team Scrum che per quelli che invece adottano Kanban. Per esempio il blocco di attività da svolgere per un team Scrum può contenere lavori appartenenti a diverse epiche e versioni, quindi è importante tenere traccia sia dell’avanzamento dei singoli sprint sia delle epiche e delle versioni. Con il termine “Scope Creep” ci si riferisce a quella situazione in cui vengono inseriti più requisiti in un progetto definito in precedenza. Per esempio, se il team sta consegnando un nuovo sito web per l’azienda, potrebbero essere richieste nuove funzionalità dopo che i requisiti iniziali sono già stati delineati. Tollerare uno Scope Creep durante uno sprint è una cattiva pratica. Invece, lo Scope Change all’interno di epiche e versioni è una conseguenza naturale di uno sviluppo agile. Mentre il team si muove attraverso il progetto, il proprietario del prodotto può decidere di assumere o rimuovere il lavoro in base a ciò che sta imparando. Il grafico Epic Burndown permette di rendere tutti consapevoli del flusso di lavoro (e del “riflusso”) all’interno di ciascuna Epic e di ciascuna Versione.

Velocity

Con questa metrica si indica la quantità media di lavoro che un team Scrum compie durante uno Sprint, misurata in punti storia o in ore, ed è molto utile per le previsioni. Il Product Owner può utilizzare un Velocity Report per prevedere la velocità con cui un team può lavorare sul backlog, perché il rapporto tiene traccia del lavoro previsto e completato su diverse iterazioni: più iterazioni saranno registrate, più accurata sarà la previsione. Diciamo che il Product Owner vuole completare 500 punti storia in arretrato. Sappiamo che il team di sviluppo generalmente completa 50 punti storia per iterazione. Il Product Owner può ragionevolmente supporre che il team avrà bisogno di 10 iterazioni per completare il lavoro richiesto. È importante monitorare l’evoluzione della velocità nel tempo. I team esistenti possono monitorare la loro velocità per garantire prestazioni costanti nel tempo e possono confermare se una particolare modifica del processo ha apportato o meno miglioramenti. Una diminuzione della velocità media è di solito un segno che una parte del processo di sviluppo del team è diventato inefficiente e questo problema dovrebbe essere affrontato durante la prossima retrospettiva. La velocità di ogni team è unica. Se la squadra A ha una velocità di 50 e la squadra B ha una velocità di 75, ciò non significa che la squadra B abbia un rendimento maggiore. Poiché la modalità di fare stime di ogni squadra è unica, lo sarà anche la loro velocità. È molto importante tenere presente questo aspetto. Resisti alla tentazione di confrontare la velocità tra le squadre. Bisogna misurare il livello di sforzo e di produzione del lavoro in base all’interpretazione unica che ciascun team dà sotto forma di story point.

Control Chart

Questo grafico che mette in relazione il tempo di ciclo delle singole attività, il tempo totale da “in corso” a “fatto”. I team con tempi di ciclo più brevi avranno probabilmente una maggiore produttività e quelli con tempi di ciclo costanti per molti aspetti saranno più prevedibili nell’esecuzione del lavoro. Il Cycle Time è una metrica primaria per i team che adottano Kanban, ma anche i team Scrum possono beneficiare di un tempo di ciclo ottimizzato. Questa misurazione del tempo è un modo efficiente e flessibile per migliorare i processi di un team poiché i risultati dei cambiamenti sono percepibili quasi immediatamente, consentendo di apportare immediatamente ulteriori modifiche. L’obiettivo finale è quello di avere un tempo ciclo coerente e breve, indipendentemente dal tipo di lavoro (nuova caratteristica, debito tecnico, eccetera).

Diagramma di flusso cumulativo

Il Cumulative Flow è uno strumento chiave per chi adotta Kanban, perché aiuta a garantire che il flusso di lavoro all’interno del team sia costante. Troviamo il numero di attività / issue sull’asse Y, e il tempo sull’asse X. Si usano dei colori per indicare i vari stati del flusso di lavoro, in questo modo a colpo d’occhio si vedranno i colli di bottiglia in combinazione con i limiti WIP. Il diagramma di flusso cumulativo dovrebbe essere liscio da sinistra a destra. Bolle o spazi vuoti in qualsiasi colore indicano carenze e colli di bottiglia, quindi si deve cercare di livellare le bande di colore in tutto il grafico. Altre metriche importanti in un programma di Digital Transformation Agile sono:

  • quanti difetti (bug) sono stati riscontrati durante lo sviluppo ?
  • quanti difetti invece dopo il rilascio ai clienti ?
  • quanti difetti trovati da persone esterne al team ?
  • quanti difetti vengono rinviati a una versione futura ?
  • quante richieste di assistenza clienti arrivano ?
  • qual è la percentuale di copertura dei test automatizzati ?

I team agili dovrebbero anche considerare la frequenza di rilascio e la velocità di consegna. Alla fine di ogni sprint, il team dovrebbe rilasciare il software per la produzione. Quante volte ciò sta effettivamente accadendo? La maggior parte delle release viene consegnata ? Nella stessa ottica, quanto tempo ci vuole perché il team rilasci una correzione d’emergenza (patch) in produzione ? Le metriche sono solo una parte della costruzione della cultura di un team. Essi forniscono una visione quantitativa della performance del team e forniscono obiettivi misurabili per il team. Anche se sono importanti, non fatevi ossessionare. Ascoltare i feedback del team durante le retrospettive è altrettanto importante per aumentare la fiducia nel team, la qualità del prodotto e la velocità di sviluppo durante il processo di rilascio. Utilizzate sia il feedback quantitativo che quello qualitativo per guidare il cambiamento.

Riferimenti e approfondimenti:

scrum basic

Il tuo capo ha sentito parlare di questa “moda” dell’Agile, e tu sei stato chiamato a ricoprire il ruolo di Scrum Master per il nuovo team.

Hai già comprato in fretta e furia il libro “Fare il doppio in metà tempo” (qui su Amazon https://amzn.to/2F6D76J) del mitico Jeff. Te lo aveva suggerito quel consulente che un paio di settimane fa era venuto a mostrarti come avresti potuto migliorare la gestione dei progetti nell’azienda dove lavori…

Ti sei reso conto che creare “barrette colorate” orizzontali su quel programma di calcolo elettronico non è la stessa cosa che stabilire relazioni per armonizzare il lavoro di squadra. Dietro alle barrette ci sono le persone e uno degli impegni più rilevanti per uno Scrum Master è organizzare le riunioni.

Può sembrare una cosa semplice, ma spesso è più complessa del previsto:

  • quando sono disponibili le persone interessate? quanti fusi orari devo tenere presente ?
  • devono essere presenti a tutte le riunioni ?
  • quando finisce lo Sprint ? Prima della Sprint Review oppure possiamo lavorare sulle cose da fare solo dopo quell’incontro?
  • dobbiamo aspettare che certe riunioni siano effettuate per vedere accettato il lavoro svolto ?

I team risolvono il problema della programmazione delle riunioni in modi diversi, più o meno efficaci. Non posso insegnarti niente, non intendo anzi insegnarti niente, semplicemente ti racconto quella che è stata la mia esperienza in questi anni.

Come sappiamo le tre riunioni più importanti che segnano la fine e l’inizio di uno Sprint sono: la Sprint Review (o Demo); la Sprint Retrospective (relativa allo sprint precedente) e la Sprint Planning (per lo sprint successivo).

Io trovo comodo pianificare questi tre briefing tutti nello stesso giorno perché hai il vantaggio di fare “tutto in un giorno”. Poiché gli incontri di Sprint Review e di Retrospective possono essere intensi e durare molto, raccomando di separarli con una pausa prima di passare alla pianificazione dello Sprint.

Può essere la pausa pranzo, una passeggiata attorno all’edificio, una chiacchierata con i collegi, lo scopo è rilassare i toni, distendere le menti (per questo suggerisco di evitare ad esempio partite a calcio balilla, che potrebbero invece aumentare la competizione interna al team).

La retrospettiva Sprint segna la fine della Sprint precedente. La pianificazione dello Sprint segna l’inizio della Sprint successiva. Sprint Review (Demo). L’altro approccio possibile è invece dedicare un giorno esclusivamente per lo Sprint Planning, un giorno diverso dalla retrospettiva e dalla demo. Sempre meglio iniziare di buon mattino.

Nel caso alcuni membri della tua squadra fossero lontani geograficamente e addirittura avessero fusi orari diversi, bisogna regolare gli orari in modo da consentire a tutti quanti la partecipazione agevole. La sequenza delle riunioni potrebbe non essere ideale per far fronte alle difficoltà dei fusi orari. Nel caso spostate in avanti di un giorno la riunione, in un orario intermedio per tutti.

Più in generale, la regola potrebbe essere che tutti i lavori dichiarati sotto forma di User Stories dovrebbero essere completati prima della fine dello Sprint il lunedì mattina. Quindi iniziare a lavorare il martedì e magari organizzare il Backlog Refinement di giovedì. Ricordati anche che la retrospettiva segna la fine dello Sprint. Dopo la retrospettiva, lo Sprint è finito. Nessun aggiustamento di velocità, nessun ritardo nel lavoro per fare qualcosa! Altrettanto importante: la “Demo” mostra solo il lavoro già accettato dal Product Owner.

Quasi lo stavo per dimenticare… il libro della settimana si intitola “Ottieni il meglio dalle tue retrospettive Agili” e lo trovate su Amazon a questo indirizzo: https://amzn.to/2HjMaaj

buona lettura …

Microsoft Project e JIRA: migrare o integrare ?

È una domanda ricorrente alla quale rispondo in modo schietto. Parlo a ragion veduta di Microsoft Project per avere iniziato ad usarlo “per necessità” fin dal 1991 nella sua versione per Apple Macintosh (in realtà Project venne rilasciato nel 1984, ma vi rimando a Google e a Wikipedia per la “storia” del prodotto, che come tanti altri di casa Microsoft NON è stato inventato dai programmatori di Bill Gates ma era il prodotto di una software house indipendente poi fagocitata).

Microsoft Project è un programma ancora molto diffuso, occorre ammetterlo, ma rappresenta un modo di gestire i progetti che andava bene prima dell’era di Internet. Poi, basti pensare che la rappresentazione delle attività mediante un diagramma di Gantt risale al 1917.

Un diagramma di Gantt permette dunque la rappresentazione grafica di un calendario di attività, utile al fine di pianificare, coordinare e tracciare specifiche attività in un progetto dando una chiara illustrazione dello stato d’avanzamento del progetto rappresentato.

Le applicazioni più moderne per il Project Management espongono oramai una interfaccia utente basata sulla metafora del Web e consentono chi più chi meno, l’aggiornamento in tempo reale dello stato delle attività.

Atlassian JIRA è una di queste applicazioni. Anzi, a mio modesto parere è l’applicazione più idonea a sostituire del tutto l’antiquato Microsoft Project.

Sì, parlo di sostituzione e non di “integrazione”, perché una domanda che faccio sempre ai miei clienti quando mi chiedono se JIRA “supporta” l’integrazione con Microsoft Project è: “hai veramente bisogno di integrare i due prodotti?” e subito dopo: “hai veramente bisogno di esportare e/o importare le attività da / verso JIRA per trattarli con Microsoft Project solo per ottenere una rappresentazione di Gantt?”.

Cosa offre di base Microsoft Project?

  • Tracking
  • diagrammi di Gantt
  • pseudo gestione delle risorse umane

Abbastanza poco rispetto a quello che può invece diventare JIRA quando viene abbinato ad esempio a BigPicture:

  • Tracking (in tempo reale);
  • Roadmap (in tempo reale);
  • diagrammi di Gantt;
  • piena gestione delle risorse umane;
  • piena gestione dei team;
  • mappatura dei rischi (in tempo reale);
  • pieno supporto alla metodologia Agile SAFe.

È lo stesso ragionamento che potete fare quando comparate Microsoft Outlook con Google Mail… Quale dei due è il più economico ? Quale dei due è il più efficiente ? Quale dei due è il più facile da usare ?

Un altro esempio: prima dell’invenzione dei Google Sheets, era “naturale” pensare ad un foglio di calcolo elettronico usato da una sola persona e poi condiviso con gli altri collaboratori tramite posta elettronica, e spendere molto tempo per “allineare” le versioni con tutte le modifiche eventualmente apportate.

Lo stesso vale tra Microsoft Project e JIRA. Quindi coraggio: mollate Microsoft Project e venite a lavorare nel futuro-presente.

Il primo innegabile vantaggio sarà quello che smetterete di sperperare il tempo in travasi continui di informazioni da Microsoft Project con esportazioni in file CSV o in formato Microsoft Excel per importarli verso JIRA e viceversa quando dovrete collaborare con il vostro Team, magari distribuito su più sedi geografiche.

C’è già tutto quello che vi serve in JIRA e BigPicture lo completa perfettamente.

Parliamo adesso dei costi.

Anche sommando i costi di una configurazione base di JIRA e quella del plugin aggiuntivo BigPicture probabilmente spenderete ancora meno che configurare una soluzione con Microsoft Project.

A marzo 2018 una licenza per utente singolo di Microsoft Project costa circa 500 euro.

JIRA in versione server per 10 utenti costa 10 euro circa; BigPicture per 10 utenti costa 10 euro circa, arrotondando per eccesso. Totale 20 euro circa, diciamo 2 euro per utente.

Quindi 2 euro contro 500: dovrebbe bastare solo questo aspetto per convincervi a lasciare perdere per sempre Microsoft Project in favore di JIRA.

JIRA viene concesso in licenza per utente, mentre Microsoft Project viene generalmente concesso in licenza per installazione.

La proposta di Atlassian rimane ancora la più economica (generalmente sono necessarie meno licenze di JIRA rispetto ad una eguale configurazione con Microsoft Project).

Inoltre, JIRA si basa sulla metafora del web, quindi funziona su tutti i principali sistemi operativi: da quelli Apple a quelli di Microsoft ovviamente, passando per Unix e Linux. Microsoft Project funziona SOLO sul sistema operativo della casa di Redmond.

Avete provato ad aprire un file in formato MS Project 2010 con Microsoft Project 2007 ? Un delirio. E se la versione di MS Project fosse la 4.0 la ’98 o quella 2002/2003… ?

JIRA non ha limitazioni di versione, un punto ulteriore a suo favore.

Come si differenzia JIRA rispetto a prodotti come Asana, Rally, Pivotal Tracker o lo stesso Trello (da poco accasatosi in Atlassian) ?

Se dovessi citare le tre caratteristiche più distintive di JIRA rispetto al resto, direi:

  • JIRA ha fatto passi da gigante rispetto ai concorrenti, è il software più personalizzabile ed è più completo rispetto a Trello;
  • supporta le principali metodologie di Project Management: Agile Scrum, Kanban, ScrumBan;
  • JIRA può contare su un marketplace di componenti aggiuntivi molto vasto che lo completano secondo le specifiche esigenze.

Per rispondere alla domanda iniziale quindi, proprio l’ultimo aspetto è quello che vi suggerisce che migrare in modo definitivo è la soluzione migliore.

noi vediamo le cose per come siamo noi, non per come sono realmente

il Talmud dice (più o meno): “noi vediamo le cose per come siamo noi, non per come sono realmente”.  Forse è per questo che quando sento parlare di “Agile alla moda” … pardon dell’Agile alla Spotify…

io in questo disegno ci vedo, ad esempio una corrispondenza ad una sola persona fisica per ogni “pupetto” e NON  una persona che appartiene, contemporaneamente, a più team agili magari con ruoli diversi ed ingaggiata nello stesso momento… 

p.s. ingrandendo l’immagine si notano tanti particolari che se bene interpretati (superando il Talmud…) ci potrebbero aiutare ad evitare gli errori e le storture del passato ed avvicinarci ad un modo di lavorare migliore e più semplice…

#intelligentipauca

https://lnkd.in/enpPVyj

 

Spotify-Engineering-Culture-Part1