Tag Archive for metodologia

Chi scommette sul fallimento del progetto (e viene pagato per questo)

C’è un ruolo nel team che scommette sul fallimento delle storie. Cerca l’insuccesso con i clienti. Ama trovare la magagna.

E’ il tester.

Tutto il team, PO compreso, desiderano creare valore in un clima di zelante ottimismo. Il ruolo di tester invece prescrive la ricerca dell’insuccesso di una user story: questo fa della persona che ricopre tale ruolo un elemento chiave del team, in quanto lui solo si sente votato alla ricerca del fallimento.

Persino il PO, più o meno consciamente, desidera il successo delle user stories e ne vede il fallimento come un impedimento al normale procedere del progetto, così che lui stesso diventa il peggior nemico della qualità di quello che viene rilasciato, a volte anche accettando una certa quantità di debito (tecnologico o di usabilità) pur di rilasciare la funzionalità. Per sua fortuna il tester non ha pietà.

In “lessons learned in sofware testing” la cosa prende una piega epica: “sull’isola dei tester essi erano destinati per sempre a cercare ciò che non potrebbe e non dovrebbe esistere, sapendo che avere successo porterà miseria agli Dei”.

Parlando di tester il mio coach era stato ancora più illuminante.
Citando Diana Larsen ha presentato il valore del ruolo di tester come l’effetto di arricchimento intellettivo apportato da un elemento di eterogeneità: se in un team di sviluppatori si inseriscono dei designers, o se in un team di soli maschi si inserisce una signorina (questo era proprio l’esempio fatto), l’effetto è un ampliamento della curva gaussiana delle possibilità di variazione del punto di vista e quindi della soluzione a un problema logico o tecnico, e di fatto un ampliamento statistico del range di variabilità, e di fatto un miglioramento della qualità.
L’introduzione di un tester, che ha una visione esattamente speculare a quella di un qualsiasi altro team member, è un valore inestimabile per un qualsias gruppo di lavoro.

Le cose che mi rendono nervoso di Agile

Potreste dire di non avere dubbi sulle metodologie agili? C’è chi ha pubblicato le 10 cose più odiate dell’Agile:
http://www.allaboutagile.com/10-things-i-hate-about-agile-development/

I risultati di un survey inviato ai primi team agile della azienda per cui lavoro mi hanno portato a riflettere su alcune questioni che considero ancora aperte, e mi sono chiesto: c’è qualcosa che non capisco o non mi piace nelle metodologie agili?

Ho identificato 4 cose che mi rendono nervoso:

1. Agile non è l’arma fine di mondo. La società per cui lavoro ha abbracciato Agile con un entusiasmo tipico delle aziende giovani e dinamiche, quindi certamente abbiamo sofferto poco la serpeggiante sfiducia anti agile riportata dall’articolo, ma il rischio contrario è che porzioni dell’azienda possano accogliere l’Agile come il messia inviato da una entità superiore per dimezzare miracolosamente i tempi di sviluppo e migliorare morale e produttività. Le metodologie che usiamo servono a guardare tutto ciò che facciamo con l’occhio vigile del cliente e quello parsimonioso dell’investitore ma non ci salvano dai pericoli quotidiani del nostro lavoro.

2. siamo sicuri che con Agile si proceda più velocemente? Le tante pratiche e cerimonie, la partecipazione a community of practice, incontri, grooming etc. migliorano enormemente la qualità del prodotto e quella della vita di chi lavora, rendono felice il cliente e soddisfatto l’investitore. Ma si corre anche più veloci? Da verificare (non facile, bisognerebbe avere due team pilot, stesso progetto ma metodologie opposte).

3. quanto è capace il team di essere il capo di se stesso? L’incubo di H&R: quanto vince il naturalissimo e per altri versi vantaggioso spirito corporativo del team sull’oggettività nel giudicare un suo membro? E’ possibile la peer evaluation? Un team può fare una scheda di valutazione di un membro se ci sono di mezzo soldi e incentivi di vario tipo? Il team sarebbe in grado di allontanare un membro manifestamente improduttivo ma amabile? Se me lo chiederete in pubblico negherò di aver mai fatto simili domande…

4. può un development team lavorare con agile quando il resto dell’azienda non lo fa? Molto difficile, il marketing dovrebbe gestire iterativamente i lanci di prodotto, l’help desk dovrebbe poter ricevere una formazione sul prodotto in maniera incrementale anche ogni settimana se necessario, la gestione personale dovrebbe essere completamente calata nelle logiche di team. Non sempre però questo riesce con facilità e diventa necessario coltivare una lingua comune che consenta lo scambio di informazioni anche tra mondi molto diversi.

Favorire la partecipazione alla review

Il prodotto che io e il mio team gestiamo interessa parecchie persone all’interno della nostra azienda.
Queste persone sono sparse in 8 uffici diversi distribuiti in 6 paesi europei.
Le nostre sprint review sono perciò necessariamente in inglese e gestite in remoto con uno strumento che consente di organizzare una multiconference con condivisione di schermo e chat.
Ciò nonostante, è tutt’altro che scontato che queste persone mantengano un interesse e una partecipazione attiva alle review, visto che noi siamo solo uno degli otto team di prodotto (ciascuno con la sua review) e sopratutto visto che molti di loro ci stanno seguendo da 48 sprint review.
Immaginate quindi la soddisfazione nel riscontrare la presenza di 25 partecipanti all’ultima sprint review, praticamente tutti i responsabili helpdesk, marketing e vendite e tutti gli esperti del prodotto in esame in ognuno dei paesi in cui siamo presenti.
Alla fine della review ho fatto i complimenti al mio team: aver mantenuto l’attenzione e l’interesse di queste persone per così lungo tempo è un successo conquistato con un lungo lavoro fatto di vittorie, errori, sconfitte, dietrofront e ripartenze. Bravi!
Cosa è che rende interessante e partecipata una review ad alto rischio di incomunicabilità come la nostra?
Nel tempo ci siamo resi conto che dovevamo trovare un modo di compensare un livello medio di conoscenza dell’inglese non proprio eccelso e una certa reticenza alla comunicazione in pubblico. Ecco come abbiamo lavorato.
La review si compone di sessioni di presentazione; in ciascuna sessione ogni team member mostra un lavoro, una feature, un risultato, uno sviluppo, il prodotto di una attività concluso nello sprint appena terminato.
Why & What
Ogni sessione viene introdotta da una slide che illustra il tipo di sviluppo e dunque il perché quello sviluppo è stato fatto (cioè le motivazioni e le esigenze che sono alla base di quella scelta) e il cosa è stato in pratica fatto. Se necessario, e per lo più lo è, alcuni link rimandano alle aree di preproduzione dalle quali i risultati del lavoro saranno mostrati.
Esempio:
Gestionale delle iscrizioni – interfaccia di verifica e validazione delle iscrizioni
Perché: l’attività viene fatta ad oggi manualmente con notevole dispendio di lavoro
Cosa: nell’area di backend abbiamo inserito una lista delle iscrizioni che possono essere validate o rifiutate
Link: area di gestione
Il tutto, ovviamente, in inglese.
Uso della chat
La review, come detto, è in inglese, ma i partecipanti parlano le lingue più svariate e non sempre si sentono a loro agio nel gestire una conversazione in inglese. Scrivere è immensamente più facile per tutti.
Dunque, usiamo lo strumento di chat per interagire con i partecipanti, chi vuole può scrivere una domanda o un commento e uno dei team member più senior è incaricato di rispondere alle domande oppure, se necessario, avvertire il resto del team e il Product Owner che c’è una domanda di interesse generale che vale la pena di essere risposta a voce. Raramente c’è la necessità di aprire l’audio del richiedente e interagire direttamente, ma se desiderato ovviamente si fa.
What’s next

La sprint review si chiude sempre con una slide finale sugli sviluppi previsti per lo sprint successivo: ovviamente questa viene presentata dal Product Owner, che anche in questo caso risponde alle domande in proposito.
Ricordo le prime review dove la maggior parte dei partecipanti veniva nella nostra stanza e per creare una atmosfera accogliente e rilassata facevamo trovare qualche dolcetto. Quando l’interesse crebbe nelle sedi estere mi chiesi con cosa avremmo sostituito quello “sweet welcome”; credo che a distanza di alcuni mesi abbiamo trovato una formula altrettanto confortevole e che, oltretutto, non favorisce la carie.