Errori di comunicazione nelle specifiche del software.

Un'esperienza che ho vissuto di recente

Stavo aspettando online di chattare con un rappresentante dell'assistenza. Ovviamente ho finito per chattare per un po' con un bot che non è stato molto utile nel mio caso. Dopo un po' sono stato trasferito a un vero essere umano. Mentre aspettavo, questa è stata la mia esperienza su WhatsApp (vedi immagine). Il tempo di attesa in questi messaggi avrebbe dovuto essere il tempo che si deve ancora aspettare, secondo il testo. Lo sviluppatore ha apparentemente implementato il tempo di attesa come il tempo che si sta già aspettando.....

Questo rende l'esperienza del cliente piuttosto negativa:

1. 1. Il cliente si aspetta una risposta molto rapida

1. 1. Il cliente riceve un messaggio WhatsApp ogni minuto

Origine delle storie utente

Nei miei corsi di formazione Product Owner sottolineo sempre che il compito di un Product Owner non è quello di scrivere storie migliori degli utenti, ma di raccontare storie migliori dagli utenti.

Le User Stories sono nate quando Kent Beck, il fondatore di eXtreme Programming (XP), ricevette un feedback da un utente talmente entusiasta di ricevere una nuova funzionalità che nacque l'idea di cercare di predefinire la risposta dell'utente. Qual è la risposta che sperate di ottenere dall'utente quando sarà in grado di utilizzare la nuova funzionalità?

Per semplificare le cose, Ron Jeffries ha creato un modello. Se lavorate con Agile o Scrum, probabilmente lo avete già visto.

In qualità di
Voglio
In modo che

Descrivono OMS, COSA e PERCHÉ (si prega di notare che non COME).

Uso improprio delle storie utente

L'errore che spesso si commette è che questo modello viene visto come il nuovo modo di registrare le specifiche dei requisiti. Cercando di catturare nel modello requisiti che non hanno alcuna relazione con l'utente. Per esempio:

Come Developer voglio un database per poter memorizzare i miei dati.
In qualità di Product Owner ho bisogno di un rapporto da mostrare all'amministratore delegato.

Interi documenti e blocchi di testo vengono allegati anche agli elementi di Jira, TFS, ecc.

Le User Stories non servono a questo, ma sono la base per la raccolta dei requisiti sociali, ovvero per migliorare le conversazioni tra sviluppatori e utenti in merito agli utenti e alle funzionalità. In alternativa agli utenti, si possono usare anche i rappresentanti o i cosiddetti stakeholder, che però devono capire e rappresentare davvero gli utenti.

Come allenatore della prima squadra XP, Ron Jeffries ha introdotto le 3 C: Carta, Conversazione e Conferma.

• • Scheda: Un cartoncino con il titolo e una o due frasi di spiegazione.

• • Conversazione: Discussione con l'intero team su ciò che si desidera

• • Conferma: Registrare come determinare se è conforme

Non è necessario che le Storie Utente siano perfettamente definite prima della conversazione con il team. Durante l'#BacklogRefinement, la definizione della User Story può essere modificata e i criteri di accettazione possono essere riscritti o aggiunti.

Come possiamo aiutarvi

Se siete interessati ad avere conversazioni migliori, date un'occhiata al nostro Workshop User Story Mapping

Ne parleremo anche nel nostro Certified Scrum Product Owner formazione, consultate il nostro programma qui sotto.