SlideShare a Scribd company logo
1 of 190
Download to read offline
iad2012
          #iad12 | @fabioarmani
Chi sono
Fabio Armani
•  CEO di OpenWare
•  f.armani@open-ware.org
•  @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	
  
Fornitore	
  
       svantaggio	
  




                        svantaggio	
                   vantaggio	
  

                                         Cliente	
  
Il dilemma del prigioniero	
  
       vantaggio	
  




                                         	
                          	
  
Fornitore	
  




                                                              lose-­‐
                                         	
                    win	
  
       svantaggio	
  




                        svantaggio	
                                        vantaggio	
  

                                                Cliente	
  
Il dilemma del prigioniero	
  
       vantaggio	
  




                                         	
                          	
  
Fornitore	
  




                                                              lose-­‐
                                         	
                    win	
  
       svantaggio	
  




                        svantaggio	
                                        vantaggio	
  

                                                Cliente	
  
Il dilemma del prigioniero	
  
       vantaggio	
  




                                         	
                          	
  
Fornitore	
  




                                                              lose-­‐
                                         	
                    win	
  
       svantaggio	
  




                        svantaggio	
                                        vantaggio	
  

                                                Cliente	
  
Il dilemma del prigioniero	
  
       vantaggio	
  




                                         	
                          	
  
Fornitore	
  




                                                              lose-­‐
                                         	
                    win	
  
       svantaggio	
  




                        svantaggio	
                                        vantaggio	
  

                                                Cliente	
  
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




       Traditional	
  


Time                     Cost
Resources       Functionality             Time
            fixed




                       Agile	
  




                    Traditional	
  

                                   vary

  Time          Functionality             Cost
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	
  


CumulaFve	
  
  Value	
  
 Captured	
  




                                             Features	
  delivered	
  
Value	
  capture	
  vs	
  delivery	
  


CumulaFve	
  
  Value	
  
 Captured	
  
              50%	
                                Usual	
  
                                                AssumpFon	
  




                                                         Features	
  delivered	
  
                                      50%	
  
Value	
  capture	
  vs	
  delivery	
  
                                       Actual	
  
                                    DistribuFon	
  

              90%	
  
CumulaFve	
  
  Value	
  
 Captured	
  
              50%	
                                   Usual	
  
                                                   AssumpFon	
  




                                                            Features	
  delivered	
  
                                         50%	
  
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
               5K per iteration (100%)
               3x5K = 15K
               18x5K = 90K
Payment	
  




                 3                       Time	
     18
Tempistiche di pagamento
               4K per iteration (80%)
               3x4K = 12K
               18x4K = 72K
Payment	
  




               72k +18k = 90K




                 3                      Time	
     18
Tempistiche di pagamento
               4K per iteration (80%)
               6x4k + 6k = 30k
               12x4k + 6k + 6k = 60k
Payment	
  




               72k +12k + 6k = 90k




                            6           Time	
     12   18
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           original person-day   payment if €500 per
                    (140 people, 2 weeks iteration)        estimate           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      Change in            Change in         effective person-
                        payment        estimate-to-actual   estimate-to-actual       day rate
                                             effort             payment




           35.000      €17.500.000                     0                    0               €500
Shared pain/gain : esempio


actual person-days   actual customer      Change in             Change in         effective person-
                        payment        estimate-to-actual    estimate-to-actual       day rate
                                             effort              payment
           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      Change in             Change in         effective person-
                        payment        estimate-to-actual    estimate-to-actual       day rate
                                             effort              payment
           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
Output
                       Fixed Scope

         Fixed Scope




                                     Time
Output
         Fixed Time




                      Fixed Time




                               Time
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
$$$	
     with Fixed Scope and Cost Ceiling



                                                 Work	
  stops	
  when	
  all	
  
                                                 requirements	
  have	
  
                                                 been	
  met	
  




                         profit	
  



                                     Effort	
  
Time & Materials
$$$	
     with Variable Scope and Cost Ceiling



                                                  Work	
  stops	
  latest	
  at	
  
                                                  Point	
  of	
  Maximum	
  
                                                  revenues	
  




                          profit	
  



                                      Effort	
  
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
$$$	
  
                        Project	
  delivers	
  funcFonality	
  ≈quarterly	
  
                      Budget	
  &	
  PrioriFes	
  adjusted	
  quarterly	
  as	
  well	
  	
  




          profit	
  
                                                                        Effort	
  
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
$$$	
  




                                       AMer	
  target	
  compleFon	
  
                                       date,	
  Supplier	
  works	
  at	
  
                                       cost	
  




               profit	
  



                           Effort	
  
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         actual       adjustement    actual       actual
                              customer     supplier cost                 customer     supplier
                              payment                                    payment       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
$$$	
  

          Business	
  value	
  achieved,	
  
               so	
  works	
  stops	
  	
  


                                                                       EsFmate	
  to	
  do	
  
                                                                       “everything”	
  




                                                                              “Missing	
  profit”	
  

                                               profit	
  



                                                           Effort	
  
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
Business	
  Value	
  
                        Change for Free




                              Time	
  
Change for Free

                           Want this new one!
Business	
  Value	
  




                                      Time	
  
Change for Free

                           Want this new one!
Business	
  Value	
  




                                                 Drop this one




                                      Time	
  
Business	
  Value	
  
                                 Money for Nothing




                        ROI cut-off


                                      Stop here


                                                  Time	
  
Business	
  Value	
  
                                 Money for Nothing




                                                             Don’t do these
                                                                  two
                        ROI cut-off


                                      Stop here


                                                  Time	
  
Moore	
  
                                      difficult	
  !	
  




Grande	
  Mago	
  -­‐	
  h:p://www.alessandropoli?.it/site/	
  	
  
Business	
  Value	
  
                        Money for Nothing




                               Time	
  
Business	
  Value	
  
                                 Money for Nothing




                        ROI cut-off


                                      Stop here


                                                  Time	
  
Business	
  Value	
  
                                 Money for Nothing




                                                             Don’t do these
                                                                 three
                        ROI cut-off


                                      Stop here


                                                  Time	
  
Business	
  Value	
  
                                 Money for Nothing



                                                 Supplier
                                                 gets 20%        Customer
                                                                 gets 80%


                        ROI cut-off



                                                              Users avoid code bloat
                            Project are always
                                                                 and unnecessary
                               done early!         Time	
            features
Fixed Resources, Fixed Date


                   80% of Business Value
Cost	
  




               3            Time	
         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
f.armani@open-ware.org
@fabioarmani

More Related Content

Viewers also liked

Shape Shift - XP 2009
Shape Shift - XP 2009Shape Shift - XP 2009
Shape Shift - XP 2009Fabio Armani
 
Chorale 2 the Tao of Change
Chorale 2   the Tao of ChangeChorale 2   the Tao of Change
Chorale 2 the Tao of ChangeFabio Armani
 
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013  Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013 Fabio Armani
 
Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Fabio Armani
 
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Fabio Armani
 
Design patterns - parte 1
Design patterns - parte 1Design patterns - parte 1
Design patterns - parte 1Fabio Armani
 
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Fabio Armani
 
Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Fabio Armani
 
Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Fabio Armani
 
Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Fabio Armani
 
Lean UX - Integrated Teams
Lean UX - Integrated TeamsLean UX - Integrated Teams
Lean UX - Integrated TeamsFabio Armani
 
Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
 
Scaling lean agile agile prage 2014 (armani)
Scaling lean agile   agile prage 2014 (armani)Scaling lean agile   agile prage 2014 (armani)
Scaling lean agile agile prage 2014 (armani)Fabio Armani
 
User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013Fabio Armani
 
User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012Fabio Armani
 
Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Fabio Armani
 
Liftoff - how to launch Agile teams and projects
Liftoff - how to launch Agile teams and projectsLiftoff - how to launch Agile teams and projects
Liftoff - how to launch Agile teams and projectsFabio Armani
 

Viewers also liked (17)

Shape Shift - XP 2009
Shape Shift - XP 2009Shape Shift - XP 2009
Shape Shift - XP 2009
 
Chorale 2 the Tao of Change
Chorale 2   the Tao of ChangeChorale 2   the Tao of Change
Chorale 2 the Tao of Change
 
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013  Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
 
Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)
 
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
 
Design patterns - parte 1
Design patterns - parte 1Design patterns - parte 1
Design patterns - parte 1
 
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
 
Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?
 
Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011
 
Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)
 
Lean UX - Integrated Teams
Lean UX - Integrated TeamsLean UX - Integrated Teams
Lean UX - Integrated Teams
 
Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)
 
Scaling lean agile agile prage 2014 (armani)
Scaling lean agile   agile prage 2014 (armani)Scaling lean agile   agile prage 2014 (armani)
Scaling lean agile agile prage 2014 (armani)
 
User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013
 
User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012
 
Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016
 
Liftoff - how to launch Agile teams and projects
Liftoff - how to launch Agile teams and projectsLiftoff - how to launch Agile teams and projects
Liftoff - how to launch Agile teams and projects
 

More from Fabio Armani

Agile Music from the Trenches
Agile Music from the TrenchesAgile Music from the Trenches
Agile Music from the TrenchesFabio Armani
 
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Fabio Armani
 
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfProduct Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfFabio Armani
 
Surfing on the Edge of Chaos
Surfing on the Edge of ChaosSurfing on the Edge of Chaos
Surfing on the Edge of ChaosFabio Armani
 
Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Fabio Armani
 
Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Fabio Armani
 
Appreciative Inquiry - an overview
Appreciative Inquiry - an overviewAppreciative Inquiry - an overview
Appreciative Inquiry - an overviewFabio Armani
 
Appreciative Inquiry - an introduction
Appreciative Inquiry - an introductionAppreciative Inquiry - an introduction
Appreciative Inquiry - an introductionFabio Armani
 
Mapping the Change - final
Mapping the Change - final Mapping the Change - final
Mapping the Change - final Fabio Armani
 
Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Fabio Armani
 
From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019Fabio Armani
 
Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Fabio Armani
 
Psychological Safety - ABD19
Psychological Safety - ABD19Psychological Safety - ABD19
Psychological Safety - ABD19Fabio Armani
 
Enterprise lean agile 2018 challenges ver 0.3
Enterprise lean agile 2018   challenges ver 0.3Enterprise lean agile 2018   challenges ver 0.3
Enterprise lean agile 2018 challenges ver 0.3Fabio Armani
 
Business Agility 2017 (final)
Business Agility 2017 (final)Business Agility 2017 (final)
Business Agility 2017 (final)Fabio Armani
 
Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Fabio Armani
 
Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Fabio Armani
 
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)Fabio Armani
 

More from Fabio Armani (18)

Agile Music from the Trenches
Agile Music from the TrenchesAgile Music from the Trenches
Agile Music from the Trenches
 
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
 
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfProduct Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
 
Surfing on the Edge of Chaos
Surfing on the Edge of ChaosSurfing on the Edge of Chaos
Surfing on the Edge of Chaos
 
Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Agile marketing - beyond it 2021
Agile marketing - beyond it 2021
 
Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)
 
Appreciative Inquiry - an overview
Appreciative Inquiry - an overviewAppreciative Inquiry - an overview
Appreciative Inquiry - an overview
 
Appreciative Inquiry - an introduction
Appreciative Inquiry - an introductionAppreciative Inquiry - an introduction
Appreciative Inquiry - an introduction
 
Mapping the Change - final
Mapping the Change - final Mapping the Change - final
Mapping the Change - final
 
Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Manifiesto de Mañana Programming
Manifiesto de Mañana Programming
 
From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019
 
Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)
 
Psychological Safety - ABD19
Psychological Safety - ABD19Psychological Safety - ABD19
Psychological Safety - ABD19
 
Enterprise lean agile 2018 challenges ver 0.3
Enterprise lean agile 2018   challenges ver 0.3Enterprise lean agile 2018   challenges ver 0.3
Enterprise lean agile 2018 challenges ver 0.3
 
Business Agility 2017 (final)
Business Agility 2017 (final)Business Agility 2017 (final)
Business Agility 2017 (final)
 
Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014
 
Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014
 
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
 

Lean Agile Contracts - iad 2012

  • 1. iad2012 #iad12 | @fabioarmani
  • 2.
  • 3. Chi sono Fabio Armani •  CEO di OpenWare •  f.armani@open-ware.org •  @fabioarmani
  • 4.
  • 5. Una domanda che mi viene posta frequentemente è la seguente: “E’ possibile stilare contratti in ambito Agile?”
  • 6. Collaborazione col cliente più che negoziazione dei contratti
  • 7.
  • 9.
  • 10. “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  
  • 11.
  • 12.
  • 13. Il dilemma del prigioniero #iad12|  @fabioarmani  
  • 14. Il dilemma del prigioniero   vantaggio   Fornitore   svantaggio   svantaggio   vantaggio   Cliente  
  • 15. Il dilemma del prigioniero   vantaggio       Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  • 16. Il dilemma del prigioniero   vantaggio       Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  • 17. Il dilemma del prigioniero   vantaggio       Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  • 18. Il dilemma del prigioniero   vantaggio       Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  • 20. Saggezza convenzionale •  Le aziende inevitabilmente sono attente ai propri interessi •  I contratti sono necessari per limitare comportamenti opportunistici
  • 22. 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
  • 23. T5  Agreement   #iad12|  @fabioarmani  
  • 24. Predi>vo   #iad12|  @fabioarmani  
  • 25. Empirico   #iad12|  @fabioarmani  
  • 26. “la mappa non è il territorio“ Alfred  Korzibsky  
  • 30. 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
  • 31. 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
  • 32.
  • 33. Functionality Traditional   Time Cost
  • 34. Resources Functionality Time fixed Agile   Traditional   vary Time Functionality Cost
  • 36. 1
  • 37.
  • 38.
  • 39. Ciclo di rilascio •  Al termine di ogni iterazione time-boxed, viene consegnato incrementalmente un sistema deployabile con funzionalità utilizzabili
  • 40. 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
  • 41. 2
  • 42.
  • 43.
  • 44. 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
  • 45. 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
  • 47. 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
  • 48. Elevator  Pitch   It’s a technique for distilling the product value proposition #iad12|  @fabioarmani  
  • 49. 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
  • 50. 3
  • 51.
  • 52. Gestione del cambiamento •  Legata alla filosofia che è alla base delle metodologie agili stesse
  • 53. 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à
  • 54. 4
  • 55.
  • 56. 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”
  • 57.
  • 58. 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
  • 59. 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
  • 60. Value  capture  vs  delivery   CumulaFve   Value   Captured   Features  delivered  
  • 61. Value  capture  vs  delivery   CumulaFve   Value   Captured   50%   Usual   AssumpFon   Features  delivered   50%  
  • 62. Value  capture  vs  delivery   Actual   DistribuFon   90%   CumulaFve   Value   Captured   50%   Usual   AssumpFon   Features  delivered   50%  
  • 63. 5
  • 64.
  • 65. Approvazione •  Non ci devono esser ambiguità circa: –  Doneness –  Acceptance –  Correction •  Particolare cura nella negoziazione di questi aspetti favorendo la collaborazione
  • 66. 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
  • 67. 6
  • 68.
  • 69. 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
  • 70. 7
  • 71.
  • 72. 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
  • 73. 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
  • 74. 8
  • 75.
  • 76. 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
  • 77. 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
  • 78. 9
  • 79.
  • 80. 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 …
  • 81. Tempistiche di pagamento 5K per iteration (100%) 3x5K = 15K 18x5K = 90K Payment   3 Time   18
  • 82. Tempistiche di pagamento 4K per iteration (80%) 3x4K = 12K 18x4K = 72K Payment   72k +18k = 90K 3 Time   18
  • 83. Tempistiche di pagamento 4K per iteration (80%) 6x4k + 6k = 30k 12x4k + 6k + 6k = 60k Payment   72k +12k + 6k = 90k 6 Time   12 18
  • 84. 10
  • 85. 10 Pagamento e fatturazione, compresi eventuali clausole di bonus e penali
  • 86.
  • 87. 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
  • 88. Time & Materials •  Estremamente valido per progetti agili: semplice e diretto •  Raccomandato •  Può applicarsi sia a: –  Fixed scope –  Variable scope
  • 89. 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
  • 90. 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
  • 91. 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”
  • 92. 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
  • 93. 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
  • 94. Shared pain/gain : esempio project estimate average velocity original person-day payment if €500 per (140 people, 2 weeks iteration) estimate person per day 100.000 points 4000 points 35.000 €17.500.000
  • 95. 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
  • 96. Shared pain/gain : esempio actual person-days actual customer Change in Change in effective person- payment estimate-to-actual estimate-to-actual day rate effort payment 35.000 €17.500.000 0 0 €500
  • 97. Shared pain/gain : esempio actual person-days actual customer Change in Change in effective person- payment estimate-to-actual estimate-to-actual day rate effort payment 30.000 €16.750.000 -14% -4% €558 35.000 €17.500.000 0 0 €500
  • 98. Shared pain/gain : esempio actual person-days actual customer Change in Change in effective person- payment estimate-to-actual estimate-to-actual day rate effort payment 30.000 €16.750.000 -14% -4% €558 35.000 €17.500.000 0 0 €500 40.000 €18.250.000 14% +4% €456
  • 99. 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
  • 100.
  • 101.
  • 102.
  • 103. Sydney Opera House •  Iniziato come progetto a prezzo fisso e data fissa •  Sfortunatamente non era assolutamente un progetto standard •  Come risultato …
  • 104. 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
  • 105. 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
  • 106.
  • 107. Soluzioni  agili   •  Una soluzione agile per situazioni basate sul prezzo fisso sarebbe quella di svincolare l'angolo di pianificazione del triangolo tempo-costo-qualità
  • 108. 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
  • 109. Soluzioni  agili   •  Di solito il cliente ha il diritto di sospendere la collaborazione dopo ogni iterazione, possibilmente con un dato premio
  • 110. Output Fixed Scope Fixed Scope Time
  • 111. Output Fixed Time Fixed Time Time
  • 112.
  • 113. Time & Materials $$$   profit   Effort  
  • 114. 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  
  • 115. 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!
  • 116. Time & Materials $$$   profit   Effort  
  • 117. Time & Materials $$$   with Fixed Scope and Cost Ceiling Work  stops  when  all   requirements  have   been  met   profit   Effort  
  • 118. Time & Materials $$$   with Variable Scope and Cost Ceiling Work  stops  latest  at   Point  of  Maximum   revenues   profit   Effort  
  • 121.
  • 122. Fixed Price / Fixed Scope $$$   revenue   Revenue  is  constants   regardless  effort  applied   or  delivery  date   Effort  
  • 123. 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ì).
  • 124. 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ì).
  • 125. 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
  • 126. 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
  • 127. 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
  • 128. 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
  • 129.
  • 130. 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
  • 131. 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
  • 132. 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
  • 133. FP/FS : perché no •  Scope definito troppo presto (per proteggere il fornitore) •  Scope troppo esteso (per proteggere il cliente)
  • 134.
  • 135.
  • 136.
  • 137.
  • 138.
  • 139. Variable-price variable-scope progressive contracts
  • 140. 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
  • 141. 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
  • 142. 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)
  • 143. 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
  • 144.
  • 145. Phased Development $$$   Project  delivers  funcFonality  ≈quarterly   Budget  &  PrioriFes  adjusted  quarterly  as  well     profit   Effort  
  • 146. Phased Dev : struttura •  Vengono finanziati dei rilasci trimestrali e approvati fondi supplementari dopo ogni release di successo
  • 147. 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
  • 148. Phased Dev : rischi •  Per il cliente il rischio è limitato al massimo ad un trimestre dei costi di sviluppo
  • 149. Cash  flow  –  release  singola  
  • 150. Cash  flow  –  2  release  
  • 151. Cash  flow  –  staged  
  • 152. 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
  • 153.
  • 154. Fixed Profit $$$   profit   Effort  
  • 155. Fixed Profit $$$   AMer  target  compleFon   date,  Supplier  works  at   cost   profit   Effort  
  • 156. 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
  • 157. 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
  • 158. 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
  • 159. 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
  • 160. 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
  • 161. Fixed Profit : esempio target cost target profit target actual adjustement actual actual customer supplier cost customer supplier payment payment 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
  • 162. 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
  • 163. 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
  • 164. 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
  • 165.
  • 167. Money for nothing $$$   Business  value  achieved,   so  works  stops     EsFmate  to  do   “everything”   “Missing  profit”   profit   Effort  
  • 168. 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
  • 169. 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
  • 170.
  • 171. Business  Value   Change for Free Time  
  • 172. Change for Free Want this new one! Business  Value   Time  
  • 173. Change for Free Want this new one! Business  Value   Drop this one Time  
  • 174.
  • 175. Business  Value   Money for Nothing ROI cut-off Stop here Time  
  • 176. Business  Value   Money for Nothing Don’t do these two ROI cut-off Stop here Time  
  • 177. Moore   difficult  !   Grande  Mago  -­‐  h:p://www.alessandropoli?.it/site/    
  • 178. Business  Value   Money for Nothing Time  
  • 179. Business  Value   Money for Nothing ROI cut-off Stop here Time  
  • 180. Business  Value   Money for Nothing Don’t do these three ROI cut-off Stop here Time  
  • 181. Business  Value   Money for Nothing Supplier gets 20% Customer gets 80% ROI cut-off Users avoid code bloat Project are always and unnecessary done early! Time   features
  • 182. Fixed Resources, Fixed Date 80% of Business Value Cost   3 Time   20
  • 184. I contratti che promuovono o obbligano un ciclo di sviluppo sequenziale aumentano i rischi di progetto!
  • 185. Suggerimenti •  Money for Nothing & Change for Free •  Progessive •  Multi-phase variable model •  Adattamento e condivisione di pain/gain e rischi –  Target cost –  Profit sharing
  • 186. La forma del contratto pone importanti basi per un progetto di successo
  • 187. Ricordiamo cosa dice il Manifesto Agile: la cooperazione con il cliente è più importante del contratto
  • 188. Quindi, qualunque cosa si faccia, è fondamentale tenere una relazione positiva con il cliente!
  • 189. What  are  Agile  approaches?