Dopo aver visto nell’articolo precedente i principi basilari dei contratti agili, con la presentazione di alcuni casi reali e con l’analisi delle motivazioni per questo nuovo tipo di contratti, passiamo con questo secondo articolo a guardare quali siano gli elementi fondamentali che non possono mancare nei contratti agili.

Introduzione

Riprendiamo il discorso sui contratti Lean Agili, iniziato nella prima parte della serie, nel quale avevamo esplorato le basi concettuali su cui essi si fondano. In questa seconda parte  vorrei esporre quelli che sono a mio avviso i principali, e oserei dire insostituibili, elementi da tenere presente nella stesura dei contratti agili.

Partiamo da una considerazione: quanta più fiducia esiste tra cliente e fornitore, tanto meno sarà necessario inserire delle clausole in un contratto. Assolutamente vero! Però, ci sono alcuni punti che devono essere necessariamente presenti in ogni contratto. Solo da un’approfondita discussione e condivisione di tali tematiche da parte di entrambi gli attori coinvolti (cliente e fornitore) può derivare il successo di una qualunque iniziativa, sia essa un progetto o un programma. Le specifiche clausole contrattuali verranno poi inserite in base a quanto presente in tali tematiche, definendone meglio e più in dettaglio l’applicabilità pratica.

Si torna sempre… all’Agile Manifesto

Mi pare opportuno ricordare due valori del Manifesto Agile, che ci guideranno nella definizione di contratti:

• Rispondere al cambiamento più che seguire un piano
• La collaborazione col cliente più che la negoziazione dei contratti

Un aspetto che va considerato è il seguente: avvocati e legali, giustamente, pretendono di avere voce in capitolo nel momento in cui si parla di contrattualistica. La loro voce deve essere la principale e può avvalersi delle argomentazioni portate da entrambe le parti, ma nella prassi non deve essere guidata da queste più di tanto. Il predominio di anni, se non decenni, delle metodologie tradizionali e waterfall, ha portato questi professionisti ad avere una mentalità deterministica e orientata alla protezione degli interessi della parte di cui sono consulenti.

Ora, il nostro obiettivo è quello di utilizzare una serie di contratti differenti da quelli standard e più idonei alle metodologie Lean Agile. Per riuscire pienamente nell’intento, dobbiamo necessariamente portare a bordo tali importanti attori (vale a dire, dobbiamo collaborare con legali e avvocati), mediante una logica che anche in questo caso deve essere basata sulla cooperazione, sul modello empirico e sulla logica “win-win” di cui abbiamo parlato nella prima parte.

Gli elementi di un contratto

Ciò detto, i più importanti punti che dovrebbero essere inseriti in tutti i contratti Lean Agile sono i seguenti e corrispondono a quelli presenti anche nei contratti tradizionali:

1. ciclo di rilascio
2. ambito del progetto
3. gestione del cambiamento
4. fine progetto
5. approvazione
6. limiti di responsabilità
7. garanzia
8. documentazione
9. tempistiche di pagamento
10. tipologie di pagamento

Vedremo nel dettaglio ciascuno di tali aspetti e cosa comporti l’utilizzo delle logiche e dei fondamenti metodologici discussi nella prima parte dell’articolo. Quindi, pur presentando nei contratti gli stessi elementi, nel caso delle metodologie agili verranno enfatizzati la collaborazione, l’apprendimento e l’evoluzione.

Ciclo di rilascio

Il primo punto da tenere in considerazione nella stesura dei contratti riguarda il ciclo di rilascio che nelle metodologie agili è diverso rispetto a quello dei metodi tradizionali. Ricordiamo che le metodologie agili sono iterative e incrementali, quindi il ciclo di rilascio sarà caratterizzato proprio da iterazioni (o sprint nel caso di Scrum). Al fine di avere un atteggiamento “agnostico” rispetto alla specifica metodologia Agile considerata, non parlerò specificamente di sprint, ma utilizzerò prevalentemente il termine iterazione.

Al termine di ogni iterazione time-boxed, può essere consegnato incrementalmente un sistema deployable con funzionalità utilizzabili. Alternativamente se il cliente preferisce non avere una nuova versione del sistema al termine di ogni iterazione, l’incremento di sistema rilasciato in produzione corrisponderà all’insieme delle funzionalità realizzate in N iterazioni. In ogni caso il team (o i team nel caso di prodotti di vaste dimensioni) del fornitore realizzerà un incremento del sistema a ogni iterazione che sia potenzialmente consegnabile e che conterrà unicamente running tested feature (funzionalità testate e utilizzabili).

Questa peculiare caratteristica delle metodologie agili, fa sì che il cliente possa far utilizzare il prodotto ai propri utenti (o metterlo sul mercato) con una cadenza regolare che va da una settima a trenta giorni, nel caso di singola iterazione, oppure pari a multipli di queste unità nel caso di più iterazioni in una release. In ogni caso quello che ci interessa è la possibilità di convalidare l’effettivo valore del prodotto in modo costante e con brevi cicli di feedback. Vedremo che questa caratteristica sarà determinante, nei contratti, per molti dei punti che saranno descritti in seguito.

L’importanza delle iterazioni

A titolo d’esempio vediamo figura 1 con la struttura, in termini di attività/eventi, di una singola iterazione e figura 2 con una release composta da più iterazioni.

 

 

Figura 1 – Attitivà ed eventi di una singola iterazione.

 

Come sappiamo, in scrum l’iterazione è detta Sprint, inizia con uno Sprint Planning e si chiude con una Retrospective, preceduta da una Sprint Review; quest’ultima consente agli stakeholder (compresi clienti e/o utenti finali) di poter dare feedback sul prodotto in maniera incrementale a ogni iterazione. Inoltre, se il cliente è d’accordo, si può rilasciare il prodotto in produzione per ottenerne la valutazione da parte degli utenti e ricevere feedback dal mercato.

 

 

Figura 2 – Una release composta da più iterazioni. In questa figura, relativa a un Release Plan, viene mostrato un numero di sprint ipotizzati per la Release 0.5 pari a quattro.

 

Nel caso di una release che comprende più Sprint il feedback giungerà al termine di N iterazioni, in ogni caso sempre prima di quanto avverrebbe nel caso dell’utilizzo di una metodologia tradizionale (waterfall). Gli aspetti contrattuali dovranno tener conto di queste possibilità, in modo da creare e rilasciare prodotti dal più alto valore possibile in modo efficace e creativo.

Gli aspetti nuovi per i legali, che dovranno essere compresi allo scopo di stilare nuove forme contrattuali, sono:

• Doneness and deployability: il rilascio a ogni iterazione è done (completo), sviluppato, testato, e quindi consegnabile.
• Durata: minore di quella di un contratto tradizionale, generalmente due settimane.
• Time-boxing: tempo fisso e ambito (quantità di funzionalità) variabile.

Per concludere questo topic, sul quale si potrebbe dissertare a lungo, vorrei menzionare che le ultime tendenze in Lean e Agile sono quelle di giungere a un Continuous Delivery, ovvero ad un rilascio praticamente continuo, anche più volte al giorno (vedere DevOps, …).

Ambito del progetto

Il secondo aspetto da tener presente nella stesura dei contratti agili è relativo all’ambito di progetto, ossia alla quantità di funzionalità che dovranno essere incluse in un determinato prodotto. Utilizzando un Product Backlog (manufatto utilizzato anche in altre metodologie oltre a Scrum), tali funzionalità vengono ordinate per priorità, in base a valore, rischio ed effort necessari a realizzarle e, cosa fondamentale, non sono definite in modo rigido all’inizio del progetto, ma evolvono in base alle  necessità del committente.

In merito a ciò, una questione molto importante è quella degli obiettivi di progetto e della cooperazione tra imprese. In pratica si tratta si spostare il punto centrale dalla realizzazione di un insieme di requisiti fisso al raggiungimento degli obiettivi finali di prodotto o servizio. Ciò richiede che le diverse imprese coinvolte (clienti e fornitori) cooperino a tal fine. Ovviamente questa nuova visione si deve riflettere nei contratti che saranno meno rigidi, per quanto riguarda l’ambito di progetto, e nei quali si dovrà invece favorire la cooperazione tra le parti, allo scopo di raggiungere obiettivi di business condivisi, in modo da favorire un rapporto di tipo win-win (come già esposto nella prima parte dell’articolo).

Cambiamenti nella struttura del progetto

Anche lo schema della struttura di progetto deve essere rivisto: non si adotterà più un approccio basato su una sequenza di fasi (raccolta requisiti, analisi, progettazione, …) in cui il rilascio avviene unicamente alla fine del progetto, ma invece si favorirà un struttura iterativa e incrementale che si avvarrà di una serie di rilasci progressivi. Ognuno di questi servirà a validare quanto realizzato, e a ricevere dei feedback che indirizzeranno i rilasci successivi fino a completare un prodotto in cui siano massimizzati valore e qualità.

Dunque nei contratti agili l’ambito non viene definito in maniera esatta e non modificabile; tutte le clausole legate a uno scope fisso vengono a decadere in favore della possibilità di sfruttare “…il cambiamento a favore del vantaggio competitivo del cliente”, come scritto nei principi del Manifesto Agile. La rigidità dei requisiti rischierebbe di schiacciare le opportunità di collaborazione tra le due parti.

 

 

Figura 3 – Il contratto agile non punta a schiacciare la controparte vista come “nemico”, ma a favorire opportunità di vantaggio competitivo per tutte le parti in causa (win-win).

 

Nei diversi contratti agili esistono possibili variazioni nel grado di specifica dell’ambito e della sua variabilità, andando da molto a poco. Queste variazioni sono in genere collegate ai differenti schemi di pagamento. Vediamo a titolo d’esempio due schemi agli estremi della scala:

• contratti target-cost: in cui si ha la massima definizione dell’ambito globale all’inizio di progetto;
• contratti progressivi: in cui nessun ambito viene definito con un orizzonte temporale superiore a quello di un’iterazione.

Contratti target-cost

Nello schema di pagamento utilizzato nei contratti denominati target-cost, l’ambito (insieme delle funzionalità) e i dettagli vengono identificati quanto meglio possibile all’inizio del progetto, allo scopo di calcolare il costo target iniziale. Quindi, pur utilizzando un approccio iterativo e incrementale, è possibile dedicare tempo e risorse per definire con la dovuta precisione i requisiti necessari a calcolare un costo di partenza che poi utilizzeremo per gestire il rapporto tra le due parti. Lo schema di pagamento farà riferimento al costo obiettivo cercando di non superarlo.

Inoltre, questi contratti consentono meccanismi di modifica dell’ambito a partire da quello ipotizzato inizialmente. Gli scarti tra ambito e costo calcolati all’inizio vengono gestiti consentendo di rimpiazzare un sottoinsieme di funzionalità con un determinato costo (inferiore a quello target) con un altro set di funzionalità di medesimo costo.

Contratti progressivi

Nei contratti progressivi, in genere l’ambito non viene definito oltre l’orizzonte di una singola iterazione: il fornitore viene pagato ad ogni iterazione con una somma calcolata sulla base delle funzionalità presenti. In questo modo anche il rischio di progetto è ridotto a quello inerente una singola iterazione. Il contratto potrà poi evolvere progressivamente man mano che il progetto prosegue e il prodotto/servizio viene realizzato.

Vision di progetto

Per operare con questa logica è fondamentale definire una chiara vision di prodotto. Si può utilizzare la tecnica dell’Elevator Pitch (descritta da Jeffrey Moore nel libro “Crossing the Chasm” [1]) in modo collaborativo, facendo partecipare anche i legali nella scrittura della vision. È fondamentale evitare di scrivere contratti in cui vision e motivazioni di business siano poco chiare, in quanto questo implicherebbe che non esistono punti fermi o riferimenti nel contratto. Inoltre un contratto privo di una panoramica è sicuramente meno comprensibile e potrebbe facilmente essere costituito solo da aspetti legali, vincoli e clausole, rendendolo ottimizzato localmente a favore di una mentalità a silos invece che sistemica.

Nel documento contrattuale è fondamentale inserire nel preambolo la vision assieme al modello di contratto che s’intende utilizzare.

Modello di contratto

Cerchiamo con un esempio di chiarire cosa inserire riguardo al modello di contratto e allo schema di pagamento. Per esempio:

• viene utilizzato un modello di contratto di tipo “target-cost”;
• la base è un prezzo di delivery (consegna) dell’ordine di € XXX.XXX;
• il fornitore rilascerà, e verrà pagato, su base incrementale al termine di ogni iterazione (tipicamente ogni due settimane).

Gestione del cambiamento

Il terzo punto che deve essere sempre presente nei contratti, riguarda la gestione del cambiamento. Questa è inerente alla filosofia che è alla base delle metodologie agili come esplicato nel principio del manifesto agile riportato in figura 4, e si esplica mediante:

• una gestione delle priorità che avviene tramite un backlog in cui si possono modificare le priorità;
• una pianificazione di progetto adattativa e iterativa.

 

 

Figura 4 – Il Manifesto Agile continua a venirci in aiuto.

 

Va evitato l’utilizzo di un pesante processo (tradizionale) di change management o di change request. È fondamentale che i legali comprendano questo punto, in modo che non vengano inseriti termini contrattualistici che violerebbero l’essenza dell’agilità; ciò non esclude del tutto elementi concernenti la gestione dei cambiamenti.

Aspetti pertinenti alle forme di contratto agili ricadono nelle due categorie:

• cambiamenti nella relazione tra le due controparti;
• variazione dell’ambito di progetto.

Cambio nelle relazioni

Ad esempio, se una delle controparti è acquisita da terzi, molto probabilmente ci saranno dei grandi cambiamenti di direzione e strategia aziendale. In questo caso si possono utilizzare clausole legali relative al change management. La natura dei rilasci iterativi e conseguentemente dei pagamenti progressivi, impiegata nelle metodologie agili, rende meno forte la pressione e l’impatto sulle due controparti.

Variazione dell’ambito

Quest’area richiede la massima cura per non snaturare la natura intrinseca delle metodologie Lean Agile, che è quella di consentire e rendere semplici e frequenti le possibili modifiche dell’ambito, favorendo la collaborazione tra le due parti: committente e fornitore. Evitare di richiedere la creazione di una change-management board e l’utilizzo di speciali e complessi processi di cambiamento.

Sono possibili diverse forme di variabilità:

• altamente flessibile senza penalità, utilizzando contratti progressivi con ambito flessibile.
• mediamente flessibile con forme di condivisione di pene/guadagno, utilizzando modelli a costo target.

Fine progetto

Il concetto di termine di un progetto in Agile è legato al meccanismo di controllo dei cambiamenti. In ambito agile la variazione può essere così radicale da portare all’interruzione del contratto, fermando ogni ulteriore attività al termine di una determinata iterazione.

È importante che i legali comprendano che un’interruzione precoce dovrebbe essere vista come un evento positivo e desiderabile, in quanto:

• non comporta necessariamente un fallimento;
• vuol dire che i risultati sono stati ottenuti prima del previsto.

 

 

Figura 5 – La fine di un progetto può rappresentare l’occasione per il dischiudersi di nuove opportunità.

 

Il migliore modello di fine consente al cliente d’interrompere il contratto, senza penali, al termine di qualsiasi iterazione.

Chiaramente, se questa possibilità da una parte offre vantaggi al cliente, che potrà avere prima e pagare meno un prodotto di alta qualità e valore, dall’altra potrebbe comportare dei problemi per il fornitore: immaginiamo che quest’ultimo, avendo coinvolto un gran numero di persone per realizzare il progetto, si troverebbe improvvisamente senza lavoro. A tale scopo i legali devono introdurre nei contratti agili delle variazioni nelle clausole di terminazione, al fine di proteggere il fornitore. Tali clausole includeranno un meccanismo basato su una scala di penalità, per il committente, che si riducono nel tempo (con le iterazioni).

Negoziare la terminazione di un contratto

La fine (normale o precoce) di un progetto può rappresentare una delle aree più difficili da negoziare in un contratto. In agile esistono però dei fattori di È:

• al termine di ogni iterazione il cliente ha un sistema funzionante;
• entrambe le parti hanno sempre una chiara e trasparente vista dello stato dei deliverable.

È fondamentale che i legali comprendano questi concetti.

Per concludere questo punto osserviamo, in figura 6, l’andamento del valore ottenuto rispetto alle funzionalità rilasciate. Mentre nel caso di metodologie waterfall l’andamento è essenzialmente lineare, e quindi a metà delle funzionalità totali avremo circa il 50% del valore, nelle metodologie agili, l’andamento non lineare consente di ottenere maggiori benefici: con metà delle funzionalità si potrebbe ottenere anche il 90% del valore. Quest’importante caratteristica può rappresentare un’importante opportunità per il cliente, inoltre quest’andamento consente di evitare la produzione di funzionalità di scarso valore o superflue.

 

 

Figura 6 – Andamento del valore ottenuto rispetto alle funzionalità rilasciate.

 

Approvazione

Il quinto aspetto riguarda i criteri e il meccanismo d’approvazione, da parte del committente, di un prodotto o servizio. Questa è un’area particolarmente delicata e fonte di possibili contrasti. Immaginate un cliente che decida che ciò che aveva approvato tre iterazioni prima non è più valido; come ci si dovrebbe comportare? Questa e altre questioni devono essere prese in considerazione nei criteri d’approvazione presenti nei contratti agili.

L’assenza d’ambiguità, che favorirebbe la conflittualità, deve essere considerata una preoccupazione fondamentale da parte dei legali e delle due controparti al fine di trovare un accordo. I concetti che devono essere enfatizzati e condivisi sono i seguenti:

• Doneness: completamento di un incremento di prodotto;
• Acceptance: l’effettiva approvazione e i criteri a essa correlati;
• Correction: la verifica che il sistema risponda alle esigenze e che sia di alta qualità.

Deve essere posta particolare cura nella negoziazione di questi aspetti favorendo la collaborazione tra le parti. Nel caso di un prodotto realizzato utilizzando metodologie tradizionali, l’accettazione avviene in modo formale solo al termine del progetto. Questo rende questo processo, che spesso richiede un collaudo effettuato mediante l’esecuzione di un insieme di test d’accettazione da parte dell’utente, complesso e critico.

Agile semplifica l’approvazione

Impiegando metodologie agili, l’approvazione viene notevolmente semplificata grazie al delivery iterativo e allo sviluppo incrementale del prodotto. Al termine di ogni iterazione può essere approvato (anche formalmente) un incremento del prodotto. Inoltre, l’automazione degli acceptance test riduce l’effort manuale necessario per la validazione del prodotto, fino a richiederne una quantità piccola o addirittura nulla. L’accettazione finale sarà quindi la composizione di una serie di fasi precedenti. In ciascuna iterazione avviene un’approvazione parziale basata su un set di test precedentemente concordato, e nel caso di Scrum, in conformità alla definition of done.

Data l’importanza di quest’area, i legali devono impiegare tutta la loro professionalità per negoziare un framework d’accettazione in modo che sia contrattualmente chiaro, allo scopo di incoraggiare la collaborazione.

Un ultimo elemento importante è l’identificazione degli utenti finali e del loro livello di coinvolgimento nella validazione del sistema. Tale identificazione deve essere quanto più possibile definita contrattualmente in modo non univoco.

Limiti di responsabilità

Le clausole inerenti i limiti di responsabilità, rappresentano probabilmente l’aspetto di negoziazione più difficile da affrontare nella costruzione dei contratti, e un’area nella quale le metodologie agili non cambiano sostanzialmente la questione. In ogni caso, anche se tali clausole rappresentano un potenziale fattore di contrasto, è fondamentale il loro inserimento nei contratti.

In Agile, il processo iterativo e incrementale limita i pericoli e i rischi di una scoperta di gravi anomalie, tipica di un rilascio “big bang”. Questo processo può attenuare le responsabilità, avendo un incremento di prodotto utilizzabile al termine di ogni iterazione.

Per esempio un’anomalia, grazie al rilascio iterativo, avrà un impatto minore sul sistema, in quanto le conseguenze negative saranno scoperte prima. Questo fatto, da solo, non garantisce  che spariscano del tutto eventuali conseguenze negative, ma perlomeno il loro impatto sarà mitigato.

Possiamo concludere questo tema dicendo che, pur con tutte le cautele del caso, la responsabilità sarà ridotta mediante l’impiego di metodologie agili.

Garanzia

Similmente alle responsabilità, anche gli aspetti concernenti la garanzia vengono mitigati da un approccio incrementale. Il profilo di rischio associato con la garanzia finale è minore dato che i rilasci incrementali consentono di avere un aumento di confidenza e un’accettazione graduale del prodotto. Inoltre, utilizzando degli acceptance test automatici, si avrà un’ulteriore diminuzione del rischio.

È fondamentale esplicitare nel contratto l’aspetto incrementale che dovrebbe legare le garanzie ad ogni rilascio parziale, così come già abbiamo discusso per i limiti di responsabilità.

Le garanzie devono essere legate ai rilasci incrementali e iterativi, anche se ovviamente può esistere una garanzia generale sul prodotto finale.

Deliverable

Per quanto riguarda questo tema, consigliamo di evitare quanto più possibile uno “statement of work” o un “quality plan”, vale a dire l’inclusione nel contratto di una lista dettagliata e fissa di deliverable e di come avvenga l’accettazione di tali manufatti. Perche’? Per una serie di motivi che illustriamo di seguito:

• Perche’ la realizzazione di tali artefatti, genera attività inutili e sprechi piuttosto che favorire la focalizzazione sulla produzione di working software. Inoltre vi è una falsa presunzione di sapere quali siano gli artefatti realmente utili per il progetto.
• In questo modo vengono spese troppe energie nella negoziazione e nella ricerca di una conformità rispetto a un “quality plan”, piuttosto che nella cooperazione per la creazione di software utile.
• Viene rinforzato un meccanismo (spesso illusorio) di command & control di pianificazione predittiva piuttosto che imparare e rispondere al cambiamento.
• Viene anche avvallata l’errata visione che un sistema possa essere definito in modo completo e predicibile, e infine consegnato dimenticando completamente che la sua realizzazione è un lavoro creativo e complesso.

In pratica questo è, ancora una volta, espressione di una falsa linearizzazione di un processo non lineare. Ricordiamo le considerazioni fatte nella prima parte della serie relativamente al Cynefin framework e al modello di Stacey.

Limitare la documentazione

In genere, è superflua anche la produzione di documentazione esaustiva relativa a progettazione e sviluppo di sistemi software. Spesso, tale documentazione viene richiesta e realizzata ipotizzando che poi in fase di manutenzione del prodotto, possa essere utile agli sviluppatori. Nella pratica, l’unica sua utilità è come mezzo didattico per nuovi sviluppatori. Molto spesso però la manutenzione è effettuata dal fornitore stesso, che non ha necessità di documentazione in quanto si può avvalere delle specifiche operative date dai test automatici.

Quindi è meglio evitare gli sprechi e concentrare tutte le energie sullo sviluppo iterativo, basato su creatività ed esplorazione di nuove opportunità, favorito da un rapporto di cooperazione.

Tempistiche di pagamento

Affrontiamo il tema delle tempistiche di pagamento, che devono essere parte integrante dei contratti. Utilizzando le metodologie agili, nel caso più frequente, il pagamento avviene al termine di ogni iterazione una volta che l’incremento di prodotto rilasciato sia stato validato. Queste tempistiche, dipendono in parte dal modello di contratto utilizzato: nel terzo articolo della serie passeremo in rassegna svariati modelli contrattuali.

Vengono descritti tre esempi di tempistiche di pagamento progressivamente più complesse e interessanti, basate sul concetto di pagamento regolare ad ogni iterazione.

Somma fissa al termine di ogni iterazione

Nel primo esempio, il pagamento avviene al termine di ogni iterazione ed è pari al costo totale diviso il numero d’iterazioni. La somma ipotizzata è di € 5000, che rappresenta il 100% della cifra concordata. Dunque, il fornitore completa un nuovo incremento di prodotto e lo consegna al committente al termine di ogni iterazione, per farglielo validare; il cliente paga la quota corrispondente. Nell’esempio ipotizziamo che le iterazioni siano 18 e la somma totale sia pari a € 90000.

 

 

Figura 7 – Pagamento a somma fissa al termine di ogni iterazione: il totale corrisponde alla “rata” moltiplicata per il numero di iterazioni.

 

Somma fissa più bassa al termine di ogni iterazione, più premio finale a conclusione

Nel secondo esempio la cifra complessiva è la stessa, ma vengono pagati ad ogni iterazione € 4000 (pari  all’80% della cifra concordata), trattenendo € 1000 per ciascuna “rata”. Al termine del progetto verrà pagato un premio di € 18000 (pari alla quota trattenuta moltiplicata per il numero d’iterazioni). In figura 8, il 20% di differenza è mostrato in azzurro scuro; la riga arancione finale equivale all’importo complessivo.

 

 

Figura 8 – Pagamento a somma fissa (più bassa) al termine di ogni iterazione, più premio finale a conclusione del progetto.

 

Somma fissa più bassa al termine di ogni iterazione, più premi (più bassi) ogni tot iterazioni

Nel terzo esempio la tempistica di pagamento è analoga a quella del secondo esempio. Il  premio di € 18000, però, viene diviso in tre tranche: dopo 6, 12 e 18 iterazioni (linee arancioni nel grafico). Tali premi vengono pagati al fornitore se le consegne corrispondo a un prodotto validato dal committente. Ovviamente la verifica al termine di ogni iterazione diminuisce di molto il rischio anche per il fornitore, mentre l’intero meccanismo cautela il cliente.

 

 

Figura 9 – Pagamento a somma fissa (più bassa) al termine di ogni iterazione. Il rimanente premio non viene però pagato tutto insieme alla fine, ma suddiviso in tre tranche scadenzate lungo la durata del progetto, alle iterazioni 6, 12 e 18.

 

Tipologie di pagamento

L’ultimo aspetto da considerare nella scrittura dei contratti agili è inerente al meccanismo di pagamento. Esamineremo alcune tra le forme di pagamento più utilizzate, note con la loro denominazione inglese:

• time & materials;
• fixed price per iteration (per unit of time);
• fixed price per unit of work;
• hybrid shared pain/gain;
• fixed price per project and target-cost pricing.

Time & Materials

La forma Time & Materials (T&M), assieme alle sue variazioni, offre una valida soluzione per i progetti agili, perche’ è semplice e diretta. È decisamente raccomandabile in quanto sposa in modo naturale la filosofia iterativa e incrementale propria di tali metodologie.

Questa modalità di pagamento può applicarsi sia a contratti Fixed scope (con ambito fisso) che Variable scope (ambito variabile).

Va detto che l’utilizzo del T&M, in progetti sviluppati in maniera sequenziale, ha sempre sollevato una serie di preoccupazioni, quali il timore che il cliente possa rimanere ingabbiato in un ciclo infinito di pagamenti prima di vedere il prodotto realizzato, o sapere se alla fine abbia un sistema di valore congruente con il capitale investito. Questi problemi sono mitigati nell’approccio agile, grazie al rilascio di un sistema utilizzabile ad ogni iterazione. Il progresso è misurato in termini di funzionalità utilizzabili e testate, di un’alta trasparenza e della possibilità di terminare il progetto ad ogni iterazione (vedere paragrafo relativo alla Fine di progetto).

Il T&M necessita di trasparenza e fiducia da entrambe le parti: ottenerle richiede tempo ed energie. Non di rado può succedere che si parta con contratti basati sul modello fixed price con varianti, per poi arrivare a variazioni del modello T&M, con il crescere della cooperazione tra le parti.

Una serie di variazioni del T&M standard limitano l’esposizione ai pericoli per il cliente e bilanciano perdite e guadagni per entrambe le parti.

Esempi di tali variazioni possono essere le seguenti:

• capped (“senza eccedere una determinata soglia”) T&M per iterazione;
• capped T&M per progetto e/o rilascio;
• capped T&M per iterazione con aggiustamenti e possibili incentivi per il fornitore.

Fixed price per iteration (per unit of time)

In un’altra modalità di pagamento, denominata Fixed price for iteration, il pagamento con prezzo fisso viene effettuato al termine di ogni iterazione; quindi l’unità di misura è data dal tempo. Il maggior pregio di questa formula di pagamento è dato della sua semplicità e predicibilità.

In agile, il modello Fixed price for iteration è spesso utilizzato nell’outsourcing dei progetti: i fornitori esterni vengono pagati al termine di ogni iterazione se il prodotto da loro rilasciato soddisfa il committente.

Vi sono due tipologie per questa modalità di pagamento:

• requisiti definiti e concordati all’inizio di ciascuna iterazione;
• altamente flessibile o senza requisiti predefiniti.

Nel primo caso si hanno problematiche simile a quelle del fixed price a livello di progetto, anche se su scala temporale minore: il fornitore deve avere chiaro quale sia lavoro che deve effettuare e avere confidenza nelle stime, per non perdere denaro. Per quanto riguarda il cliente, il problema, o costo, principale consiste nel ricarico effettuato dal fornitore per gestire il proprio rischio, dato dall’incertezza nell’esplorazione tecnologica e nel lavoro per lo sviluppo dei requisiti. Queste perplessità vengono mitigate dalla brevità delle iterazioni e dalla riduzione dell’ambito corrispondente, rispetto a quanto sarebbe previsto per un progetto tradizionale.

Nel secondo caso, la problematica maggiore è rappresentata dalla fiducia che il cliente riesce ad avere nei confronti del fornitore. Maggiore la fiducia e la cooperazione, migliori saranno i risultati ottenuti. In questo secondo caso, il fornitore, non dovendo gestire i rischi, non effettuerà alcun ricarico.

Ci sono degli aspetti che possono essere sicuramente d’aiuto: la trasparenza, i rilasci frequenti, la facilità d’interruzione del contratto al termine di qualsiasi iterazione.

Fixed price per unit of work (UoW)

Nel terzo schema di pagamento esaminato, viene corrisposto un prezzo fisso al rilascio di ciascuna UoW (Unit of Work, “unità di lavoro”). Mentre nei progetti tradizionali una UoW può corrispondere a qualsiasi deliverable (documento, specifica…) in agile è rappresentata dal settimo principio del manifesto: “il software funzionante è la reale misura del progresso”. Quindi un’unità di lavoro è direttamente legata al concetto di running, tested feature (“funzionalità testate e utilizzabili”) ideato da Ron Jeffrey.

Possono essere utilizzati vari sistemi di stima delle unità di lavoro. I più comuni sono:

• price per story point (maggiormente utilizzato in ambito agile);
• price per function point (in molte realtà questo è uno standard);
• price per feature point (è importante che le parti concordino sul concetto di feature rilasciata).

Questo modello è congruente con i temi Lean Agile dell’essere delivery-oriented (dare massima importanza ai rilasci frequenti), e value-oriented (enfatizzare in valore che guida tutto il processo di sviluppo).

Ciò è vero, supponendo che una UoW agile sia vagamente legata al valore per i clienti (il che non è sempre vero), che pagano proporzionalmente al valore ricevuto. Tuttavia, poiche’ negli schemi che abbiamo visto un punto è maggiormente correlato alla grandezza e all’effort di progetto piuttosto che al reale valore per il cliente, questo aspetto viene in parte a perdersi.

Una questione importante a livello legale e contrattuale è data dalla definizione chiara e condivisa tra le parti (cliente e fornitore) del concetto di point.

• I function point sono meno ambigui e possono essere identificati e verificati da analisti funzionali certificati;
• in contrasto, gli story point, anche se più adatti in un contesto agile, non hanno un significato indipendente, ma solo relativo.

Hybrid shared pain/gain

Esistono numerosi schemi di pagamento ibrido, basati sul criterio della condivisione di pene e guadagni. Uno di tali schemi è stato proposto da Robert C. Martin, e si chiama Discounted fixed price per unit of work, plus discounted T&M (“costo fisso per unità di lavoro scontato più un T&M sempre scontato”). In questo modello viene offerto un costo giornaliero ridotto, per singola persona, più un costo supplementare per UoW (unità di lavoro). Cerchiamo di comprendere questo modello meglio facendo un esempio.

Questi sono i dati dell’esempio:

• si suppone una stima complessiva di realizzazione pari a 1000 punti;
• una velocity media di 40 punti (con un team di 14 persone e iterazioni di 2 settimane);
• supponendo un costo di € 500,00 al giorno;
• il fornitore richiede un prezzo scontato a persona di € 150,00 + un prezzo per punto di € 125,50.

Nella figura si suppone un effort complessivo di 3500 giorni uomo, pagati a € 500,00 per una cifra complessiva di € 1750000. In questo caso, dato che lo sforzo reale è uguale a quello stimato, il cliente pagherà con un semplice schema di tipo T&M.

 

 

Figura 10 – Uno schema di pagamento ibrido.

 

Nel caso il cui l’effort vari, il pagamento da parte del cliente varierà di una quantità proporzionalmente minore. In figura 10 possiamo vedere che nel caso in cui il fornitore riesca a completare il lavoro con uno sforzo pari a 3000 giornate, il costo complessivo sarà di € 1675000, la differenza tra sforzo stimato e reale è del 14%, mentre la diminuzione del pagamento è solo del 4%. Quindi il fornitore viene pagato con una cifra giornaliera maggiore. Stessa cosa avviene nel caso inverso, con un numero di giornate complessive maggiore.

Come nel meccanismo del target-cost, sia fornitore, sia cliente condividono i rischi e i vantaggi.

Fixed price per project e target-cost pricing

Le ultime due forme di pagamento considerate sono denominate prezzo fisso per progetto e pagamento a costo target. Entrambi questi schemi hanno un impatto complessivo sul modello di progetto e di contratto ben maggiore che non quello unicamente legato alla forma di pagamento, perciò li descriveremo nella parte finale della serie, nel terzo articolo.

Conclusioni

Finiamo la seconda parte di quesa serie con alcune considerazioni. La prima è che, per stilare dei contratti, deve necessariamente essere inclusa una serie di aspetti, sia che si tratti di contratti tradizionali, sia di Lean Agile. Nei contratti agili, quindi, non vengono a cadere i punti fermi, ma ciascuno di questi assume una valenza diversa grazie all’enfasi rivolta alla collaborazione e alla ricerca del valore per il prodotto.

La seconda considerazione, è che i legali devono necessariamente conoscere tutti i concetti fondamentali delle metodologie agili e, in particolare modo, l’approccio iterativo e incrementale, l’enfasi sul valore piuttosto che sulla quantità di funzionalità realizzate, il pensiero empirico contrapposto a quello deterministico.

Una volta trattati i concetti alla base dei contratti e discussi dieci punti fondamentali, passeremo nella prossima parte a descrivere diverse forme di contratto.

 

Riferimenti

[1] Geoffrey A. Moore, “Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers”, 3rd ed, Harper Business, 2014