Storie

Dal momento che le parole scritte possono essere fonte di interpretazione, le persone hanno bisogno di confrontarsi. Quindi si ha il bisogno di creare occasioni di conversazione, così da rimuovere dubbi e opacità attraverso la comunicazione verbale con uno scambio continuo e frequente di informazioni.

Il risultato di una conversazione è una rappresentazione soggettiva di un insieme di concetti, ovvero: chi partecipa alla conversazione ne uscirà con una personale fotografia mentale di quanto emerso durante lo scambio con il proprio interlocutore.

Uno studio condotto dalla psicologa Linda Kreger Silverman mostra come due terzi della popolazione abbia una percezione multi-dimensionale, ovvero la capacità di trasformare le immagini attraverso l’occhio della mente, guardandole da differenti prospettive. Il nostro emisfero sinistro è sequenziale, analitico e orientato al concetto di tempo. Al contrario, l’emisfero destro elabora le informazioni nel loro complesso, tramite un processo di sintesi, cogliendo i movimenti nello spazio. L’emisfero sinistro è caratterizzato dalle parole, l’emisfero destro dalle immagini.

Requisiti

Lo stile di management tradizionale (waterfall) concepisce i progetti come una successione logica di fasi dove l’obiettivo è stabilito a priori a fronte di un’attenta analisi dei requisiti. Quando descriviamo i requisiti in termini di astrazioni, molto spesso ci dimentichiamo di esplicitare le motivazioni che hanno portato alla loro definizione, trascurando “il perchè” dietro a un requisito. Di conseguenza, limitiamo la nostra capacità di comprendere il significato del nostro lavoro, contenendo la spinta verso l’innovazione. Kent Beck, uno dei creatori della metodologia di sviluppo software “Extreme Programming”, nel suo libro “Extreme Programming Explained: Embrace Change” scrive:

Lo sviluppo software è stato deviato dalla parola “requisito”, definita nel dizionario come “qualcosa di necessario o obbligatorio”. La parola racchiude una connotazione di assolutismo e di permanenza, entrambi ostacoli al cambiamento.

In pratica i requisiti annientano la discussione e inibiscono la capacità di adattarsi al cambiamento.

User story

Nell’iter di un nuovo prodotto coesistono due diverse prospettive: quella (quale? Dato che dopo dici quella tecnica sembra che qua ci debba essere un aggettivo) legata al business composta da clienti, utilizzatori e stakeholder, e quella tecnica legata al team di sviluppo. Lo sbilanciamento tra queste prospettive è tra le principali cause di fallimento dei progetti.

Una user story è una promessa di buona conversazione (Alistar Cockburn, computer scientist e firmatario del Manifesto Agile)

Una user story è una semplice e concisa descrizione di una funzionalità di un prodotto raccontata attraverso gli occhi di una persona (tipicamente l’utilizzatore o il cliente) che desidera quella nuova funzionalità. Citando la celebre allitterazione “card, conversation, confirmation” proposta da Ron Jeffries, le user story sono caratterizzate da tre aspetti chiave:

Un buon punto di partenza per iniziare a pensare in termini di user story è quello di utilizzare la forma “As tepee of user, I want some goal so that some reason”. L’incipit di questa formula ci mette nei panni di una persona (chi) che userà il nostro prodotto o che riceverà del valore da esso. Le due parti successive ci consentono di dare evidenza alla specifica necessità (che cosa), ovvero un qualche bisogno da soddisfare, un’esigenza implicita o esplicita, nonché la motivazione intrinseca che porta a desiderarla (perchè).

Le storie prendono il loro nome da come le usiamo, non da come le scriviamo (Jeff Patton, agile lean, UX e product design evangelist)

Il potere del “perchè”

Viviamo oramai nel pieno dell’era del capitalismo guidato dal cliente (client capitalism); un epocale salto da una logica trainata da prodotti, servizi e venditori a un ecosistema globale in cui sono i clienti a guidare il mercato.

Utilizzare le storie per descrivere gli obiettivi nel nostro lavoro non equivale soltanto a dotarci di un nuovo strumento per la gestione dei nostri progetti; la vera trasformazione deriva dal pensare alle storie come l’unità di misura principale per l’avanzamento e l’evoluzione di un progetto, non oltre il peso specifico degli output raggiunti.

Dovremmo quindi imparare a mettere al centro il “perchè”, come racconta Simon Sinek, scrittore angloamericano, nel suo famoso TED talk “Come i grandi leader ispirano azione”. Questo grande motivatore spiega molto bene l’importanza del “perchè” nella leadership, affermando che c’è un comune denominatore tra tutti i più importanti e influenti leader del mondo, ovvero, basano le loro decisioni proprio sul “perchè” e non sui “come” o sui “che cosa”.


Questo articolo utilizza citazioni tratte dal libro “Agile company” di Marco Dussin (Autore), Ivano Masiero (Autore), A. Rimassa (a cura di), editore EGEA (2 maggio 2019). Tali citazioni sono state rielaborate e adattate ai fini di argomentare sulle tematiche trattate nel libro rispettando la Legge sul Diritto d’Autore (la legge n. 633 del 1941) così da non rendere inutile la lettura del brano originale, anzi invogliando il lettore a tale lettura.