Team agile vs budget fisso: la nostra esperienza e i nostri errori

1,205 views

Published on

L'obiettivo del talk oltre a condividere la nostra esperienza, è quello di mostrare come con una disciplina fedele alle best practices e un team che comunica in modo efficace è possibile affrontare meglio anche progetti a budget fisso.

Condividendo gli insegnamenti emersi da una retrospettiva dove abbiamo analizzato l'esito di un anno di progetti eterogenei (siti web, applicazioni mobile) con contratti a budget fisso, mostreremo quali sono state le azioni e gli errori che hanno portato al successo o insuccesso confrontandoli con il manifesto Agile e le pratiche XP e SCRUM.

(Talk presentato da due speaker Alessandro Violini e Lorenzo Massacci)

Published in: Education
2 Comments
9 Likes
Statistics
Notes
No Downloads
Views
Total views
1,205
On SlideShare
0
From Embeds
0
Number of Embeds
330
Actions
Shares
0
Downloads
20
Comments
2
Likes
9
Embeds 0
No embeds

No notes for slide

Team agile vs budget fisso: la nostra esperienza e i nostri errori

  1. 1. TEAM AGILE vs BUDGET FISSO si può avere successo in un progetto a budget fisso utilizzando le buone pratiche delle metodologie agili?
  2. 2. non abbiamo soluzioni
  3. 3. raccontiamo la nostra esperienza
  4. 4. TEAM AGILE vs BUDGET FISSO ALESSANDRO VIOLINI Front End Developer LORENZO MASSACCI Mobile Developer Front End Developer @violo @lorenzomassacci il nostro TEAM www.e-xtrategy.net
  5. 5. TEAM AGILE vs BUDGET FISSO in certi contesti è inevitabile: Bandi, Pubbliche Amministrazioni, Startup, ...
  6. 6. http://en.wikipedia.org/wiki/Project_management_triangle il triangolo di ferro per mantenere l’equilibrio, al variare di una componente, devono variare anche le altre
  7. 7. la nostra retrospettiva 1 ANNO di progetti eterogenei a budget fisso 60% #fail 40% #win
  8. 8. #fail quando definiamo un progetto a budget fisso? il cliente deve aggiungere extra budget il fornitore lavora sottocosto e ci rimette il cliente non è soddisfatto del prodotto consegnato alla fine
  9. 9. la nostra retrospettiva 60% #fail 40% #win come abbiamo valutato questo dato? come hanno influito le buone pratiche del metodo agile?
  10. 10. valutazioni del progetto aderenza al manifesto agile http://agilemanifesto.org/iso/it individui e interazioni - software funzionante collaborazione col cliente - risposta al cambiamento attuazione del metodo user story - release planning - rilasci frequenti - iterazioni cliente parte del team - retrospettive durante il progetto pair programming - test automatici - etc. particolarità contrattuali
  11. 11. le pagelle dei progetti #win #fail aderenza manifesto agile aderenza manifesto agile 10 - 8 - 6 6-5-9-6-6 attuazione del metodo attuazione del metodo 7-7-8 3-6-6-6-8
  12. 12. il METODO nei progetti Cliente parte del team User story Release planning // 100% // dove non fatto #fail Iterazioni Rilasci frequenti // dove non fatto #fail // 90% // dove non fatto #fail Retrospettive durante il progetto Pair programming // fa tendere il #fail al #win // effetto vantaggioso Test automatici // effetto vantaggioso
  13. 13. particolarità contrattuali #fail budget non stimato dal team di sviluppo #fail progetto troppo vasto da essere stimato #win contratto aperto a budget fisso che non blinda lo scope #fail
  14. 14. l’influenza del PO #win PO presente e dal potere decisionale #fail PO assente #win proattività verso i bisogni del PO #fail PO multipli e in contrasto #epicfail PO finto in realtà è un intermediario
  15. 15. lo scope #win scope nogoziato bene #fail non saper dire di NO #fail impossibilità di negoziare lo scope con il PO
  16. 16. conclusione le metodologie agili non sono state mai la causa diretta del #fail o del #win di un progetto a budget fisso. spesso il fallimento del progetto a budget fisso è causato dalla mancata negoziazione dello scope e da una comunicazione non efficace con il PO.
  17. 17. chi è il Product Owner? ● ● ● ● ● ha la vision del prodotto non conosce i dettagli sa perché lo stiamo costruendo sa quale problema risolveremo e a ha il potere di prendere decisioni chi
  18. 18. che cosa significa negoziare lo scope? lo scope fisso nasce da una falsa promessa: sapere quanto è complesso realizzare un software prima di farlo.
  19. 19. che cosa significa negoziare lo scope? scegliere in ogni momento la strada migliore per raggiungere l’obiettivo.
  20. 20. cosa abbiamo imparato? ● non vivere il progetto come un conflitto tra le due realtà ● coinvolgere il Cliente favorendo un dialogo efficace e costante ● farlo diventare parte integrante del team così da remare tutti nella stessa direzione

×