Nel tempo ho rivalutato l'importanza della pratica 'Customer on Site' così sponsorizzata dai metodi agili quale ad esempio eXtreme Programming.
Mantengo valida l'assunzione che la collaborazione deve essere costante e collaborativa; gli sviluppatori dovrebbero smettere di arguire e approfondire l'analisi facendo domande e scavando per soddisfare i veri bisogni del cliente, così come il cliente deve continuare a definire le priorità etc...
Un'ottima opportunità sarebbe avere il cliente sempre disponibile. Ciò accade di rado, anche quando il customer è 'on site'. Spesso accade che bisogna rincorrerlo e farsi dare risposte mentre viaggia tra un meeting e l'altro. Questa modalità di ricevere risposte può sembrare agile ma porta con sè vari svantaggi: ogni scelta deve infatti essere meditata; non può essere frutto della fretta.
Avendo un filo diretto di comunicazione, il cliente è stimolato a fare richieste di change request, a volte piccole ma non certo trascurabili (magari una mezz'ora di tempo); la pratica suggerirebbe di raccoglierle e considerarle in una opportuna fase di planning; ed ecco un altro problema: non sempre il planning è definito in un certo lasso temporale ben definito. Ciò che ho visto spesso succedere è che il planning viene fatto al termine di una funzionalità, quando lo sviluppatore chiede su cosa deve iniziare a lavorare.
Riassumendo, il cliente non si abitua a destinare tempi ben definiti per il planning, per le demo, per l'analisi. Ritaglia questi tempi quando gli capita, e questo è un peccato per tutti.
Secondo me il lavorare a distanza fissando tali periodi di tempo potrebbe essere una buona soluzione. Planning lunedì mattina, le demo giovedì pomeriggio e l'analisi il venerdì, ad esempio.
E' certo possibile farlo anche lavorando dal cliente, ma entrano in gioco altre componenti: il cliente comincia a criticare le pratiche di sviluppo del team e vuole imporre una atmosfera di controllo. Comincia a questionare l'efficacia del pair programming, delle pause, degli orari di lavoro etc.. tutto questo per vari fini, che forse non è nemmeno interessante analizzare.
Se non c'è un coach oppure il coach non riesce a 'difendere' il team si creano tensioni che sarebbe meglio evitare.
Dalla mia esperienza preferisco mille volte non lavorare nella sede del cliente, pur mantenendo l'abitudine di comunicare spesso e bene.
9 commenti:
in questo momento sto tentando una scelta diversa
ho volutamente evitato opportunitá allettanti come consulente per essere invece uno sviluppatore interno a web company fianco a fianco col cliente
la mia speranza é che cosi ho la possibilitá di realizzare veramente il cambiamento nell'azienda
le armi che uso sono 2, da un lato mi faccio forte dell'essperienza e quindi mi proteggo da solo senza bisogno di un coach (e tendo a proteggere anche il team quando posso cioé ... faccio il coach :) ) e dall'altro ho scelto attentamente l'azienda per cui lavoro (ora che tutti vogliono fare agile il mio compito é trovare quelli che hanno una speranza di successo, niente perdenti)
la cosa positiva per ora é che vedo chiaramente gli ostali, man mano che vengono rimossi vedo il successivo collo di bottiglia e riesco a percepire le dinamiche che si creano tra team-azienda-utenti
non so se riusciro ad avere successo , vesiamo fra 6/12 mesi
Tom, occhio che racconti l'esperienza di "developers on-site", cioè gli sviluppatori in sede dal cliente: questo non è customer on-site.
non è solo questione di nomi, davvero: se è il cliente ad essere da te, sa che sta sottraendo tempo al suo lavoro per dedicarsi al team, e quindi sa riconoscerne il valore, non fa le cose "di fretta", nei ritagli di tempo.
in questo modo è anche pià facile pianificare i momenti importanti di una iterazione: iteration planning e demo; quello che tu citi come "lavorare a distanza".
ps: se ti interessa, di "developers on-site" vs. "customer on-site" ne parla Extreme Programming Applied.
ciao
Ciao Jacopo,
secondo me non cambia molto, se non nei diversi rapporti di forza. Pure nel senso letterale di 'customer on site' ci sarebbero gli stessi problemi, mitigati dal fatto che il cliente gioca fuori casa.
Luca, in bocca al lupo!!
"se non c'è il coach a difendere il team"... Ma davvero, sembra che il team abbia bisogno della mamma! Quando il team non è maturo o ci sono altre difficoltà può ben essere che il coach dà una mano a "tenere a bada" il cliente. Che significa semplicemente facilitare la comunicazione: spiegare al cliente il perché delle pratiche (ieri un mio cliente ha "scoperto" dopo un anno che cosa sono le user stories) Il coach spiega come funzionano le pratiche agili sia al team che al cliente.
Ma se il coach per qualche motivo non c'è, non c'è nessun motivo per cui questo ruolo di comunicazione non venga preso in carico dal team. Il successo dei nostri progetti dipende da noi, dal prendere in mano i nostri destini. "Non c'era il coach a difendermi" è una scusa un po' deboluccia, non credi?
Mah
il focus non è sul coach, su chi dovrebbe 'difendere' ; il problema è alla radice: non dovrebbe nemmeno esserci l'esigenza di proteggere certe pratiche.
Alcune cose non dovrebbero essere messe in discussione, punto e basta.
Ovviamente IMHO
Ma perché non bisogna mettere in discussione certe pratiche? Io che sono un cliente che non sa nulla di agile ho ben diritto di essere dubbioso sulle pratiche non standard del team agile. Se il team ha le idee chiare è in grado di spiegare perché funzionano e perché servono. Se il team si limita a dire "non si devono mettere in discussione queste cose, punto e basta", io come cliente ho l'impressione di avere a che fare con gente poco matura. Ti torna?
No, quando mi affido ad un idraulico o un cuoco non questiono il modo in cui lavorano, non entro nemmeno in cucina ma valuto solo la bontà del piatto.
Poi si potrebbe discutere sul fatto che l'informatica non è "la stessa cosa", su questo argomento sono completamente in disaccordo: dovrebbe seguire le stesse regole di qualsiasi altro lavoro.
Rimane ovviamente in atto il fatto che il team deve continuamente riflettere sul modo di lavorare, ci mancherebbe!
Si, probabilmente lo e
good start
Posta un commento