Le lingue
Pagine
Legale
iad2012 #iad12 | @fabioarmani
Una domanda che mi viene posta frequentemente è la seguente:
“E’ possibile stilare contratti in ambito Agile?”
Collaborazione col cliente più che negoziazione dei contratti
#iad12| @fabioarmani
“Nella lunga storia del genere umano (e delle specie animali, anche) coloro che hanno imparato a collaborare e
improvvisare più efficacemente hanno prevalso.“
Charles Darwin
Il dilemma del prigioniero
#iad12| @fabioarmani
Il dilemma del prigioniero vantaggio
svantaggio
vantaggio svantaggio
Cliente
Fornito
re
Il dilemma del prigioniero
lose-‐win
vantaggio
svantaggio
vantaggio svantaggio
Cliente
Fornito
re
Il dilemma del prigioniero
lose-‐win
vantaggio
svantaggio
vantaggio svantaggio
Cliente
Fornito
re
Il dilemma del prigioniero
lose-‐win
vantaggio
svantaggio
vantaggio svantaggio
Cliente
Fornito
re
Il dilemma del prigioniero
lose-‐win
vantaggio
svantaggio
vantaggio svantaggio
Cliente
Fornito
re
Saggezza convenzionale
Saggezza convenzionale
• Le aziende inevitabilmente sono attente ai propri interessi
• I contratti sono necessari per limitare comportamenti opportunistici
Approccio agile
Approccio agile
• Si suppone che l’altra parte agirà in buona fede
• Lasciare che sia la relazione a limitare l'opportunismo
• Utilizzare il contratto per introdurre incentivi
T5 Agreement
#iad12| @fabioarmani
Predi>vo
#iad12| @fabioarmani
Empirico
#iad12| @fabioarmani
“la mappa non è il territorio“
Alfred Korzibsky
Cynefin
Lean Agile Contracts
#iad12| @fabioarmani
Contratti agili
• I metodi agili forniscono una grande flessibilità e consentono requisiti e priorità variabili
• Questa adattabilità e flessibilità dello scope possono creare problemi quando si definiscono i criteri di accettazione per contratti e lavori in outsourcing
Contratti agili
• Questi problemi esistono sin dalla nascita delle metodologie agili
• Su questo importante tema sono stati spesi sforzi notevoli
• Nel 1994, la prima edizione del Manuale di DSDM presentava il modello del triangolo invertito
Functionality
Time Cost
Traditional
Functionality
Time Cost
Traditional
Functionality
Resources Time
Agile
fixed
vary
Lean Agile Contracts
1
Ciclo di rilascio
• Al termine di ogni iterazione time-boxed, viene consegnato incrementalmente un sistema deployabile con funzionalità utilizzabili
Ciclo di rilascio
• Aspetti nuovi per i legali – Doneness and deployability : il rilascio ad ogni
iterazione è done, sviluppato, testato … ovvero in teoria consegnabile
– Durata : minore, generalmente due settimane – Time-boxing : tempo fisso ed ambito variabile
2
Ambito del progetto
• Nei contratti agili lo scope non viene definito in maniera esatta e non modificabile
• Nei diversi contratti esistono possibili variazioni nel grado di specifica dell’ambito e della sua variabilità
• Queste variazioni sono in genere collegate ai differenti schemi di pagamento
Ambito del progetto
• Contratti Target-cost – Scope e dettagli vengono identificati quanto
meglio possibile all’inizio del progetto, allo scopo di calcolare il target cost iniziale
– Consentono meccanismi di modifica dello scope
• Contratti Progessivi – In cui lo scope non viene definito oltre l’orizzonte
di una singola iterazione
#iad12| @fabioarmani
Vision di progetto
• Definire una chiara Vision di prodotto • Utilizzare la tecnica dell’Elevator Pitch in
modo collaborativo (partecipano anche i legali)
Moore, “Crosing the Chasm”
• Inserire il modello di contratto
Elevator Pitch It’s a technique for distilling the product value proposition
#iad12| @fabioarmani
Modello di contratto
• Esempio: – questo è un contratto di tipo “target-cost” – La base è un prezzo di delivery dell’ordine di €
XXXX – Il fornitore rilascerà e verrà pagato su base
incrementale al termine di ogni iterazione di due settimane
3
Gestione del cambiamento
• Legata alla filosofia che è alla base delle metodologie agili stesse
Gestione del cambiamento
• Gestione delle priorità nel Backlog • Pianificazione adattativa ed iterativa • Non viene utilizzato un pesante (tradizionale)
processo di change management o di change request
• E’ fondamentale che i legali comprendano questo punto – Non vengano inseriti termini contrattualistici che
violerebbero l’essenza dell’agilità
4
Fine progetto
• Legata al meccanismo di controllo dei cambiamenti
• In ambito agile il cambiamento può essere così radicale da portare all’interruzione del contratto
“fermando ogni attività al termine di una determinata iterazione”
Fine progetto
• Un’interruzione precoce dovrebbe essere vista come un evento positivo e desiderabile – Non comporta necessariamente un fallimento – Vuol dire che i risultati sono stati ottenuti prima
• Consente al cliente di interrompere il contratto, senza penali, al termine di qualsiasi iterazione
• Variazioni nelle clausole di terminazione proteggono il fornitore
Fine progetto
• Queste clausole possono essere particolarmente difficili in ogni contratto
• Fattori di mitigazione in agile: – 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
• E’ fondamentale che i legali comprendano questi concetti
Value capture vs delivery
Features delivered
CumulaFve Value
Captured
Value capture vs delivery
Usual AssumpFon
50%
50%
Features delivered
CumulaFve Value
Captured
Value capture vs delivery
Usual AssumpFon
Actual DistribuFon
50%
50%
90%
Features delivered
CumulaFve Value
Captured
5
Approvazione
• Non ci devono esser ambiguità circa: – Doneness – Acceptance – Correction
• Particolare cura nella negoziazione di questi aspetti favorendo la collaborazione
Approvazione
• Approvazione semplificata grazie al delivery iterativo allo sviluppo incrementale del prodotto
• Automazione degli acceptance test riduce l’effort manuale nella validazione
• L’accettazione finale è la composizione di una serie di fasi precedenti
6
Limiti di responsabilità
• Queste clausole rappresentano probabilmente l’aspetto di negoziazione più difficile
• Vanno in ogni caso inserite nel contratto • In agile il processo iterativo ed incrementale
limita i pericoli di una scoperta di gravi anomalie del sistema “big bang”
• Le conseguenze negative vengono scoperte prima
7
Garanzia
• Similmente alle responsabilità, anche questi aspetti vengono mitigati da un approccio agile
• Ogni accettazione graduale ne ha mitigato il rischio
• Utilizzando Accetance test automatici si ha un ulteriore diminuzione del rischio
Garanzia
• Esplicitare l’aspetto incrementale nel contratto
• Le garanzia devono essere legate ai rilasci incrementali ed iterativi
• Può ovviamente esistere una garanzia generale sul prodotto finale
8
Documentazione
• Evitare quanto più possibile uno “statement of work” o “quality plan” – ovvero una lista dettagliata e fissa di
“deliverable” e di come avvenga l’accettazione di tali artefatti
Documentazione
• Perché? – Genera attività inutili e sprechi piuttosto che la
focalizzazione sulla produzione di “working software”
– Vi è una falsa presunzione di sapere quali siano gli artifact realmente utili
– Troppe energie spese in negoziazione e conformità al “quality plan” piuttosto che cooperazione nella creazione di software utile
– Falsa linearizzazione di un processo non lineare
9
Tempistiche di pagamento
• Il pagamento avviene al termine di ogni iterazione
• Dipende in parte dal modello di contratto • Nei casi più semplici viene pagato il 100%
del prezzo d’iterazione pattuito • In casi più complessi possono essere utilizzati
altri meccanismi …
Tempistiche di pagamento
Time
Paym
ent
3 18
3x5K = 15K
18x5K = 90K
5K per iteration (100%)
Tempistiche di pagamento
Time
Paym
ent
3 18
3x4K = 12K
18x4K = 72K
4K per iteration (80%)
72k +18k = 90K
Tempistiche di pagamento
Time
Paym
ent
6 18 12
6x4k + 6k = 30k
12x4k + 6k + 6k = 60k
4K per iteration (80%)
72k +12k + 6k = 90k
10
10 Pagamento e fatturazione, compresi eventuali clausole di
bonus e penali
Pagamento
• Time & materials • Fixed price per iteration (per unit of time) • Fixed price per unit of work (UoW) • Hybrid shared pain/gain • Fixed price per project and target-cost
pricing
Time & Materials
• Estremamente valido per progetti agili: semplice e diretto
• Raccomandato • Può applicarsi sia a: – Fixed scope – Variable scope
Time & Materials
• Variazioni limitano l’esposizione ai pericoli per il cliente e bilanciano pene/guadagni
• Esempi di variazioni: – Capped (“non eccedere la 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
• Virtù data da semplicità e predicibilità • Viene utilizzato in agile outsourcing • Vi sono due tipologie:
1. Requisiti definiti e concordati all’inizio dell’iterazione
2. Altamente flessibile o senza requisiti predefiniti
Fixed Price per UoW
• In agile una UoW è rappresentata dal settimo principio:
“il software funzionante è la reale misura del progresso”
• Quindi una UoW è legata a “running, tested software feature”
Fixed Price per UoW
• Possono essere utilizzati vari sistemi di stima delle UoW: – Price per story point – Price per function point – Price per feature point
• Questo modello è congruente con i temi agile e lean del – Delivery-oriented – Value-oriented
Shared pain/gain
• Esistono numerosi schemi di pagamento ibrido
• Uno degli schemi è quello proposto da Robert Martin – Discounted fixed price per unit of work, plus
discounted T&M
Shared pain/gain : esempio
project estimate average velocity
(140 people, 2 weeks iteration)
original person-day
estimate
payment if €500 per
person per day
100.000 points 4000 points 35.000 €17.500.000
Shared pain/gain : esempio
• Viene offerto un costo giornaliero ridotto, più un complementare costo per UoW
• Esempio: – Supponendo un costo di €500 al giorno – Il fornitore richiede un prezzo scontato a persona di €150
+ un price per point di €125,50
Shared pain/gain : esempio
actual person-days actual customer
payment
Change in
estimate-to-actual
effort
Change in
estimate-to-actual
payment
effective person-
day rate
35.000 €17.500.000
0 0 €500
Shared pain/gain : esempio
actual person-days actual customer
payment
Change in
estimate-to-actual
effort
Change in
estimate-to-actual
payment
effective person-
day rate
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000
0 0 €500
Shared pain/gain : esempio
actual person-days actual customer
payment
Change in
estimate-to-actual
effort
Change in
estimate-to-actual
payment
effective person-
day rate
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000
0 0 €500
40.000 €18.250.000
14% +4% €456
Shared pain/gain
• Se l’effort reale è uguale a quello stimato, il cliente pagherà con un semplice schema di tipo T&M
• Nel caso il cui tale effort vari, il pagamento da parte del cliente varierà meno
• Come nel meccanismo del target-cost sia fornitore sia cliente condividono i rischi
Sydney Opera House
• Iniziato come progetto a prezzo fisso e data fissa
• Sfortunatamente non era assolutamente un progetto standard
• Come risultato …
Sydney Opera House
• Ci sono voluti 13 anni e 102 milioni di dollari australiani per costruirla al posto dei 3 anni e 7 milioni di dollari stimati – 330 % del tempo – 1350 % dei costi
Sviluppo soMware
• Lo sviluppo del software consiste quasi sempre (in larga misura) nella creazione di qualcosa di nuovo, che nessuno ha realizzato in precedenza
• Pertanto i contratti a prezzo-fisso e data-fissa per lo sviluppo del software sono noti per essere imprecisi ed erronei
Soluzioni agili
• Una soluzione agile per situazioni basate sul prezzo fisso sarebbe quella di svincolare l'angolo di pianificazione del triangolo tempo-costo-qualità
Soluzioni agili
• Ciò in genere implica che si istituisca sia una forma di contratto ‘time & materials’ sia un finanziamento a fasi (gated)
• Nel caso di contratti a tempo e materiali il cliente paga ogni mese per il mese di sviluppo, oppure iterazione dopo iterazione
Soluzioni agili
• Di solito il cliente ha il diritto di sospendere la collaborazione dopo ogni iterazione, possibilmente con un dato premio
Fixed Scope O
utpu
t
Time
Fixed Scope
Fixed Time
Fixed Time
Time
Out
put
Time & Materials
profit
$$$
Effort
T&M : variazioni di scope
• Lo scope non è fissato a priori • Prima o poi, il cliente non vorrà continuare a
pagare, dunque il progetto volgerà al termine
T&M : rischi
• 100% a carico del cliente • Il fornitore ha pochi incentivi a contenere i
costi • Lo sforzo necessario per garantire che solo il
lavoro e le spese legittimi vengano fatturati può essere notevole
• Questo sforzo di tracciamento rappresenta uno spreco!
Time & Materials
profit
$$$
Effort
Time & Materials
profit
Effort
$$$ with Fixed Scope and Cost Ceiling
Work stops when all requirements have been met
Time & Materials
profit
Effort
$$$
Work stops latest at Point of Maximum revenues
with Variable Scope and Cost Ceiling
Lean Agile Contracts
Modelli di contratto
Fixed Price / Fixed Scope
revenue
$$$
Revenue is constants regardless effort applied or delivery date
Effort
FP/FS : struttura
• Concordare gli elementi da fornire • Consegnarli • Inviare fattura • I clienti amano i progetti a prezzo fisso,
perché dà loro sicurezza (almeno così credono)(o almeno la pensano così).
FP/FS : struttura
• Concordare gli elementi da fornire • Consegnarli • Inviare fattura • I clienti amano i progetti a prezzo fisso,
perché dà loro sicurezza (almeno così credono)(o almeno la pensano così).
FP/FS : variazioni di scope
• Nulla: è evidente già nel nome del tipo di contratto : fixed scope
• Il processo di change request ha lo scopo di limitare le modifiche dell’ambito (scope)
• Questo processo è costoso, e le modifiche di solito non sono prevenibili
FP/FS : variazioni di scope
• Dal momento che il cliente per definizione richiede aumenti dello scope, terminare un progetto può essere piuttosto difficile
• D’altra parte il fornitore vuole che il cliente sia soddisfatto, quindi in genere cede
• I requisiti di un contratto di questo tipo devono essere definiti in modo molto stringente e rigoroso
FP/FS : rischi
• Il rischio è molto sbilanciato a sfavore del fornitore
• Se le stime sono sbagliate, il progetto perderà soldi
• Porta ad un lose-lose situation • Introduzione di alto debito tecnico • Il cliente paga più del dovuto e spesso non
ottiene ciò di cui ha realmente bisogno
FP/FS : rischi
• Se vengono anche introdotte clausole di “fixed time” il rischio di progetto aumenta
• Il cliente viene penalizzato anche a lungo termine a causa dell’introduzione di debito tecnico – Aumento dei costi di manutenzione – Aumento dei costi per le evoluzioni
FP/FS : contromisure
• Definire i requisiti mediante user story e MMF
• Gestire le priorità degli elementi del backlog – Scambiare requisiti esistenti con altri di uguale effort – Cambiare l’ordine di esecuzione dei requisiti fissi – Migliorare la “definition of done” ad ogni iterazione
• Aumentare i margini del prezzo di contratto per riflettere i rischi inerenti allo sviluppo FPFS
FP/FS : contromisure
• Proposte di Ken Schwaber: – Il cliente può richiedere altre release in ogni
momento, pagate a T&M – Il cliente può terminare prima se soddisfatto,
pagando al fornitore il 20% del valore rimanente non fatturato
FP/FS : waterfall o agile?
“La cosa peggiore che possiate fare con un progetto FPFS è rendere le cose ancora
peggiori adottando un approccio tradizionale di tipo sequenziale”
Craig Larman & Bas Vodde
FP/FS : perché no
• Scope definito troppo presto (per proteggere il fornitore)
• Scope troppo esteso (per proteggere il cliente)
Variable-price variable-scope progressive contracts
Progressive : struttura
• Implicano uno scope totalmente flessibile che viene definito in modo adattativo ad ogni iterazione successiva
• Ottimi candidati per lo sviluppo agile • Rappresentano un framework per gli accordi
contrattuali che definiscono le relazioni tra le parti e gli schemi di pagamento ma non lo scope
Progressive : struttura
• Rappresentano un modello comune per relazioni a lungo termini tra clienti e fornitori agile
• Un pattern frequente: 1. Utilizzo di primi contratti che sono variazioni di
FPFS 2. Successivamente si ha uno spostamento verso
contratti progressivi con T&M e/o capped T&M per iterazione
Progressive : variazioni
• Capped-price, variable scope • Capped-price, partial-fixed scope : viene
definito solo un piccolo set di requisiti, lasciando spazio ad apprendimento ed adattabilità
• Fixed-price, variable scope : è possibile fissare le date finale (optional scope contract)
Progressive : rischio
• Mitigare i rischi con modelli flessibili di contratto
• Modello multi-fase : un grande progetto viene suddiviso in una serie di progetti più piccoli – Le forme contrattuali possono variare da una fase
all’altra
Phased Development
Effort
$$$
profit
Project delivers funcFonality ≈quarterly Budget & PrioriFes adjusted quarterly as well
Phased Dev : struttura
• Vengono finanziati dei rilasci trimestrali e approvati fondi supplementari dopo ogni release di successo
Phased Dev : variazioni di scope
• Non esplicitamente definito dal modello • Le release sono effettivamente ‘time boxed’ • La consapevolezza che ci potrà essere
un’altra versione il trimestre prossimo rende più facile accettare il rinvio di una funzione per ottenere il time-box
Phased Dev : rischi
• Per il cliente il rischio è limitato al massimo ad un trimestre dei costi di sviluppo
Cash flow – release singola
Cash flow – 2 release
Cash flow – staged
Phased Dev : relazione
• Cooperativa • Sia il cliente sia il fornitore hanno un
incentivo affinché ogni release abbia successo, in modo che verranno approvati ulteriori finanziamenti
Fixed Profit
profit
Effort
$$$
Fixed Profit
profit
Effort
$$$
AMer target compleFon date, Supplier works at cost
Target Cost : struttura
• Basati su obiettivi di business ad alto livello • Il costo target include tutti i cambiamenti • Il target è una responsabilità congiunta delle
due parti • Obbiettivi e costo target vengono
chiaramente comunicati a tutti le persone coinvolte che collaborano allo scopo di raggiungere il goal finale
Target Cost : struttura
• I contratti target cost allineano le motivazioni di entrambe le parti
• Vengono utilizzati da Toyota con i loro fornitori, riflettendo il pilastro del rispetto per le persone del Lean Thinking per stabilire relazioni di lunga durata con i fornitori, basate su fiducia e mutua collaborazione/supporto
Fixed Profit : struttura
• Qualsiasi bilancio del progetto è costituito da costi effettivi e profitto
• Le parti concordano su un determinato profitto in anticipo (ad esempio 150.000 €)
• Indipendentemente da quando il progetto viene completato, il contraente riceve i costi sostenuti più il profitto concordato
Fixed Profit : variazioni di scope
• Lo scope è fisso e viene calcolato durante la fase uno 1. Calcolo del del target cost (no-wishful thinking)
mediante scrupolosa due diligence 2. Esplicitazione dei costi da parte del fornitore in
modo che il cliente possa trasparentemente vedere tutti i dettagli che hanno portato al calcolo del target cost
Fixed Profit : attuazione
• La fase due prevede l’utilizzo di metodologie agili (es: Scrum)
• Tracciamento accurato dei costi • Condivisione dei costi • La chiave di successo è legata alle formule di
condivisione di pain/gain per effettuare aggiustamenti relativi alla differenza tra costi reali e target
Fixed Profit : esempio
target cost target profit target
customer
payment
actual
supplier cost
adjustement actual
customer
payment
actual
supplier
profit
€1.000.000 €150.000 €1.150.000 €1.100.000 + €60.000 €1.210.000
€110.000
€1.000.000 €150.000
€1.150.000 €900.000 - €60.000 €1.090.000
€190.000
Fixed Profit : rischi
• Il rischio è condiviso • Se il progetto finisce prima, il cliente paga
meno, ma il fornitore ha ancora il suo profitto
• Se il progetto supera il budget, il cliente paga di più, ma il fornitore non guadagna il profitto aggiuntivo
Fixed Profit : rischi
• Dopo la data di consegna stabilita, il fornitore non potrà più fatturare altro profitto, si limiterà a coprire i propri costi
• Il rischio è condiviso mediante le formule di aggiustamento
• Inoltre le parti possono (non è garantito) promuovere modi per ridurre gli sprechi durante il progetto
Fixed Profit : relazione
• Cooperativa • Entrambi hanno un chiaro incentivo a finire
presto • Se il lavoro termina prima, sia il cliente, sia lo
sviluppatore ne traggono beneficio • Il cliente per risparmiare denaro e il fornitore
per ottenere un margine di profitto più elevato
Jeff Sutherland
Money for nothing
profit
Effort
$$$
EsFmate to do “everything”
“Missing profit”
Business value achieved, so works stops
MfN / CfF : variazioni di scope
• Lo scope può essere modificato • Feature (o storie) progettate, ma non
realizzate, possono essere sostituite con altre storie della stessa dimensione
• Invece la realizzazione di feature aggiuntive ha un costo extra
MfN / CfF : rischi
• Il rischio è condiviso • Entrambe le parti hanno interesse a
completare il progetto quanto prima • Il cliente avrà costi inferiori, il fornitore avrà
un margine più elevato
Change for Free
Time
Busin
ess V
alue
Change for Free
Time
Busin
ess V
alue
Want this new one!
Change for Free
Time
Busin
ess V
alue
Drop this one
Want this new one!
Money for Nothing
Time
Busin
ess V
alue
ROI cut-off
Stop here
Money for Nothing
Time
Busin
ess V
alue
ROI cut-off
Don’t do these two
Stop here
Grande Mago -‐ h:p://www.alessandropoli?.it/site/
Moore difficult !
Money for Nothing
Time
Busin
ess V
alue
Money for Nothing
Time
Busin
ess V
alue
ROI cut-off
Stop here
Money for Nothing
Time
Busin
ess V
alue
ROI cut-off
Stop here
Don’t do these three
Money for Nothing
Time
Busin
ess V
alue
ROI cut-off
Customer gets 80%
Supplier gets 20%
Project are always done early!
Users avoid code bloat and unnecessary
features
Fixed Resources, Fixed Date
Time
Cost 80% of Business Value
3 20
Lean Agile Contracts
I contratti che promuovono o obbligano un ciclo di sviluppo
sequenziale aumentano i rischi di progetto!
Suggerimenti
• Money for Nothing & Change for Free • Progessive • Multi-phase variable model • Adattamento e condivisione di pain/gain e
rischi – Target cost – Profit sharing
La forma del contratto pone importanti basi per un progetto di successo
Ricordiamo cosa dice il Manifesto Agile: la cooperazione con il cliente è
più importante del contratto
Quindi, qualunque cosa si faccia, è fondamentale tenere una relazione
positiva con il cliente!
What are Agile approaches?
Fabio Armani CEO OpenWare [email protected] @fabioarmani
Top Related