Quando mi capita di confrontarmi con persone interessate alla tematica di introduzione di un metodo di lavoro sento spesso delle obiezioni abbastanza comuni.
Provo a riassumerle con degli slogan e una classifica. Al primo posto :
1) "Da noi non si può fare"
Spesso si pensa che la propria realtà lavorativa sia assolutamente straordinaria e unica per quanto riguarda colleghi, rapporti con il management, rapporti con il cliente. Io penso che sia abbastanza simile da tutte le parti, e si compone così:
- rapporto con i colleghi: di media buono con quelli dello stesso team. Probabilmente il fatto di lavorarci tutti i giorni incentiva l'impegno a creare relazioni piacevoli. Quello che noto è che quando ci sono team diversi si tende a parlare delle persone degli altri team 'disumanizzandoli', banalmente smettendo di chiamare per nome e cognome e sostituendo con un sostantivo generico. Ad esempio frasi del tipo: "Quando si lavora con gli *(indiani|cinesi|spagnoli|americani)* è sempre un disastro" "il team di *(analisi|test|dba|plm)* ci mette il bastone fra le ruote". E allora in questo senso vedo bene tutte quelle pratiche che portano a ripristinare i nomi e i cognomi, al fine di avere una comunicazione umana.
- rapporto con il management o con i commerciali: tendenzialmente ogni sviluppatore pensa di essere migliore del proprio manager o del proprio commerciale nei loro rispettivi lavori. Mi sbaglio? Mi chiedo quindi se è anche vero che ogni commerciale o manager pensa di essere migliore dei propri sviluppatori per quanto riguarda la codifica. Se così fosse sarebbe buffo! Ma in effetti a volte *forse* manager e commerciali ci azzeccano, quando ci chiedono delle funzionalità davvero banali tipo 'sposta questo link da destra a sinistra' e la cosa genera giorni di lavoro.
- rapporti con il cliente. E' mia convinzione che un buon cliente gioca sempre il ruolo dell'insoddisfatto ma continua a mantenerti come fornitore. Ovviamente questo non vuol dire si debba dormire sugli allora o lodarsi per sempre. Ma questo porta allo slogan numero due:
2) "Siamo lenti" oppure "il team XXX non è abbastanza produttivo"
Posto che non è possibile definire chiaramente la produttività, e qualsiasi metrica che viene _imposta_ per misurare la produttività verrà di certo raggirata, la risposta deve andare nella direzione della chiarezza. Non si è produttivi rispetto al passato? O non si è produttivi rispetto ad un altro team? La ricerca di una metrica è una scusa per cercare di sviscerare e oggettivare la percezione di lentezza di un team.
3) "Mi sembra che ci sia poca documentazione"
Sì, in certi ambienti si ama la carta. Ammetto di essere uno di quei sviluppatori che di base reputano la documentazione inutile perchè non porta valore. Ma so che in certi casi mi sbaglio. Quel che noto in verità è che quando lavoro in un team XP scrivo molta piu documentazione di quando lavoro da solo. Esempi:
- documento tutti gli script
- manutengo il file di istruzioni per il setup del progetto
- scrivo un journal delle attività ogni fine giornata
- scrivo un iteration report da consegnare al cliente ogni fine iterazione
- scrivo un riassunto di ogni meeting che si effettua
Alla base di questa critica che viene fatta all'XP o Scrum o quel che sia pongo solo un principio: che non scrivo per principio ciò che non viene letto. Se scrivo qualcosa è perchè qualcuno davvero la legge e trova valore in quel che scrivo.
4) "Non posso migliorare il codice perchè non mi viene allocato del tempo per farlo"
E' virtuoso coinvolgere il cliente nel processo di sviluppo del suo prodotto, ma non è furbo farlo ad ogni livello, sopratutto scendendo troppo nel tecnico. L'importante è mantenere i RUOLI. eXtreme Programming e Scrum li identificano con grande precisione, cosa può o non può fare un cliente e uno sviluppatore. Non ha senso chiedere a un cliente se dopo che hai risolto un baco puoi scrivere un test per garantire che non accada più: lo fai e basta. Il cliente non ha alcun diritto di entrare in merito alla gestione di task tecnici.
Immedesimandomi in un cliente, non farei fare allo sviluppatore niente di cio che non capisco, tranne poi lamentarmi degli effetti.
Nella stessa direzione va la maggior critica che viene posta al "pair programming":
5) "Non possiamo fare pair programming perchè il management non vuole due persone lavorino sulla stessa cosa"
Ok. Mettiamola così, se la situazione lavorativa è buona e il management non si lamenta, va bene non fare pair programming. Altrimenti è giusto sperimentare, coinvolgere, ma come dicevo prima è fondamentale distinguere cosa si può fare in un certo ruolo.
Se il management forza i tentativi di miglioramento del team, ed ha il diritto (diritto, non il potere) di farlo, va bene purchè poi si assume le responsabilità della scelta, prendendo quindi su di sè eventuali critiche sulla 'produttività' del team. Patti chiari, amicizia lunga. Però per ragionare in questo modo ci vuole coraggio! Dimostriamo che davvero c'è miglioramento nell'applicazione di una tecnica!
L'invito è di provare, di valutare dopo un certo periodo di tempo e non scendere a compromessi se non dopo averla imparata con una certa disinvoltura.
In bocca al lupo!
Nessun commento:
Posta un commento