After-market

Ciao! Forse ricordi che alla fine dello scorso maggio ho avuto il piacere di fare da coach per e-xtrategy. Dopo qualche mese, immagino, di piena dedizione, di tentativi e di errori questo è quello che mi scrive Lorenzo, che tra i ragazzi di e-xtrategy è stato quello che ha proposto agli altri di avvicinarsi ai metodi agili.

[...] siamo però partiti subito cercando di adottare l’intero processo di planning agile su un progetto più semplice applicando:

  • user story
  • planning game
  • iteration meeting
  • release frequenti
  • frequente contatto con il cliente

Mi sembra un ottimo punto di partenza. Nei loro panni avrei adottato anche qualche pratica di basso livello come i test automatici, per fare un esempio, tanto per tenere sempre in testa che è la qualità del codice che permette un management agile e non questo a migliorare la prima. Ma insomma, per come la vedo io, da qualche parte è sempre necessario iniziare, no?

Lorenzo nella sua e-mail prosegue così:

Note Positive

  • Il progetto si è concluso con successo in 5 iterazioni (e non era una cosa scontata all’inizio)
  • Non ci sono stati strascichi e modifiche all’ultimo momento (perché sono state tutte “catturate” e gestite nei vari iteration meeting)
  • Alla fine abbiamo realizzato una cosa “tecnicamente” molto più semplice di quello che pensavamo all’inizio di dover fare, questo perché siamo riusciti a concentrarci sul valore di business per il cliente e non sulla soluzione tecnologica
  • Grazie agli iteration meeting tutto il team è stato correttamente tenuto informato dell’andamento del lavoro quindi ci ritroviamo oggi che la conoscenza del progetto e distribuita correttamente tra tutto il team
  • Michele Luconi (che in e-xtrategy riveste il ruolo di project manager tradizionale, n.d.r.) ha investito molto meno tempo in questo progetto rispetto alla media degli altri progetti, ma in quel poco tempo (iteration meeting e poco altro) il suo contributo è stato più proficuo del solito riuscendo a tenere comunque saldamente il timone del progetto
  • Soddisfazione interna, tutti i componenti del team erano soddisfatti ed entusiasti nel lavorare sul progetto

Preferirò dilungarmi a commentare i riscontri negativi, ma sicuramente mi piace constatare come questo gruppo di persone abbia recepito una cosa fondamentale: il core di tutta ’sta faccenda agile non è nelle pratiche. Mostrano di aver perfettamente acquisito il vero succo dello sviluppo agile: produrre di più, in modo più semplice nel fluire di una quotidianeità più lineare.

Posso farvi i complimenti i pubblico? ;)

Passiamo alle note più dolenti, io pronto a riconoscere ogni mio errore sia nella corretta trasmissione dei valori, dei principi e delle pratiche, sia nella corretta conoscenza degli stessi.

Note Negative

  • Abbiamo impiegato molto tempo in riunioni (dovuto alla nostra inesperienza ed al fatto che durante gli iteration meeting diverse volte siamo finiti a discutere delle metodologie agili e come applicarle al meglio invece che discutere del progetto)

Beh… ma questo non è un reale problema a regime. Perlomeno non lo sarà! Diverrete sempre più rapidi ed efficaci. D’altronde non esiste disciplina – degna di questo nome – senza una curva di apprendimento! C’è un asintoto di competenza ad aspettarvi laggiù! :)

2) Abbiamo avuto difficoltà nel coordinare il fornitore esterno delle creatività (per non rischiare in questo progetto il fornitore esterno ci ha fornito tutta la creatività all’inizio e non in modo incrementale)

Questo è un problema più spinoso che lo scorso inverno ha dato adito a diversi post su questo blog, su quello di Alberto Mucignat e su quello di Luca Mascaro ispirando inoltre l’intero AgileCamp2009. L’ideale sarebbe avere un creativo disposto a – e in grado di – lavorare iterativamente e incrementalmente. Quando questa figura manca ci sono delle soluzioni, ancora poco mature.

3) Abbiamo trovato difficoltà a gestire (nel modo agile) le user story che si riferivano alle attività di social media marketing che difficilmente riuscivamo ad dividere in task all’interno dell’iterazione perché erano attività costanti che erano presenti sempre durante il progetto (anzi sono presenti e continuano anche adesso che la parte di sviluppo è completa)

Si tratta sempre di modellare con la user story un valore per il business. Scritta una user story con questo spirito, la si può reiterare ad ogni… iterazione appunto! La difficoltà nel descriverne i task relativi trovo invece meriti qualche sforzo in più, perlomeno all’inizio, tanto per darvi uno spunto retrospettivo più oggettivo.

4) Abbiamo trovato difficoltà a passare dai story point alla quantificazione economica (non avendo una velocity da prendere come riferimento)

Anche qui è questione di tempo, col tempo si sbaglia sempre meno. All’inizio siate pessimisti se volete proteggervi un po’: facevate così anche prima del resto, come tutti! Però non esagerate eh… e soprattutto sappiate fare tesoro fin da subito dei primi errori.

Abbiamo comunque fatto retrospettiva e pensiamo di risolvere (o comunque ridurre) le note negative in questo modo:
problema 1) il tempo per gli iteration meeting lo stimiamo all’inizio (sappiamo quante persone saranno coinvolte e sappiamo indicativamente quante iterazioni andremo a fare ) quindi lo possiamo tenere sotto controllo. Inoltre dopo questo primo progetto pilota ne stiamo facendo partire altri e ci rendiamo conto di essere molto più “snelli” visto che ogni volta il processo ci diventa più familiare.
problema 2) Stiamo facendo tentativi e confronti con il fornitore della creatività per capire come ottimizzare la nostra collaborazione
problema 3) Crediamo che in questo progetto particolare sarebbe stato più corretto scindere in due progetti separati le attività sviluppo e di social media marketing (anche perché i punti in comune erano pochi e potevano essere gestiti da uno o due iteration meeting in comune) in modo da poter gestire le tempistiche diversamente
problema 4) Fino a che non abbiamo un baso solida di esperienza (velocity di progetti conclusi) al termine del planning game scorriamo le user story e facciamo anche la quantificazione in ore

Anche qui trovo siate sulla strada giusta. Semplicemente vi state osservando, ci state riflettendo su e state cercando soluzioni ispirate ai valori cui volete aderire. Qualcosa di buono non può che uscirne fuori.

Comunque siamo entusiasti di come riusciamo a lavorare meglio ed abbiamo fatto partire già altri 2 progetti in modo agile :-D

Veniamo ora alle domande per te:

1) Per progetti piccoli (progetti da 8-10 giornate/uomo) visto che comunque non riusciamo a farli durare 15gg ma almeno 1mese (a causa dei tempi di risposta del cliente e dei fornitori) rischiamo che il tempo di gestione del progetto diventi troppo alto. Che ne pensi? Hai sono suggerimenti/esperienze a riguardo?

No, non ho una risposta seria qui perché non ho una risposta univoca. Su alcuni progetti – uno in corsa in questi giorni – abbiamo optato per iterazioni da 5 giorni. Potremmo quindi soffrire di overhead del tutto simili a quello percepito da voi, ma noi siamo soddisfatti. Forse siamo efficienti ed efficaci in fase di planning e di discussione o forse abbiamo più bisogno di feedback di voi o forse…

2) Il creativo fa fatica (ed impiega più tempo) a lavorare in modo incrementale, risulta più conveniente (e utile) fare gran parte del lavoro all’inizio e quindi sviluppare tutta la creatività richiesta dalle user story nel complesso (e non storia per storia). In realtà abbiamo visto che questo poi è utile anche perchè il cliente vedendo subito quello che sarà l’aspetto grafico si rende conto se c’è qualcosa che non va nelle user story (mancanti o non ben definite) già in questa fase. Che ne pensi?

La questione, come scrivevo più sopra, è effettivamente aperta. Il prototipo iniziale ha il suo senso. Ma ne ha anche non ignorare come anche sul versante del layout ci siano spesso e volentieri ripensamenti e quindi prima o poi la necessità di riformulare gli obiettivi. Probabilmente si devono fare entrambe le cose: produrre un progetto di massima all’inizio (wireframe, prototipi…) e poi lavorarci sopra incrementalmente.

[...]

Altri aggiornamenti sul lato tecnico:

- abbiamo iniziato ad utilizzare SVN :-D
- stiamo cercando di utilizzare sempre di più TDD
- abbiamo inserito il pair programming per la realizzazione delle parti “delicate” di codice o per passare le conoscenze
- stiamo utilizzando la tecnica del pompiere per gestire le assistenze/manutenzioni

[...]

Grazie ancora per quello che hai saputo trasmetterci.

Buone Ferie

Quante soddisfazioni che mi date… :)
Grazie a voi ragazzi, anche di questo prezioso feedback! Oh, tenetemi aggiornato eh! Ciao!

August 24 2009 08:26 am | Dalle trincee

3 Responses to “After-market”

  1. Lorenzo Massacci on 24 Aug 2009 at 10:39 #

    Grazie dei complimenti “coach”,
    troppo buono ;-)

  2. Alessandro Astarita on 31 Aug 2009 at 19:06 #

    Cos’è la tecnica del pompiere per la gestione dell’assistenza?
    :)

  3. Jacopo Romei on 06 Sep 2009 at 19:57 #

    La “tecnica del pompiere” non è farina del mio sacco e non ricordo da chi l’ho imparata. Appena (ri)appurate le fonti faccio un post qui ;) Nel frattempo se ci incontriamo faccia a faccia, Alessandro, chiedimi pure! Ciaooo!

Trackback URI | Comments RSS

Leave a Reply