Criticità

Quando non utilizzare XP

Back non esclude mai la possibilità di utilizzare l’XP: lui sostiene che è possibile provare ad utilizzare questo approccio sempre (anche se in realtà non è sempre possibile “provare”), a patto che vengano rispettati i 12 punti elencati sopra.

Da questo possiamo concludere che Agile non si può usare quando:

• l’ambiente non permette l’applicazione dei 12 punti, come per esempio quando i team sono dislocati in luoghi diversi;
• ci sono barriere managieriali, come team troppo numerosi;
• ci sono barriere tecnologiche, come quando per esempio non è possibile utilizzare una macchina specifica condivisa da tutte le coppie per i test, ostacolando l’integrazione continua.
• ci sono troppi stakeholders diversi e in contrasto tra loro;
• situazioni in cui la consegna incrementale non ha senso, come per una centrale nucleare (vero Dyatlov?).

Critiche da Meyer

Di seguito sono elencate alcune critiche all’eXtreme Programming fatte da Meyer (già pluricitato in questo documento).

• Sottovalutazione dell’up-front, ovvero la progettazione iniziale prima di partire. Per Meyer, a parte in casi eccezionali (sviluppatori o manager particolarmente bravi) la progettazione non può essere fatta in modo totalmente incrementale. Nell’esperienza dei tesisti e colleghi di dottorando del prof. Bellettini questo problema non è così presente, ma potrebbe trattarsi di survivorship bias.
• Sopravalutazione delle user stories: secondo Meyer sono troppo specifiche per sostituire i requisiti.
• Mancata evidenziazione delle dipendenze tra user stories. Le user stories dovrebbero essere indipendenti tra loro, ma questo non è quasi mai possibile; nel design classico si utilizzano i diagrammi di Gantt per chiarire tutte le dipendenze tra i diversi punti del sistema da realizzare.
• Il TTD può portare ad una visione troppo ristretta.
• Cross functional team: se i team sono troppo disomogenei, ovvero ci sono tante singole figure specializzate in un campo e queste devono collaborare in coppia, ci possono essere dei problemi.

I punti di cui sopra cercano di evidenziare la mancanza di approfondimento e chiarezza dell’XP su alcuni aspetti dell’approccio ad un lavoro fornito da un cliente.

È consigliata la lettura del libro di Meyer.

Mesi uomo

È diffuso tra i manager pensare che la stima in tempo in mesi uomo sia graficata come un ramo di un iperbole, ovvero che il tempo diminuisca simil-esponenzialmente all’aumentare dei mesi uomo; tale stima non considera i tempi di overhead, ovvero il tempo impiegato per la comunicazione e tutto ciò che non è l’implementazione. I mesi uomo non quindi sono una metrica valida, ma sono utili solo a posteriori per valutare se un approccio ad un problema si è dimostrato valido.

Nella realtà, all’aumentare delle persone aumenta il bisogno di comunicare, quindi non sempre porta ad un aumento lineare della produttività.

Quando il lavoro è strettamente sequenziale e non parallelizzabile (come la gravidanza) anche all’aumentare delle persone il tempo non cambia, anzi si rischia di rallentarlo.

In caso di ritardi nell’avanzamento del progetto invece che aggiungere personale rischiando di peggiorare la situazione posso:

• Discutere la dead-line con il cliente, se possibile.
• Diminuire la portata del progetto.
• Diminuire la qualità del progetto, diminuendo il testing (fortemente sconsigliato ma accade spesso).

Nel mondo dello sviluppatore software spesso c’è un numero ideale di persone per un progetto; dopodiché, persone in più causano solo confusione e rallentano i tempi a causa della comunicazione. Il numero può anche essere grande, dipende dall’entità del progetto (esempio: space shuttle).

In generale, le metodologie agili iniziano a non funzionare più se il team è più grande di 8-10 persone. Quando il progetto non funziona più con un tale numero di persone, è necessario esplorare altre pratiche.