Story / Impact Mapping – Contesto, principi e panoramica

Lo sviluppo software a piccoli lotti è positivo
Ci sono molti vantaggi nell'adottare l'approccio Small-Batch (molti piccoli passi singoli) nello sviluppo software:

• Feedback più rapido
• I problemi vengono localizzati
• Rischio ridotto
• Più pressione e routine per la riduzione dello sforzo

Lo sviluppo software naive a piccoli lotti non è altrettanto positivo

Se però si affronta lo sviluppo software Small-Batch in modo ingenuo, c'è anche uno svantaggio significativo: la mancanza di connessione con l'obiettivo complessivo.

Jeff Patton ha descritto questo fenomeno attraverso l'esempio di un albero e un sacco pieno di foglie:

"Immagino un albero il cui tronco è composto dagli obiettivi e dai benefici desiderati che guidano il sistema. I rami grossi sono gli utenti, i rami più sottili e i ramoscelli sono le capability di cui hanno bisogno. Le foglie rappresentano le User Story abbastanza piccole da essere sviluppate nelle iterazioni.
Dopo tutto questo lavoro, dopo aver costruito così tanta comprensione condivisa, ho la sensazione che togliamo tutte le foglie dall'albero e le infiliamo in un grande sacco – e poi tagliamo l'albero."

Il "sacco pieno di foglie" si riferisce a un elenco prioritizzato di attività senza contesto in un Backlog e riflette la comprensione ingenua dei "Backlog" che, a mio avviso, è particolarmente tipica dei principianti Agile. Anche se in teoria sembra un approccio Small-Batch, il "sacco pieno di foglie" recide il collegamento con i principi e gli obiettivi sottostanti, minando così l'autonomia.

I 5 attributi di un approccio Small-Batch efficace nello sviluppo software

Un approccio più efficace va però oltre la semplice suddivisione in unità più piccole. Un approccio più efficace:

• enfatizza l'intenzione effettiva attraverso gli obiettivi.
• enfatizza la connessione logica tra gli obiettivi e le attività necessarie.
• rappresenta visibilmente gli obiettivi, le attività e le connessioni per rivelare eventuali incongruenze e malintesi.
• è orientato al lavoro collaborativo.
• è iterativo, ovvero all'inizio non è richiesta la completezza.
• Story/Impact Mapping vs. sviluppo software Small-Batch
  Sia lo "User Story Mapping" di Jeff Patton che l'"Impact Mapping" di Gojko Adzic sono risposte (in gran parte equivalenti) agli approcci ingenui per la determinazione dei singoli passi più piccoli nello sviluppo software Small-Batch (ovvero per la creazione dei Backlog). Lo descriverei così:

Nota: questo processo di Impact Mapping dovrebbe essere iterativo. È qui rappresentato in modo sequenziale solo per una migliore comprensione. Non è né necessario né consigliabile eseguire ogni passo in questo ordine. Al contrario, puoi iniziare dal punto in cui ti trovi e scambiare i passi secondo necessità.

1) Identifica gli obiettivi
Cosa vuoi raggiungere?

Dovrebbe essere qualcosa che si può osservare e quindi anche misurare. Per questo motivo mi piace il termine "impatto", perché implica che qualcosa sia misurabile. Tuttavia, "obiettivo" è più comune e inoltre non mi piace introdurre nuova terminologia quando non è strettamente necessario.

Possono esserci più obiettivi.

2) Identificare ruoli e attività
Chi deve partecipare a un'attività per raggiungere gli obiettivi? Ovvero, quali attività devono essere eseguite da qualcuno per raggiungere gli obiettivi?

In generale preferisco iniziare dalle attività. Nella pratica, però, è piuttosto un processo iterativo.

Nota che "ruolo" non significa "persona". "Persona" può riferirsi ad altri ruoli che non hanno a che fare con i tuoi obiettivi, ma piuttosto con i propri obiettivi. Questo di solito significa che bisogna aggiungere obiettivi supplementari da supportare.

3) Identificare le capability
Qual è il prerequisito affinché il ruolo possa svolgere un'attività?
Le capability non devono necessariamente essere qualcosa integrato nel software.

4) Identificare feature e story
Cosa deve essere fatto per creare o rendere possibili le capability?
Le Story dovrebbero essere composte da lavori più piccoli. Le Feature servono più a consentire discussioni a un livello più dettagliato.

Questo testo proviene dal blog di Jason Yip ed è stato tradotto in italiano.