Sfuggente e di qualità

Ron Jeffries, nella mailing list extremeprogramming@yahoogroups.com, in queste ultime ore a chi scriveva

[Unified Process] has [a flow with all the steps] formally described. I know [extreme programming] have different philosophies but they are both methodologies and should them both have a formal process.

rispondeva così

Sorry. Agile processes are not formal.

Questa risposta sintetizza (perché chiaramente si tratta di sintesi affatto esaustiva) molti aspetti difficili dell’approccio al mondo agile. Tra i primi che mi vengono in mente ora, mentre devo scappare per tornare al mio lavoro, trovo:

  1. I metodi agili non possono essere spiegati top-down. Una spiegazione frontale può aiutare, può introdurre, ma poi basta: bisogna fare e capire. La mera inesistenza di una impalcatura formale scardina ogni tentativo di verbalizzarne una.
  2. I processi agili sono facilmente fraintendibili da chi non è disposto ad approfondire il tema perché è più facile fare di concetti dai contorni sfumati quello che si vuole per giustificare le proprie esigenze dirette o addirittura le proprie debolezze. Penso a quanti ritengono che l’agile si risolva nella formula iteratività+incrementalità facendosi sfuggire che anche Unified Process contempla un approccio iterativo e incrementale.
  3. I metodi agili sono adatti a fronteggiare la realtà perché ne riflettono la complessa vaghezza. Non esiste squadra di calcio che possa vincere una partita applicando schemi rigidi. Non esiste medico serio che si aspetti che un paziente sia un sistema che restituisce output lineari . Non esiste ecologo che pensi che si possa agire per step contemporanemanete deterministici e lineari per rimettere a posto un ecosistema. Esistono invece molti professionisti IT che credono che un sistema complesso – come un progetto – possa essere controllato da entità (più) semplici – una persona o addirittura un tool.

Quello che credo sia il nostro dovere tutti i giorni è crescere aumentando la nostra consapevolezza della complessità del contesto dei progetti IT e saper galleggiare su quelle onde ridefinendo ogni giorno il nostro equilibrio, senza affetto per quello trovato oggi, senza nostalgia per quello abbandonato ieri.

Trovi sia difficile? Lo è!

June 11 2010 02:50 pm | Base

3 Responses to “Sfuggente e di qualità”

  1. Giorgio Sironi on 13 Jun 2010 at 13:40 #

    Abbiamo un corso al Politecnico di Milano il cui oggetto praticamente è un po’ di teoria più Rational Unified Process, UML Web Application Extension eccetera. Inutile dire che seguire un corso del genere avendo già un background agile è semplicemente *doloroso*, in particolare in punti come i 5 diagrammi da aggiornare per aggiungere un file JSP.

  2. Agile è… non dire mai “ci pensi tu” | Sviluppo Agile on 21 Dec 2010 at 12:02 #

    [...] A questi diluitori di significato, ricordo che da queste parti si predilige la collaborazione col cliente piuttosto che stare lì ad aspettare che i contratti vengano impugnati inesorabilmente da una delle parti contro l’altra e che invece sarebbe bene giocare allo stesso tavolo dall’inizio alla fine del progetto senza stare lì a sostituire la voglia di lavorare con deleghe e regolette, perché la prima serve comunque, le seconde non funzionano e le terze nessuno le ha ancora trovate. [...]

  3. odino on 05 Jun 2013 at 21:56 #

    ogni tanto ho bisogno di rileggere questo post :)

Trackback URI | Comments RSS

Leave a Reply