Metodologia “Agile” per il project manager

Metodo Agile

Questo articolo nasce dopo una lunga “navigazione” tra moltissime pagine web che ho letto al fine di documentarmi meglio sulle metodologie che istintivamente ho sempre messo in essere quando ho avuto modo di gestire uno o più progetti.

Nel febbraio 2001, in una stazione scistica nel Wasatch Mountains dello Utah, diciassette persone si sono incontrate per parlare, sciare, rilassarsi, e cercare di trovare qualcosa in comune. Ciò che è emerso è stato il Manifesto Agile Software Development. I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e altri si trovavano di fronte alla necessità di un’alternativa alla documentazione che guida il processo, e alle pesanti metodologie di sviluppo software.

Quanto è emerso da questo incontro è stata la stesura simbolica di un Manifesto per il Software Agile Development firmato da tutti i partecipanti che si autonominarono “L’Alleanza Agile“. Questo gruppo di pensatori indipendenti sullo sviluppo software, a volte concorrenti tra loro, hanno convenuto sul Manifesto for Agile Software Development visualizzato sul  sito web  agilemanifesto.org/.

Propongo di seguito la traduzione fatta da Jacopo Romei aul suo sito web.

Manifesto per lo Sviluppo Agile di Software

Stiamo ricercando modi migliori di sviluppare software facendolo e aiutando gli altri a farlo.

Grazie a questa attività siamo arrivati a considerare importanti:

  • Gli individui e le interazioni più dei processi e degli strumenti
  • Il software funzionante più che la documentazione esaustiva
  • La collaborazione col cliente più che la negoziazione del contratto
  • Rispondere al cambiamento più che seguire i piani

Ovvero, fermo restando il valore delle entità a destra, consideriamo più importanti le entità a sinistra.

I Dodici Principi del Software Agile
Vedi i firmatari (via agilemanifesto.org)

Riguardo gli autori (via agilemanifesto.org)
Riguardo il Manifesto (via agilemanifesto.org)
Riguardo questa traduzione

 

I 12 principi sottostanti al Manifesto Agile

1.  La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

2.  Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo.

3.  I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.

4.  Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

5.  Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.

6.  Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.

7.  Una conversazione face to face (o meglio skype to skype) è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.

8.  Il software funzionante è il principale metro di misura di progresso. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

9.  La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.

10.  La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.

11.  Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

12.  A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

L’utilizzo di questo approccio rispetto ai processi più tradizionali di sviluppo (a cascata o iterativi) risulta più idoneo per progetti di dimensioni medio-piccole, con gruppi di lavoro non superiori alle 8-10 persone.Gruppi più grandi rischiano infatti di non riuscire ad applicare con efficacia le discipline collaborative previste dal modello Agile.

Processo Agile

Agile non è un processo specifico, ma piuttosto un termine generico per un gruppo di metodologie e di approcci che hanno una base simile. Questi approcci, tra cui Extreme Programming, Dynamic System Development Method, Scrum, Crystal e Lean tra gli altri, si basano sulla realizzazione di alta qualità, lavorando software presto e spesso, e la creazione di soddisfazione del cliente.

Sebbene ciascuno dei metodi che formano la famiglia dei processi agili ha un obiettivo simile, si raggiunge questo obiettivo attraverso pratiche diverse.

In questo articolo ho preso le migliori pratiche che abbiamo visto e fatto il lavoro di elencare tutti i processi e metterli insieme.

Immaginiamo una  figura a cerchi (come l’immagine dell’articolo)  come una rappresentazione di base di queste  pratiche agili che abbiamo distillato;
il cerchio più al centro  indica le pratiche che un paio di programmatori usano in quotidiano. Il successivo cerchio esterno  mostra le pratiche che vengono utilizzati da un team di sviluppatori. Il cerchio più esterno ci dà pratiche utilizzate da tutte le persone coinvolte in un progetto come “I clienti, sviluppatori, tester, analisti aziendali, ecc

Ciascuna delle pratiche nei cerchi si riferisce direttamente ai valori fondamentali della filosofia Agile mostrati ai quattro angoli: Comunicazione, Feedback, Coraggio e Semplicità. Cioè, ogni pratica ci dà un modo concreto per seguire i valori Agile e renderli parte del processo.

Elenchiamo le metodologie del modello “Agile”.

Agile Unified Process

Si tratta di una versione semplificata dell’IBM Rational Unified Process (RUP). Descrive un approccio semplice per lo sviluppo di software applicativo utilizzando tecniche agili e concetti propri del RUP.

Dynamic System Development Process

Si tratta di un metodo basato sul Rapid Application Development, un approccio iterativo e incrementale che enfatizza il continuo coinvolgimento di utenti e cliente.

Studiato per progetti di sviluppo di sistemi informativi caratterizzati da schedulazioni e budget ridotti e indirizza le più comuni cause di fallimento di un progetto, come il superamento del budget, il mancato rispetto delle date di consegna, il mancato coinvolgimento degli utenti finali e del top management.

Il suo obiettivo è di consegnare progetti nei tempi e costi previsti, adattando le modifiche ai requisiti in corso d’opera.

XTreme Programming

Extreme Programming (XP) è una disciplina che organizza i gruppi di lavoro verso la produzione di software di alta qualità in modo più produttivo che con metodi tradizionali. XP cerca di ridurre i costi delle modifiche ai requisiti decomponendo le attività di sviluppo in molti cicli brevi piuttosto che in un unico lungo ciclo.

Feature Driven Development

Un processo di sviluppo software iterativo ed incrementale che miscela una serie di buone pratiche in un insieme coeso. Queste pratiche sono orientate allo sviluppo di funzionalità nel rispetto delle esigenze del cliente, suddividendo l’attività di sviluppo in singole componenti (Feature) che procedono parallelamente.

Scrum

Un framework iterativo e incrementale per la gestione di progetti. Si basa su tre semplici punti: Sprint, Backlog e Scrum Meeting.
Molto simile ad Extreme Programming prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine dei quali consegnare una versione al cliente, indica come definire i dettagli del lavoro da fare nell’immediato futuro (Backlog) per averne una definizione estesa, organizza riunioni giornaliere del team di sviluppo (Scrum Meeting) per verificare cosa si è fatto e cosa si farà.

 

 Le sette pratiche centrali di lavoro Agile

Il lavoro Agile  si compone di 7 pratiche di base. Queste pratiche costituiscono un solido punto di partenza per qualsiasi persona, gruppo o comunità che voglia seguire la via Agile.

Self-Organizing Team

Qualsiasi gruppo di persone che desiderano essere un Team Agile ha bisogno di prendere l’iniziativa e di decidere autonomamente su come sta andando il lavoro (processo) e su come ha intenzione di fare il lavoro (prodotto). Il termine “squadra” si applica in generale a qualsiasi gruppo formato di persone che stanno lavorando insieme verso un obiettivo comune.

Il risultato più importante del team di sviluppo è lo stesso team, e non le specifiche competenze e capacità che gli individui imparano.

Se la squadra è parte di un’organizzazione più ampia, l’organizzazione deve dare alla squadra lo spazio, l’autorità e la sicurezza per riuscire ad essere auto-organizzati. Riguardo alla leadership, l’organizzazione è responsabile per la determinazione del “perché?”, Alcuni vincoli sul “come?”, Lasciando poi al team di rispondere alla necessità nel miglior modo possibile.

Questa pratica è Conosciuta anche come: Team totale (Extreme Programming), Cross-Functional Team (gestione aziendale).

Deliver Frequently

Agile utilizza brevi periodi di tempo per monitorare il processo di erogazione di valore. Ognuna di queste iterazioni o timeboxes è strutturata in modo tale, in realtà, che la squadra o il gruppo quando finisce un pezzo di lavoro lo consegna ai soggetti interessati.
Prima che i prodotti  possano essere consegnati, il valore maggiore puo’ essere ottenuto da questi prodotti. Questo valore aggiunto è derivato da opportunità quali le vendite precedenti, vantaggio competitivo, feedback , e riduzione dei rischi.

C’è un compromesso: più breve è il tempo di consegna, minore è valore che sarà dato a quel pezzo.

Conosciuto anche come: Sprint (Scrum), iterazione (Extreme Programming), timeboxing (generico), valore temporale del denaro (contabilità).

Plan to Learn

Ogni tipo di lavoro è disciplinato da un orizzonte di prevedibilità. Qualsiasi piano che si estende al di là di questo orizzonte di prevedibilità è destinato a fallire. Agile  utilizza un ciclo di apprendimento legato alla pianificazione dei lavori e accoglie questo come inevitabile.

Innanzitutto, è richiesto un obiettivo. Questo obiettivo può essere a lungo termine. Team che utilizzano lavoro Agile creano una coda di task di lavoro per raggiungere questo obiettivo. Per ogni iterazione, alcuni di questi elementi sono selezionati, finiti e quindi la coda viene regolata. I cambiamenti nella coda di lavoro si basano su fattori esterni, e che la squadra conosce.

Uno dei metodi più efficaci per la squadra per conoscere lo stato del suo lavoro è la retrospettiva. Dopo ogni consegna dei risultati, il team tiene una retrospettiva per esaminare come si può migliorare.

Conosciuto anche come: Controllare e Adattare (Scrum), Kaizen (Lean), Adaptive Planning (generico).

Communicate Powerfully

Una squadra ha bisogno di disporre di mezzi efficaci per comunicare, sia tra i membri del team e anche per le parti interessate. Per “Comunicare Potentemente” , una squadra ha bisogno di preferire la comunicazione di persona attraverso la comunicazione distribuita. Sincrono sulla comunicazione asincrona. Elevata larghezza di banda e più bassa larghezza di banda di comunicazione. Comunicazione multi-mode  su singola modalità di comunicazione.

Il risultato di non riuscire a comunicare con forza include il tempo sprecato per l’attesa, le incomprensioni che portano a difetti o re-lavoro, abbassamento della fiducia, difficoltà nel team-building, e in definitiva un fallimento.

Il mezzo più efficace per comunicare con forza, è quello di mettere tutta la squadra insieme in una stanza dove può fare il loro lavoro, ogni giorno per la maggior parte del tempo di lavoro.

Alcuni tipi di lavoro non si prestano a questo approccio (ad esempio la creazione di un video documentario), ma ogni sforzo dovrebbe essere fatto per migliorare la comunicazione.

Conosciuto anche come: Visibilità (Scrum), Team e Team intero Camera (Extreme Programming), War Room (gestione aziendale).

Test Everything

Testando tutto, guidando tutto il lavoro di un team, creando casi di test per verificare il lavoro, una squadra può raggiungere livelli qualitativi estremamente elevati. Questa capacità di prevenire i difetti è così importante che solo una decisione di livello esecutivo deve essere considerata sufficiente per consentire i difetti in un processo di lavoro. La qualità non è negoziabile.

Nel lavoro Agile, la rimozione di un difetto è l’unico tipo di lavoro che ha priorità su tutte le nuove caratteristiche / funzionalità. Se il risultato finale desiderato è quello di massimizzare il valore, rimuovendo difetti si raggiunge più facilmente un tal fine.

Ogni squadra ha un dovere etico di scoprire nuovi modi per testare efficacemente il proprio lavoro. Questo può avvenire attraverso l’uso di strumenti, meccanismi di feedback, automazione, e il buona vecchia capacità di problem solving.

Conosciuto anche come: canarino nella miniera di carbone (Scrum), Test-Driven Development (Extreme Programming), difetti per Opportunità (Six-Sigma).

Misura del valore (Measure Value)

Dal momento che la realtà è percepita, è importante per un team Agile, e per l’organizzazione, avere un metodo chiaro per descrivere e percepire ciò che è importante per l’organizzazione. Misurare il valore è un metodo critico per descrivere e percepire ciò che è importante.

Una metrica singola può essere usata per guidare tutte la misure e la definizione degli obiettivi e le ricompense di un’organizzazione. Tutte le altre misure sono secondarie e devono essere trattate come tali: limitate e temporanee.

Ci sono molte cose più facilmente misurabili rispetto al valore. Spesso è facile misurare i costi, e le ore lavorate, oppure i difetti riscontrati, o la stima ore effettive … ecc, tuttavia, tutte queste altre misure implicitamente o esplicitamente non fanno altro che portare ad un comportamento sub-ottimale.

Conosciuto anche come: Risultati di misura (Scrum), ROI (gestione aziendale), Driver economico (Good to Great), Running Caratteristiche testate (Extreme Programming).

Clear the Path (Cancellare il Percorso)

Tutti coloro i quali, in un’organizzazione, utilizzano lavoro Agile si assumono la responsabilità per la pulizia del percorso, rimuovendo (cancellando!) gli ostacoli che impediscono il lavoro venga svolto in modo efficace. Cancellare il percorso non significa solo trovare espedienti e soluzioni rapide ai problemi, ma piuttosto avere il tempo di guardare un ostacolo e fare il meglio possibile per rimuovelo in modo permanente.

Nel metodo di lavoro Agile, il Facilitatore del processo è la persona che è responsabile per tracciare gli ostacoli e garantire che il “percorso venga cancellato”. Per fare questo, il facilitatore di processo mantiene un record sugli ostacoli.

La cancellazione del percorso è  a volte un doloroso lavoro che ci espone a cose che preferiremmo non affrontare. Di conseguenza, è fondamentale che le persone costruiscano la loro capacità di veridicità e lavorino per accrescere la fiducia tra di loro. Costruire una capacità di veridicità non è qualcosa che può essere fatto usando un processo esplicito.

Conosciuto anche come: eliminazione degli ostacoli (Scrum), fermare la linea (Lean).

 

E l’Acqua Calda?

Tutte le pratiche e le metodologie Agile sono destinate ad aumentare la produttività dei team che le adottano. In un certo senso si può pensare ad essa come “team + pratica  = migliore”, ciò che andreamo ad esplorare è la natura di “+”.

Se si vuole fare un piatto di pasta, mettiamo l’acqua a bollire in pentola e, la nostra acqua, inizialmente sarà fredda. Facciamo un intervento per correggere questo stato indesiderabile: accendiamo il fuoco. Mettiamo la pasta a mollo? Voglio dire, adesso? A meno che non vogliate mangiare della pasta scotta, che farà rabbrividire un italiano, la risposta è no: l’acqua deve ancora bollire. C’è un ritardo tra il momento in cui accendiamo il fuoco sotto la pentola e la bollitura dell’acqua, più o meno di 15 minuti. Ciò è significativo: significa che abbiamo il tempo andare a sfogliare un magazine su iPad. Ciò significa anche che, se l’acqua (gia salata?) non è ancora in ebollizione dopo mezz’ora, c’è qualcosa di sbagliato. Forse arriva poco gas, o non abbiamo girato bene la manopola. Qualunque cosa accada, intuitivamente sappiamo come utilizzare questo ritardo per gestire “pentola + manopola gas  in esecuzione = ….”.

La stessa idea è altrettanto – se non più – importante all’interno di un team di sviluppo software. Senza un senso del ritardo tra lo stato originale e lo stato desiderato dato un certo intervento, è facile sotto o sovrastimare.

Durante il riscaldamento della vostra acqua per la pasta, non c’è bisogno di aspettare fino alla fine per vedere se è in bollitura: controllando di tanto in tanto, si può vedere se i tempi vanno come previsto. Si può essere in grado di vedere se l’acqua ha iniziato il processo di ebollizione ed è quasi tutta evaporata, oppure si riscalda lentamente e ti rendi conto che la manopola del gas è al minimo. Questo feedback aggiuntivo consente di gestire in modo più efficace. Ma se l’acqua bolle dopo 15 minuti in condizioni ideali, e siete a soli 10 minuti, non aspettatevi che sia eveporata.

Conclusioni

Ancora una volta, non spegnere il gas e  esclamare: “L’acqua non bolle! Non abbiamo bisogno di mangiare dopo tutto! “.

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*