Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lean Agile Contracts - iad 2012

4,300 views

Published on

This presentation, that was presented at the Italian Agile Day 2012 conference by Fabio Armani. It deals with Lean Agile Contracts in terms of related principles, topics, typologies and models.

Published in: Technology

Lean Agile Contracts - iad 2012

  1. 1. iad2012 #iad12 | @fabioarmani
  2. 2. Chi sonoFabio Armani•  CEO di OpenWare•  f.armani@open-ware.org•  @fabioarmani
  3. 3. Una domanda che mi viene posta frequentemente è la seguente:“E’ possibile stilare contratti in ambito Agile?”
  4. 4. Collaborazione col cliente piùche negoziazione dei contratti
  5. 5. #iad12|  @fabioarmani  
  6. 6. “Nella lunga storia del genere umano (e delle specie animali, anche) coloro che hanno imparato a collaborare eimprovvisare più efficacemente hanno prevalso.“ Charles  Darwin  
  7. 7. Il dilemma del prigioniero #iad12|  @fabioarmani  
  8. 8. Il dilemma del prigioniero   vantaggio  Fornitore   svantaggio   svantaggio   vantaggio   Cliente  
  9. 9. Il dilemma del prigioniero   vantaggio      Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  10. 10. Il dilemma del prigioniero   vantaggio      Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  11. 11. Il dilemma del prigioniero   vantaggio      Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  12. 12. Il dilemma del prigioniero   vantaggio      Fornitore   lose-­‐   win   svantaggio   svantaggio   vantaggio   Cliente  
  13. 13. Saggezza convenzionale
  14. 14. Saggezza convenzionale•  Le aziende inevitabilmente sono attente ai propri interessi•  I contratti sono necessari per limitare comportamenti opportunistici
  15. 15. Approccio agile
  16. 16. Approccio agile•  Si suppone che l’altra parte agirà in buona fede•  Lasciare che sia la relazione a limitare lopportunismo•  Utilizzare il contratto per introdurre incentivi
  17. 17. T5  Agreement   #iad12|  @fabioarmani  
  18. 18. Predi>vo   #iad12|  @fabioarmani  
  19. 19. Empirico   #iad12|  @fabioarmani  
  20. 20. “la mappa non è il territorio“ Alfred  Korzibsky  
  21. 21. Cynefin
  22. 22. Lean Agile Contracts
  23. 23. #iad12|  @fabioarmani  
  24. 24. 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
  25. 25. 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
  26. 26. Functionality Traditional  Time Cost
  27. 27. Resources Functionality Time fixed Agile   Traditional   vary Time Functionality Cost
  28. 28. Lean Agile Contracts
  29. 29. 1
  30. 30. Ciclo di rilascio•  Al termine di ogni iterazione time-boxed, viene consegnato incrementalmente un sistema deployabile con funzionalità utilizzabili
  31. 31. 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
  32. 32. 2
  33. 33. 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
  34. 34. 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
  35. 35. #iad12|  @fabioarmani  
  36. 36. 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
  37. 37. Elevator  Pitch  It’s a technique for distilling the product value proposition #iad12|  @fabioarmani  
  38. 38. 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
  39. 39. 3
  40. 40. Gestione del cambiamento•  Legata alla filosofia che è alla base delle metodologie agili stesse
  41. 41. 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à
  42. 42. 4
  43. 43. 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”
  44. 44. 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
  45. 45. 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
  46. 46. Value  capture  vs  delivery  CumulaFve   Value   Captured   Features  delivered  
  47. 47. Value  capture  vs  delivery  CumulaFve   Value   Captured   50%   Usual   AssumpFon   Features  delivered   50%  
  48. 48. Value  capture  vs  delivery   Actual   DistribuFon   90%  CumulaFve   Value   Captured   50%   Usual   AssumpFon   Features  delivered   50%  
  49. 49. 5
  50. 50. Approvazione•  Non ci devono esser ambiguità circa: –  Doneness –  Acceptance –  Correction•  Particolare cura nella negoziazione di questi aspetti favorendo la collaborazione
  51. 51. 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
  52. 52. 6
  53. 53. 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
  54. 54. 7
  55. 55. 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
  56. 56. 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
  57. 57. 8
  58. 58. 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
  59. 59. 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
  60. 60. 9
  61. 61. 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 …
  62. 62. Tempistiche di pagamento 5K per iteration (100%) 3x5K = 15K 18x5K = 90KPayment   3 Time   18
  63. 63. Tempistiche di pagamento 4K per iteration (80%) 3x4K = 12K 18x4K = 72KPayment   72k +18k = 90K 3 Time   18
  64. 64. Tempistiche di pagamento 4K per iteration (80%) 6x4k + 6k = 30k 12x4k + 6k + 6k = 60kPayment   72k +12k + 6k = 90k 6 Time   12 18
  65. 65. 10
  66. 66. 10 Pagamento e fatturazione,compresi eventuali clausole di bonus e penali
  67. 67. 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
  68. 68. Time & Materials•  Estremamente valido per progetti agili: semplice e diretto•  Raccomandato•  Può applicarsi sia a: –  Fixed scope –  Variable scope
  69. 69. 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
  70. 70. 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
  71. 71. 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”
  72. 72. 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
  73. 73. 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
  74. 74. 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
  75. 75. 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
  76. 76. Shared pain/gain : esempioactual 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
  77. 77. Shared pain/gain : esempioactual 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
  78. 78. Shared pain/gain : esempioactual 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
  79. 79. 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
  80. 80. Sydney Opera House•  Iniziato come progetto a prezzo fisso e data fissa•  Sfortunatamente non era assolutamente un progetto standard•  Come risultato …
  81. 81. 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
  82. 82. 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
  83. 83. Soluzioni  agili  •  Una soluzione agile per situazioni basate sul prezzo fisso sarebbe quella di svincolare langolo di pianificazione del triangolo tempo-costo-qualità
  84. 84. 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
  85. 85. Soluzioni  agili  •  Di solito il cliente ha il diritto di sospendere la collaborazione dopo ogni iterazione, possibilmente con un dato premio
  86. 86. Output Fixed Scope Fixed Scope Time
  87. 87. Output Fixed Time Fixed Time Time
  88. 88. Time & Materials$$$   profit   Effort  
  89. 89. 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  
  90. 90. 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!
  91. 91. Time & Materials$$$   profit   Effort  
  92. 92. Time & Materials$$$   with Fixed Scope and Cost Ceiling Work  stops  when  all   requirements  have   been  met   profit   Effort  
  93. 93. Time & Materials$$$   with Variable Scope and Cost Ceiling Work  stops  latest  at   Point  of  Maximum   revenues   profit   Effort  
  94. 94. Lean Agile Contracts
  95. 95. Modelli di contratto
  96. 96. Fixed Price / Fixed Scope$$$   revenue   Revenue  is  constants   regardless  effort  applied   or  delivery  date   Effort  
  97. 97. 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ì).
  98. 98. 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ì).
  99. 99. 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
  100. 100. 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
  101. 101. 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
  102. 102. 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
  103. 103. 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
  104. 104. 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
  105. 105. FP/FS : waterfall o agile? “La cosa peggiore che possiate fare con un progetto FPFS è rendere le cose ancorapeggiori adottando un approccio tradizionale di tipo sequenziale” Craig Larman & Bas Vodde
  106. 106. FP/FS : perché no•  Scope definito troppo presto (per proteggere il fornitore)•  Scope troppo esteso (per proteggere il cliente)
  107. 107. Variable-price variable-scope progressive contracts
  108. 108. 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
  109. 109. 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
  110. 110. 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)
  111. 111. 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
  112. 112. Phased Development$$$   Project  delivers  funcFonality  ≈quarterly   Budget  &  PrioriFes  adjusted  quarterly  as  well     profit   Effort  
  113. 113. Phased Dev : struttura•  Vengono finanziati dei rilasci trimestrali e approvati fondi supplementari dopo ogni release di successo
  114. 114. 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
  115. 115. Phased Dev : rischi•  Per il cliente il rischio è limitato al massimo ad un trimestre dei costi di sviluppo
  116. 116. Cash  flow  –  release  singola  
  117. 117. Cash  flow  –  2  release  
  118. 118. Cash  flow  –  staged  
  119. 119. 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
  120. 120. Fixed Profit$$$   profit   Effort  
  121. 121. Fixed Profit$$$   AMer  target  compleFon   date,  Supplier  works  at   cost   profit   Effort  
  122. 122. 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
  123. 123. 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
  124. 124. 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
  125. 125. 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
  126. 126. 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
  127. 127. Fixed Profit : esempiotarget 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
  128. 128. 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
  129. 129. 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
  130. 130. 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
  131. 131. Jeff Sutherland
  132. 132. Money for nothing$$$   Business  value  achieved,   so  works  stops     EsFmate  to  do   “everything”   “Missing  profit”   profit   Effort  
  133. 133. 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
  134. 134. 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
  135. 135. Business  Value   Change for Free Time  
  136. 136. Change for Free Want this new one!Business  Value   Time  
  137. 137. Change for Free Want this new one!Business  Value   Drop this one Time  
  138. 138. Business  Value   Money for Nothing ROI cut-off Stop here Time  
  139. 139. Business  Value   Money for Nothing Don’t do these two ROI cut-off Stop here Time  
  140. 140. Moore   difficult  !  Grande  Mago  -­‐  h:p://www.alessandropoli?.it/site/    
  141. 141. Business  Value   Money for Nothing Time  
  142. 142. Business  Value   Money for Nothing ROI cut-off Stop here Time  
  143. 143. Business  Value   Money for Nothing Don’t do these three ROI cut-off Stop here Time  
  144. 144. 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
  145. 145. Fixed Resources, Fixed Date 80% of Business ValueCost   3 Time   20
  146. 146. Lean Agile Contracts
  147. 147. I contratti che promuovono o obbligano un ciclo di svilupposequenziale aumentano i rischi di progetto!
  148. 148. Suggerimenti•  Money for Nothing & Change for Free•  Progessive•  Multi-phase variable model•  Adattamento e condivisione di pain/gain e rischi –  Target cost –  Profit sharing
  149. 149. La forma del contratto pone importanti basi per un progetto di successo
  150. 150. Ricordiamo cosa dice il ManifestoAgile: la cooperazione con il cliente è più importante del contratto
  151. 151. Quindi, qualunque cosa si faccia, èfondamentale tenere una relazione positiva con il cliente!
  152. 152. What  are  Agile  approaches?  
  153. 153. Fabio ArmaniCEO OpenWaref.armani@open-ware.org@fabioarmani

×