I talk m’interessano relativamente, è raro assistere ad un talk che parla di un’argomento di mio interesse all’interno del quale si dicano cose che non ho già letto e/o sentito, chiaramente questo non dipende dalla preparazione dell’oratore ma dal fatto che non può dar per scontato che tutti i presenti conoscano già determinati argomenti. Alcuni tipi di talk però fanno eccezione, per esempio gli experience report mi piacciono molto

Giovedì 07/05/2009, la giornata inizia subito bene, parto con il treno delle 6:30 da Milano con l’iphone pieno di conferenze (quale cosa migliore di andare ad una conferenza guardandosi altre conferenze), direzione: Firenze, scopo: partecipare a bettersoftware. Arrivati a Firenze sto per scendere dal treno e becco Simone Genini, grazie al suo aiuto riesco a raggiungere appena in tempo l’albergo della conferenza (io ho una capacità di perdermi incredibile, talmente incredibile che neanche iphone + google maps mi salvano)

Primo talk (mannaggia a chi ha deciso di far iniziare la conferenza così presto) è stato quello di Antonio Cangiano sul mondo delle startup, lui stesso ne sta facendo partire una e ha condiviso con la platea i suoi pensieri. Sabato (durante pycon3) ho avuto modo di parlare con Antonio, è una persona molto simpatica e socievole, mi ha spiegato le idee che stanno alla base di thinkcode (la sua startup) e devo dire che sarò sicuramente uno dei loro primi clienti (se siete appassionati di programmazione vi consiglio di iscrivervi alla loro ml, se non siete appassionati di programmazione avete sbagliato blog :-))

La giornata è proseguita con i talk di Matteo Vaccari, Francesco Cirillo e Simone Casciaroli (Simone perchè non hai un blog?), tre experience report degni di nota.

Scena madre della giornata: Francesco Cirillo sale sul palco e attacca con la campagna anti-if, dice che ha delle magliette da regalare, ma le regalerà solo a chi dirà qualcosa in grado di colpirlo, al che Jacopo Romei che era seduto di fianco a me si alza e urla “Sei Bellissimoooo!!!”, scoppiano tutti a ridere e lui si becca la maglietta, grande Jacopo, uno ottimo esempio di pensiero creativo :-)

Cosa vuol dire che le metodologie Agili possono funzionare soltanto in un mondo perfetto? Considerando anche i commenti degli altri, possiamo interpretarlo come: “Le metodologie Agili possono funzionare solo in un mondo perfetto perchè nella realtà esistono dei vincoli che non possono essere superati”

La risposta che ho dato quando mi è stato esposto questo dubbio è perfettamente in linea con il commento di Vieri del Bianco

In una recente intervista è stato chiesto a Kent Beck cosa voglia dire “essere agili” (il DOMANDONE…). La sua risposta mi ha decisamente colpito (estremamente sintetica e in definitiva illuminante): “My definition is that you accept input from reality and you respond to it”.
Ma questa è l’antitesi del mondo perfetto… io la interpreto con l’essere capaci di modificare gli strumenti/metodologie/pratiche/valori per plasmarsi sulla “realtà” (e la realtà non è solo il cliente, o l’ambiente di lavoro e le sue regole, ma anche la squadra con cui si ha a che fare).
Questo è, a mio avviso, il cuore dei metodi agili (e l’Agile Manifesto sembra confermarlo).

Pensate solo al motore della natura evolutiva delle metodologie Agili: la retrospettiva. Il team si interroga continuamente sul proprio metodo di lavoro e lo fa basandosi sia su dati soggettivi, ma sopratutto su dati oggettivi = metriche raccolte durante il processo produttivo, metriche che vengono stabilite basandosi su quelli che sono i reali obiettivi del progetto e quindi del suo committente. Questo comporta un continuo adattamento del team e del metodo che deriva da un confronto costante con i risultati ottenuti. Questa è l’essenza delle metodologie Agili: un estremo realismo, una vocazione alla trasparenza e alla comunicazione

Tuttavia, come è stato accennato nei commenti, a volte la realtà impedisce la corretta applicazione di alcune pratiche rendendole controproducenti, altre volte i valori e i principi vengono talmente disillusi da rendere impossibile l’adozione di una metodologia agile, è vero, non lo nego, anch’io mi sono trovato in situazioni simili e non ho potuto fare altro che arrendermi all’evidenza

Facciamo un ragionamento però: una delle critiche che vengono mosse alle metodologie Agili è quello di essere “acqua calda”, nient’altro che buon senso applicato, il che è sostanzialmente vero, ma quindi cosa vuol dire quando il buon senso non può essere utilizzato? Probabilmente quelli che consideriamo come vincoli sono in realtà vizi che possono e dovrebbero essere eliminati, vizi che in realtà rappresentano delle grosse opportunità di miglioramento

Al che sorge spontanea la domanda: “Quando dovremmo sfruttare l’adattabilità delle metodologie Agili per aggirare un ostacolo e quando invece l’ostacolo dovrebbe essere abbattuto?”. Ovviamente non esiste una risposta che può essere data a priori, un consiglio? In un momento di calma e lucidità identificate quali sono i vostri veri obiettivi, valori e principi, confrontatevi sempre con essi in maniera obiettiva e misurabile, se lavorerete per migliorarvi continuamente, siete sulla buona strada :-) Ovviamente lo scrivo più che altro rivolgendomi a me stesso :-)

Se avete altri commenti a riguardo mi piacerebbe sentirli, altrimenti possiamo passare alla prossima domanda: “Quale aumento di produttività possiamo aspettarci da un team che inizia ad adottare SCRUM? In quali tempi?”

L’articolo indica alcune pratiche che possono essere utilizzate dai programmatori per “mantenere un programma nella propria testa”, inizialmente sia l’obiettivo dell’articolo che alcune delle pratiche proposte mi hanno un po’ disorientato in quanto in apparente netto contrasto con quanto dettato dalle metodologie Agili: “Se Paul Graham è un mito, e ha ragione, allora hanno torto le metodologie Agili?” No, hanno ragione entrambi, i principi che stanno alla base sono gli stessi, come al solito tutto torna :-)

Prendiamo per esempio una delle pratiche più forti fra quelle proposte: “Keep rewriting your program”; come dargli torto? Capita spesso che durante la scrittura di un programma un programmatore arrivi ad un momento in cui la sua conoscenza attuale del problema e della relativa soluzione non sia più rispecchiata dal codice, riscrivendolo potremmo inserire nel codice tale conoscenza e quindi otterremmo del codice migliore. D’altra parte molti conosceranno la “Sindrome del secondo sistema” e sapranno quindi che la maggior parte delle riscritture dei progetti software risulta fallimentare. “Come è possibile che entrambe queste evidenze empiriche siano vere? Come risolvono la questione le metodologie Agili?”

Cos’è il refactoring se non un’attività di continua riscrittura del codice? Kent Beck spiega perchè eXtreme Programming è eXtreme: tutte quelle pratiche che hanno dimostrato nel tempo di essere valide sono state portate all’estremo. La revisione del codice funziona? Bene, revisioniamo il codice sempre! = Pair Programming. La riscrittura di programmi porta a dei programmi con un design migliore? Bene, riscriviamo i nostri programmi continuamente! = Refactoring

Attraverso la pratica del refactoring possiamo trasformare (riscrivere) continuamente il nostro codice affichè rispecchi nella maniera migliore possibile la conoscenza che attualmente abbiamo del dominio del problema e della sua soluzione. Continuamente! Il trucco è sempre quello: se un’attività è rischiosa, difficile, costosa, ma potenzialmente di grande valore, quello che dobbiamo fare non è evitarla o prevenirla, ma trovare un modo per renderla meno rischiosa, meno difficile e meno costosa, mantenendone il valore inalterato (pensate per esempio alla Continuous Integration)

Al solito ci sono pratiche a corollario che portano il codice ad essere rappresentazione della nostra conoscenza:

• Unit Tests: come specifica eseguibile del comportamento dei componenti del nostro software
• Acceptance Tests: come specifica eseguibile delle funzionalità esibite dal nostro software
• Shared Code: fare in modo che il nostro codice sia leggibile a tutti i componenti del team (lo considero un super set di “Write rereadable code” dell’articolo di Graham)
• Domain Driven Design: sviluppare un linguaggio di dominio (Ubiquitous Language) all’interno del codice. Questa pratica potrebbe essere portata all’estremo scrivendo un’interprete per un DSL (Graham come Lisper a questo proposito ne sa qualcosa)

Fare questo tipo di assunzione significa però assumere che esista il concetto di “correttezza a priori”, ovvero che esista la possibilità di determinare all’inizio del progetto il concetto di “correttezza”, il che presuppone che ci debba essere “predicibilità”, altrimenti sarebbe impossibile “pianificare correttamente”. Quindi alla fine per far funzionare tutta questa sequenza di implicazioni logiche, abbiamo la necessità di fare un’ulteriore assunzione, ovvero quella di avere dei “requisiti stabili” che ci diano quella “predicibilità” di cui abbiamo bisogno. Chiunque abbia un po’ di esperienza nel campo dello sviluppo del software sa quanto questo sia difficile, ma sapete una cosa? Mi voglio rovinare e vi regalo anche questa!

Ricapitolando: ho concesso (per ipotesi) alle metodologie tradizionali la certezza matematica di riuscire ad ottenere un prodotto conforme a dei requisiti che sono garantiti stabili durante il periodo di sviluppo… l’ho fatto perchè quest’ultimo articolo non vuole criticare il “come” le metodologie tradizionali intendono raggiungere gli obiettivi prefissi, ma vuole criticare gli obiettivi stessi, in particolare il concetto di correttezza.
Correttezza, per queste metodologie, è sinonimo di conformità alle specifiche, il che è perfetto nel mondo accademico, in un mondo artificiale, in un mondo dove il cliente è la specifica. Nel mondo reale le cose non stanno proprio così.

Cosa succederebbe se le specifiche fossero sbagliate? Saremmo portati a rispondere che otteremmo un prodotto finale sbagliato, il che sembrerebbe un po’ un assurdo viste le ipotesi di perfezione che abbiamo fatto; allora ci chiediamo: Cosa vuol dire che il prodotto finale è corretto? O meglio, cosa vuol dire che le specifiche sono corrette? Se come me vivete nel mondo reale: “la specifica di un software è corretta se l’utilizzo del prodotto che ne deriva raggiunge gli obiettivi del committente”.

A questo punto qualcuno potrebbe obiettare indicando come responsabilità degli analisti quella di scrivere specifiche corrette, al che domanderei: secondo voi è possibile scrivere specifiche corrette (secondo la definizione di correttezza che abbiamo dato)? Siamo sicuri che all’inizio del progetto esistano già tutte le informazioni necessarie per scrivere delle specifiche che una volta implementate consentiranno al nostro cliente di raggiungere i suoi obiettivi? Gli obiettivi del cliente rimarranno sempre quelli? Il modo in cui il nostro cliente può raggiungere i suoi obiettivi cambierà nel tempo? Ma sopratutto, abbiamo un modo per misurare se il nostro cliente ha raggiunto i suoi obiettivi?

Richiedere la “stabilità dei requisiti” significa richiedere non solo la “stabilità degli obiettivi” ma anche la “stabilità delle strategie per raggiungerli”, questo ci porta ad ambiente immobile, un abiente in cui l’acquisizione di conoscenza è scoraggiata, in cui il cliente viene isolato in quanto pericoloso “agente di cambiamento”, poco importa se quella conoscenza e quei cambiamenti sono indispensabili per permettere al cliente di raggiungere i suoi obiettivi! Questa è la mia più grande critica alle metodologie tradizionali, un difetto che non lascia scampo: il cercare di adattare il mondo reale a quello che funziona in laboratorio, ammesso e non concesso che funzioni, non dimenticatevi che è solo un’ipotesi :-).

Tutto questo mi ha portato ad amare le metodologie Agili perchè hanno il coraggio di confrontarsi continuamente con degli obiettivi reali, misurando iterazione dopo iterazione l’efficacia del prodotto realizzato fino a quel momento e sfruttando ogni dato rilevato come un’opportunità di miglioramento, ma questa è un’altra storia…

E’ estremamente semplice da disegnare e da tenere aggiornato, potrebbe sembrare una sciocchezza, ma non lo è: la complessità di disegno del grafico ci potrebbe portare ad utilizzare uno o più programmi specifici per il plotting, il che ci porterebbe a dover inserire manualmente i dati relativi, il che probabilmente ci porterebbe a considerare la possibilità di utilizzare uno o più software per memorizzare i nostri dati di processo in modo da poter automatizzare la generazione del grafico. Ne vale la pena? A mio parere questo è un’antipattern abbastanza comune che dovrebbe essere accuratamente evitato, per questo consiglio tutti i miei team di disegnare i loro grafici di processo a mano e di fare il traking dopo o durante lo stand-up meeting.

E’ estremamente intuitivo: sull’asse verticale sono rappresentati i punti storia, ovvero una misura della complessità (cumulativa) delle funzionalità che dovremmo implementare, sull’asse orizzontale sono rappresentati i giorni che abbiamo a disposizione per completare il nostro lavoro. L’ho definito “intuitivo” sia perchè è semplice identificare l’obiettivo (consumare i punti storia entro la data prevista), sia perchè basta un colpo d’occhio per capire se siamo in ritardo o se siamo in anticipo sulle nostre previsioni: se siamo sopra l’andamento ideale, siamo in ritardo, altrimenti siamo in anticipo

Un’altra caratteristica “Agile” di questo tipo di grafico è la possibilità di identificare molto rapidamente dei trend, possiamo avere feedback immediato su quello che è lo stato del progetto oggi e sullo stato in cui sarà il progetto domani se non modificheremo il nostro processo produttivo.

Ultimamente ad uno dei miei team è stato affidato un progetto che dovrà essere sviluppato contemporaneamente al loro progetto principale. Ovviamente c’è stato dato un budget di tempo (e quindi di costo) all’interno del quale abbiamo negoziato le funzionalità che dovranno essere implementate. Durante una retrospettiva ho consigliato di tener traccia dell’andamento di questo progetto (che ha uno scope ben definito a dispetto del loro progetto principale) attraverso un burn down chart. In quel momento mi sono accorto che per questo tipo di progetti il burn down chart nel suo formato originale può portare a dei problemi.

Il progetto in questione è limitato nello scope e nel tempo, ma deve anche essere limitato nell’effort che il team può spendere per la sua realizzazione. Avendo come unica metrica il burn down chart tradizionale correremmo il rischio di dedicare troppe energie (leggi persone/ore) per mantenere ideale l’avanzamento di questo progetto secondario a discapito del progetto principale

Quando ci si trova di fronte ad una situazione di questo genere una soluzione potrebbe essere quella di tener traccia, all’interno dello stesso grafico, anche dell’effort. Supponiamo che il nostro budget preveda 5 mesi uomo, calcolando 10 pomodori/giorno/uomo (un pomodoro è un’unita di tempo di 25 minuti), per 20 giorni/mese/uomo, fanno un totale di 1000 pomodori che possiamo spendere come team su questo progetto. In questo modo abbiamo un grafico che non solo ci comunica l’andamento del progetto, ma lo mette in relazione con l’effort spesa. Per esempio nell’immagine qui di fianco possiamo vedere come l’andamento del progetto sia praticamente perfetto, a discapito però di un’utilizzo eccessivo di risorse

La divisione in fasi del lavoro è stata inizialmente concepita per le produzioni di tipo manifatturiero: spezzando la lavorazione in fasi discrete, organizzandole in una catena continua e isolandole le une dalle altre, è possibile semplificare il lavoro di ottimizzazione e di controllo della qualità. Perchè non applicare gli stessi concetti anche alla produzione del software? Ogni fase elabora l’intero progetto ad un determinato livello d’astrazione, ogni fase viene lavorata da persone che sviluppano competenze specifiche riducendo la probabilità di difetti, infine al termine di ogni fase possiamo controllare la qualità dei semilavorati e verificare l’andamento del progetto. Sembrerebbe filare tutto liscio, ma…

La divisione in fasi in ambito manifatturiero funziona solo se i semilavorati che vengono prodotti possiedono determinate proprietà, per esempio devono essere facilmente trasportabili e non devono degradarsi, se così non fosse quello che perderemmo durante il trasporto potrebbe avere un costo maggiore del valore del semilavorato stesso. A questo punto ci chiediamo: i deliverable (semilavorati) relativi alle fasi di produzione del software, di che natura sono? Sono artefatti di rappresentazione della conoscenza che abbiamo del progetto ad un determinato livello d’astrazione, ovvero qualcosa di molto degradabile

• Mai giocato a passaparola? In questo caso le cose sono ancora peggiori: quello che vuole il cliente è diverso da ciò che l’analista pensa che il cliente voglia, ciò che l’analista ha capito è diverso da ciò che l’analista scriverà nel documento d’analisi, che sarà diverso da ciò che capirà l’architetto leggendo il documento d’analisi, ecc… Più le fasi sono isolate, più le fasi sono numerose, più la pressione e l’urgenza aumentano, più questo effetto peggiora, esattamente come nel gioco, e nel gioco devi solo ripetere una frase, non interpretarne il significato
• Nella produzione manifatturiera la qualità del semilavorato è valutabile al di fuori di ogni contesto, la stessa cosa non può essere fatta anche con gli artefatti prodotti durante la realizzazione di un software, in quanto l’artefatto non è fine a se stesso, ma è la rappresentazione di qualcos’altro, la sua qualità può essere giudicata solo misurando l’accuratezza della rappresentazione stessa. Tutto questo per dire che il degrado nel tempo può essere causato anche da un cambiamento in ciò che si vuole rappresentare (alzi la mano chi non ha mai avuto un cliente che abbia cambiato idea durante un progetto)

Un’altra cosa che dobbiamo considerare è la probabilità d’errore: è vero che attraverso la specializzazione di ogni fase è possibile ridurre la probabilità d’errore al suo interno, ma è anche vero che la probabilità d’errore totale non è la somma delle probabilità nelle singole fasi, ma il loro prodotto, quindi non è detto che la riduzione della probabilità d’errore locale, dovuta all’introduzione di una fase specializzata, riduca la probabilità d’errore globale, che alla fine è l’unica cosa che ci dovrebbe interessare

Infine notiamo che non è possibile, come abbiamo accennato prima, valutare la qualità del singolo artefatto se non valutandone l’accuratezza, e questa valutazione non è possibile farla secondo parametri oggettivi (come nel caso della manifattureria), l’unico modo possibile è coinvolgere gli stessi meccanismi che portano alla realizzazione dell’artefatto e che quindi sono passibili degli stessi errori. Questo ci porta a concludere che non è possibile valutare l’andamento del progetto se non alla fine dello stesso, dove il cliente può provare ciò che è stato realizzato e verificare se effettivamente risolve le sue necessità

Tutti questi problemi sorgono per una ragione molto semplice: la produzione del software non c’entra niente con la manifattura. E’ la stessa differenza che c’è fra il lavoro di un cuoco che deve inventare una nuova ricetta, e una cucina che deve seguire una ricetta. Da una parte l’obiettivo è quello di soddisfare il palato del cliente, per farlo il cuoco farà molti esperimenti, proverà combinazioni di alimenti diversi, tempi di cottura diversi, ad ogni tentativo raccoglierà del feedback che guiderà il tentativo successivo; nel caso del cuoco l’errore è necessario per l’acquisizione di feedback, necessario per l’acquisizione di conoscenza, necessaria per raggiungere lo scopo. Dall’altra l’obiettivo è quello di riprodurre fedelmente la ricetta nel più breve tempo possibile, per farlo la cucina può dividere la realizzazione della ricetta in fasi, può ottimizzare ogni singola fase tenendo come parametro di confronto il piatto originale, nel caso della cucina lo scopo è quello di evitare gli errori

Se non siete ancora convinti, non perdetevi l’ultima parte, non ne rimmarete delusi :-)

La strategia di base è quella di accompagnare il proprio interlocutore in una sequenza di implicazioni logiche che ci porteranno a demolire tutte le assunzioni che stanno alla base delle metodologie ingegneristiche, una delle quali (se non la principale) è l’analogia fra l’attività di produzione del software e le fasi di realizzazione di un artefatto di produzione ingegneristica/manifatturiera

Lo scopo iniziale era quello di “ereditare” dalle scienze ingegneristiche quella formalità che avrebbe potuto salvare la produzione del software, devo ammettere che all’epoca questo tentativo aveva un suo perchè, quello che non ammetto è che nei 30 anni seguenti nessuno l’abbia più messo in discussione

Lo mettiamo in discussione noi adesso utilizzando l’onnipresente metafora della costruzione del ponte. Prendiamo ad esempio la fase di Progettazione, a questa fase viene dato molto peso e rigore in quanto un errore causerebbe un danno economico rilevante nella fase successiva di Costruzione, ovvero la fase più lunga e onerosa. Parrebbe logico fare lo stesso discorso anche per quanto riguarda il software, si sa che un errore di Design fatto all’inizio del progetto può causare in seguito dei seri problemi, ma…

Analizziamo meglio la fase di Progettazione, abbiamo detto che è una fase molto rigorosa, talmente rigorosa da produrre un modello che rappresenta in maniera corretta e completa ciò che si andrà a costruire. Nel mondo dell’edilizia tale modello è indispensabile, in quanto la fase di Costruzione è una semplice traduzione del modello nell’artefatto che esso rappresenta, senza aggiunta ne perdita di informazioni

Succede la stessa cosa anche nel software? Se la fase di Progettazione di un ponte si conclude con la realizzazione di un modello matematico/fisico dello stesso, cosa viene realizzato alla fine della fase di Design? Una serie di diagrammi UML? Riuscite a pensare ad un modello del software che abbia le stesse caratteristiche di quello del ponte? Esiste un modo per rappresentarlo in maniera corretta e completa? Un modello da poter tradurre senza perdita o aggiunta di informazioni?

La risposta è di una semplicità imbarazzante, il codice sorgente. Proseguiamo con il ragionamento, se il modello del nostro prodotto è il suo codice sorgente, qual’è la fase successiva? Abbiamo detto che la Costruzione è la traduzione del modello nell’artefatto, quindi la risposta è altrettanto semplice, la compilazione. Da qui viene la frase che dico sempre: “la manodopera non esiste nel mondo dell’informatica, gli unici operai in questo settore sono i computer”

Notate come la fase più dispendiosa da un lato (Costruzione) venga messa in relazione con la fase meno costosa dall’altro (Compilazione), questo ci porta alla prima conclusione: le metodologie ingegneristiche utilizzano un processo che è stato pensato per gestire delle limitazioni fisiche (la costruzione costosa e irreversibile dell’artefatto) che il codice non ha! Questo per esempio ci consente di adottare delle strategie iterative/incrementali che sarebbero impossibili in ambito ingegneristico

Se non vi ho convinto, non preoccupatevi, questo è solo il riscaldamento, non perdetervi il resto :-)

P.S. Se qualcuno sta pensando al fatto che esistono modelli alternativi di rappresentazione del software, preciso subito che il discorso non cambia di una virgola: se il modello è semanticamente ben specificato è possibile scrivere un compilatore per esso, altrimenti, se il modello è ambiguo, per definizione non è corretto e completo (cvd)

Se siete di Milano, se siete incuriositi dalle metodologie Agili, se volete scambiare esperienze, capire come poter applicare una di queste metodologie o una delle pratiche, iscrivetevi alla nostra mailing list e venite a trovarci ad uno dei nostri meeting che si svolgono a Milano ogni due settimane

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è