Gabriele Lana

In questi ultimi giorni sul news group it.lavoro.informatica, si è sviluppato un bel thread in cui si è parlato un po’ di tutto, ci si è chiesti se esiste la cariera tecnica, se siamo costretti ad “evolvere” in manager, se il programmatore (come tipologia di lavoro) può essere equiparato ad un operaio, e si è parlato anche di metodologie agili.

In particolare volevo riportare l’estratto di un post in quanto lo trovo abbastanza significativo

Proprio riguardo a XP, si parte dal presupposto che il cliente voglia
condividere lo sviluppo e le responsabilità che questo comporta. A me,
di clienti così, non ne sono capitati tanti. E a te? Probabilmente, lo dico io per primo,
le dimensioni dei clienti che pratichiamo sono differenti.

Si è arrivati a parlare di XP in quanto le metodologie agili hanno una considerazione del ruolo del programmatore/sviluppatore diverso rispetto a quello delle metodologie tradizionali. Di seguito la mia risposta

La dimensione del cliente non conta, e’ la mentalita’ aziendale del
cliente la discriminante, ma non penso che questo influisca
negativamente solo nell’applicazione di una metodologia agile

Le metodologie agili sono metodologie nate per supportare il rapporto
fornitore/cliente in modo che il cliente riesca a raggiungere i propri
obiettivi e che il fornitore venga pagato per il lavoro effettivo,
permettendo di valutare durante l’andamento del progetto se il
raggiungimento dell’obiettivo vale il costo della fornitura

E’ un approcio win/win basato sulla fiducia, sul rispetto e sulla
qualità, è ovvio che questo può funzionare solo con delle aziende
che “giocano per vincere” e non con quelle aziende che “giocano per
non perdere”

Il dirigente X che ha un budget Y, in una logica bacata e viziosa, non
ha come obiettivo quello di supportare gli obiettivi aziendali
attraverso la realizzazione del progetto Z, ma quello di far
implementare Z (che ha dei requisiti ben precisi) in maniera tale da
potersi parare il cu*o in qualsiasi situazione. Al dirigente X non
importa della qualità finale di Z (tanto ne è responsabile il
fornitore), ne del fatto che Z serva agli scopi per i quali è stato
richiesto (non è nelle sue responsabilità), quindi avrà tutto
l’interesse nel concentrarsi in un contratto capestro con il fornitore
piuttosto che instaurare una sana collaborazione

Chiaro che in una situazione del genere non consiglierei mai l’uso di
una metodologia agile, ma e’ anche vero che non lavoro per clienti di
questo tipo :-)

Si è sopratutto parlato del fatto che spesso i programmatori vengono visti come operai, ovvero il loro lavoro viene considerato ripetitivo, prevedibile, ecc… Molti (fra cui io) hanno argomentato contro questa teoria considerando il lavoro del programmatore come un lavoro sostanzialmente creativo. Altri hanno evidenziato il fatto che spesso il lavoro degli operai viene denigrato come non degno di essere equiparato a quello del programmatore. Come ho scritto nel thread, nessuna denigrazione, la ragione per la quale insisto tanto nel differenziare le due tipologie di lavoro è perchè la gestione taylorista dei programmatori, operata dalle metodologie tradizionali, ha causato enormi danni economici. Presto pubblicherò una serie di articoli in cui spiegherò esattamente il perchè