Qualche mese fa, a Venezia, Fabio Armani, durante l’Agile Business Day 2017, ha proposto un’immagine che sintetizza in maniera davvero egregia la Product Ownership:
Forse non era la prima volta che vedevo quest’immagine ed avevo avuto già la fortuna di seguire questo percorso che porta dagli obiettivi alle specifiche. L’ho trovato, e lo trovo tutt’ora, davvero efficace. E quindi è un percorso che confermo e consiglio anch’io.
Queste le mie piccole recensioni/riflessioni personali dei libri citati nell’immagine:
Impact Mapping 
Libro davvero utile; veloce, conciso, scritto bene, che fornisce un percorso efficace nel prioritizzare la roadmap di un prodotto e per definire il perimetro di una prima release (ed è solo uno degli aspetti utili che ti porti a casa leggendo il libro). Importante, secondo me, leggerlo almeno una volta. Ho trovato molto utile anche un altro libro dello stesso autore (Fifty Quick Ideas to Improve your User Stories) e che serve per raffinare un po’ le tecniche. Un po’ più difficile come prima lettura da fare, perchè presuppone un po’ di conoscenze di tecniche da Product Owner; ma è un libro che torna utile consultare all’occorrenza o quando si ha un po’ di esperienza in più.
User Story Mapping
Uno dei libri più interessanti e ben scritti che ho letto su questi argomenti. L’ho trovato senza dubbi molto utile. Il contenuto merita davvero perchè non si basa solo su una tecnica (quella dello USM), ma soprattutto sugli obiettivi che quella tecnica porta alla luce (la comprensione reale di un dominio, la sua condivisione con gli altri). Inoltre trovo che insieme all’impact mapping, definisca davvero un buon percorso per tenere fissa e chiara la “big picture” e scendere nei dettagli che servono ad un team dev per rilasciare valore in breve tempo. Nelle recensioni che avevo letto si parlava del fatto che fosse un po’ ripetitivo, ma in realtà ho trovato una varietà elevata di sfumature diverse dello stesso messaggio. Sfumature che venivano da esperienze reali e quindi molto molto pratiche e di valore. Inoltre lo stile è davvero piacevole e colloquiale. L’ho letto tutto molto velocemente.
Specification By Example
Stesso autore di Impact Mapping (Gojko Adzic), ma due risultati davvero differenti. Sinceramente l’ho trovato ovvio e banale; aldilà di passare il messaggio di utilizzare gli esempi per comprendere meglio le specifiche (cosa che è francamente naturale da fare e lo dice uno che non ha molta esperienza come Product Owner); ci sono scritte delle ovvietà clamorose…Mi ha ricordato quando, molti anni fa, in una precedenza esperienza, leggevo dei corsi per iniziare il percorso di selezionatore del personale (che come manager eri tenuto a svolgere dopo qualche anno di esperienza); in questi corsi c’erano pagine e pagine che spiegavano come stare seduti davanti una persona durante un colloquio, suggerivano di non sbadigliare o di non ruotare in alto gli occhi in senso di disapprovazione, di guardare in faccia l’intervistato, ecc..ecc…..Ai tempi avevo liquidato queste cose con un “so’ americani…“ e devi dirgli tutto, passo passo, anche ovvietà che a noi italiani fanno sorridere…ma oggi non sono più tanto sicuro che sia un problema o una tendenza “americana”… per capirci vi riporto un paragrafo, inserito nel cuore del libro, che a me lascia senza parole:
From my experience, it takes far less time to illustrate requirements with examples than to implement them. Concluding that we don’t have enough information to illustrate something with examples takes far less time than coming to the same realization after trying to implement the software. Instead of starting to develop an incomplete story only to see it blow up in the middle of an iteration, we can flush such problems out during the collaboration on specifications while we can still address them—and when the business users are still available.
Non sono io che sono particolarmente competente o schizzinoso, vero? Beh ci sono interi paragrafi che vanno avanti così… Qualche spunto di approfondimento lo danno i tool indicati (FitNesse o Cucumber), ma la realtà è che è la mia anima dev ad essere affascinata dagli strumenti, il che è sempre una cosa da tenere sotto-controllo, perchè il rischio è investire tempo e forze per mettere in piedi un’infrastruttura che poi potrebbe trovare un’applicazione piuttosto limitata.
Altre buone letture da suggerirmi per arrivare dal “foglio bianco alla brutta, velocemente”?
Comments