Contesto
Lo scenario tipico vede due attori: il cliente e il team di sviluppo.
Durante lo sviluppo di un prodotto, il cliente richiede una modifica, una nuova funzionalità. Il team però è già sommerso di lavoro e quindi il cliente attende, con time to market rallentato, stress per il team che poi porta a lavorare di fretta e con bassa qualità.
Questa situazione genera caos e il sistema va fuori dal nostro controllo.
Un semplice caso d’uso
Per capire meglio la situazione, Giulio fa un esempio.
Abbiamo un Product Owner (PO), responsabile delle feature, e il nostro prodotto, un’applicazione di e-commerce con tre feature:
- A: catalogo prodotto;
- B: acquisto prodotti;
- C: review dei prodotti.
Siamo nel campo dell’e-commerce, tipicamente il prodotto sarà composta da un’app mobile, un sito e un insieme di servizi lato back-end da sviluppare.
Avremo quindi due team, uno front-end e l’altro back-end, che partono insieme a sviluppare la prima feature, e cioè il catalogo.
Il PO deve tradurre le feature in modo tale che i due team disponibili, uno per il frontend e l’altro per il backend, le possano sviluppare e rilasciare.
Lo sviluppo inizia con la feature A, e i due team partono sincronizzati. Ad un certo qualcuno lato frontend ha un problema e chiede supporto al team del backend che però chiede di aspettare perché non ha subito la soluzione pronta. Il team del frontend non rimane con le mani in mane e decide di passare allo sviluppo della feature B. Passano dei giorni e il team del backend comunica di avere una soluzione per il problema…inizia ad ad emergere del disallineamento fino a che entrambi i team torneranno sulla stessa feature A.