Planning Patterns and Antipatterns

3,714 views

Published on

Slides from my presentation at Better Software 2011 (in Italian)

Published in: Technology
2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
3,714
On SlideShare
0
From Embeds
0
Number of Embeds
1,312
Actions
Shares
0
Downloads
35
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

Planning Patterns and Antipatterns

  1. 1. Planning patterns and antipatterns Matteo Vaccari matteo.vaccari@xpeppers.com @xpmatteo
  2. 2. La pianificazione Agile • L’organizzazione sceglie un Product Owner • Il PO definisce con gli sviluppatori le User Stories • Gli sviluppatori stimano le US • Ogni settimana: • Il PO sceglie le X storie più importanti • Gli sviluppatori implementano le US secondo le indicazioni del PO • Demo delle US che vengono accettate dal POChe cosa può andare storto?
  3. 3. Antipattern: sì bwana
  4. 4. Tu mi dici quello chedevo fare e io lo faccio. Corollario: poi se va male è colpa tua
  5. 5. Siamo contractor o consulenti?Di chi è la responsabilità di progettare?Pretendiamo che sia il PO a trovare le soluzioni?
  6. 6. Antipattern:Progettisti in erba
  7. 7. PO Progettista in erba• Questo bottone mettilo più in qua• Ci deve essere il mio logo lampeggiante!• E questo fammelo un po’ più viola
  8. 8. Antipattern:Disconnessione
  9. 9. Disconnessione dagli utenti• Si lavora sulle storie che interessano di più il Product Owner• Gestiamo 42 diverse varianti di coupon• .... ma non c’è il carrello!
  10. 10. Disconnessione dagli stakeholders• Si lavora sulle user stories che interessano di più il Product Owner• Ci interfacciamo con servizi di analisi statistica del comportamento degli utenti• Ma il committente dice “Tutto quello che volevo era un sito che assomigli a quello del Gorgonzola Zeta”
  11. 11. Antipattern:Se non ha valore per il PO allora non esiste
  12. 12. Conseguenze:• “Non si possono” splittare le storie perché al PO non serve una funzionalità incompleta• “Non si possono” eseguire attività di miglioramento del design perché non sono visibili al PO
  13. 13. Antipattern: i requisiti sono solo funzionali
  14. 14. Esempio:“Riscrivetemi questo sistema!”
  15. 15. • Analizziamo l’applicazione vecchia con il cliente• Ricaviamo un backlog di user stories Dove sono i requisiti non funzionali??
  16. 16. “Rick Kazman mio prof di architetture softwarediceva: i progetti falliscono per ilnon soddisfacimento dei requisiti non funzionali,raramente per il non soddisfacimento deirequisiti funzionali.” Francesco Cirillo, extremeprogramming-it, 18/02/2010
  17. 17. Il cliente ha già un sistema che funziona. Replicare le funzioni non basta. Più veloce Più stabile Più usabile Più bello ... Deve farmi fare più soldi!
  18. 18. Nome: Più-Fatturato Tipo: Requisito non funzionale Descrizione: Fatturare di più che con il sistema vecchio Scala: € fatturati al mese Status [dec. 2010]: 123 K€ Goal [dec. 2011]: 180 K€
  19. 19. Nome: Più-Fatturato Tipo: Requisito di qualità Descrizione: Fatturare di più che con il sistema vecchio Scala: € fatturati al mese Status [dec. 2010]: 123 K€ Goal [dec. 2011]: 180 K€
  20. 20. Nome: Più-Fatturato Tipo: Valore Descrizione: Fatturare di più che con il sistema vecchio Scala: € fatturati al mese Status [dec. 2010]: 123 K€ Goal [dec. 2011]: 180 K€
  21. 21. Nome: Più-Fatturato Tipo: Valore Stakeholder: Gino Rossi, proprietario Descrizione: Fatturare di più che con il sistema vecchio Scala: € fatturati al mese Status [dec. 2010]: 123 K€ Goal [dec. 2011]: 180 K€
  22. 22. Nome: Più-Fatturato Tipo: Valore Stakeholder: Gino Rossi, proprietario Descrizione: Fatturare di più che Nome: Acquisto-Facile con il sistema vecchio Tipo: Valore Scala: € fatturati al mese Stakeholder: Users Status [dec. 2010]: 123 K€ Scala: tempo necessario per trovare Goal [dec. 2011]: 180 K€ e acquistare un determinato articolo Status [giu. 2011]: 150s Nome: Disponibile Goal [dic. 2011]: 30s Tipo: Valore Stakeholder: Davide, operations Nome: Aggiornamento-Facile Scala: % di tempo in cui il sistema è Tipo: Valore disponibile Stakeholder: Luca, help desk Status [giu. 2011]: 90% Scala: Tempo necessario per Goal [dic. 2011]: 97% aggiornare i banner Status [giu. 2011]: 290s Nome: Codice-Pulito Goal [dic. 2011]: 30s Tipo: Valore Stakeholder: Team di sviluppo Scala: McCabeNome: Modifiche-Facili Status [giu. 2010]: 2,7 Tipo: Valore Goal [sempre]: < 3 Stakeholder: Proprietà XPeppers Scala: Tempo necessario a implementare una modifica definita Status [giu. 2011, modifica=nuova home page]: 30 pomodori Goal [set.2011, modifica=nuova home page]: 10 pomodori
  23. 23. Pattern: Avere un piano
  24. 24. Pratica: release planAs the XP customer, you have a right to an overall plan, ... to define softwarereleases and to manage scope to get a quality release out on time.Extreme Programming Installed, 2000. Stakeholder Values!Quarterly CyclePlan work a quarter at a time. Once a quarter reflect on the team, the project,its progress, and its alignment with larger goals.Extreme Programming Explained,2nd ed., 2005
  25. 25. Pattern: Distinguere irequisiti dalle soluzioni
  26. 26. Requisito o Soluzione tecnica? Nome: Informazioni-Studenti Tipo: Requisito funzionale (?) Descrizione: I segretari possono visualizzare e aggiornare le informazioni [A,B,C,...] di uno studente Nome: Produttività-Segreteria Tipo: Valore Descrizione: Il segretario esegue la procedura amministrativa [XYZ] più agevolmente Scala: Tempo necessario ad eseguire [XYZ] (secondi) Status [giu. 2011]: 350s Goal: 20s
  27. 27. Soluzioni che supportano i ValoriNome: Produttività-Segreteria Tipo: Valore Descrizione: Il segretario esegue la procedura amministrativa [XYZ] più agevolmente Scala: Tempo necessario ad eseguire [XYZ] (secondi) Status [giu. 2011]: 350s Goal: 20s Nome: Wizard-Iscrizione-Studenti Tipo: Soluzione Descrizione: Sequenza di passi orientata al compito di iscrivere gli studentiNome: Crud-Studenti Tipo: Soluzione Descrizione: Maschere di gestione tabella studenti
  28. 28. Ha dei criteri di Valore cheCommittente non sono considerati Vuole descrivereProduct Owner soluzioni tecniche Fanno quel che gli Developers si dice di fare
  29. 29. Stakeholder StakeholderStakeholder Stakeholder Hanno Valori Stakeholder Stakeholder Decide quali Soluzioni Product Owner tecniche producono maggior Valore per il costo Propongono Soluzioni Developers tecniche
  30. 30. Caso:rifacimento di un sistema
  31. 31. I rifacimenti sono rischiosi• Abbiamo capito tutto quello che fa il sistema?• Cosa succede il giorno in cui sostituiamo il sistema vecchio con il nuovo?• Che cosa farà il nuovo sistema meglio di quello vecchio?
  32. 32. Qual è il requisito più importante? Nome: Migrazione-Utenti Tipo: Valore Descrizione: l’Utente prosegue la sua operatività con il nuovo sistema Scala: % degli Utenti migrati Goal: [01/01/2012] 100%
  33. 33. Come raggiungere questo obiettivo?Nome: Migrazione-Utenti Tipo: Valore Descrizione: l’Utente prosegue la sua operatività con il nuovo sistema Scala: % degli Utenti migrati Goal: [01/01/2012] 100% Censimento Utenti Utenti tipo I - 3 utenti che necessitano della feature A Utenti tipo II - 7 utenti che necessitano delle feature A, B Utenti tipo III - 400 utenti che necessitano delle feature A, B, C, DNome: Step-Feature-A Tipo: Step Descrizione: Implementare la feature A Criterio di accettazione: Un utente tipo I migrato con successoNome: Step-Feature-B Tipo: Step Descrizione: Implementare la feature B Criterio di accettazione: Un utente tipo II migrato con successo
  34. 34. Nome: Migrazione-Utenti Tipo: Valore Censimento Utenti Descrizione: l’Utente prosegue la sua Utenti tipo I - 3 utenti che necessitano di A operatività con il nuovo sistema Utenti tipo II - 7 utenti che necessitano di A, B Scala: % degli Utenti migrati Utenti tipo III - 400 utenti che necessitano di A, B, C, D Goal: [01/01/2012] 100% Nome: Step-Feature-A Tipo: Step Descrizione: Implementare la feature A Criterio di accettazione: Un utente di tipo I migrato con successo Nome: Step-Feature-B Tipo: Step Descrizione: Implementare la feature B Criterio di accettazione: Un utente di tipo II migrato con successo Nome: Piano-Incrementale Versione: 0.1 Passo 0: Step-Feature-A Passo 1: Step-Feature-B Passo 2: Step-Feature-C ...
  35. 35. Altre soluzioni tecnicheNome: Migrazione-Utenti Tipo: Valore Descrizione: l’Utente prosegue la sua operatività con il nuovo sistema Utente tipo I Utente tipo II Admin Scala: % degli Utenti migrati Goal: [01/01/2012] 100% Linux Windows App nuova App vecchiaNome: Sincronizzare-DB-Legacy Tipo: Soluzione Descrizione: Ogni TX sul DB nuovo viene copiata sul DB vecchio Supporta: Migrazione-Utenti, Piano- Database Batch Sync Database Incrementale nuovo legacy
  36. 36. Nome: Scalabile Tipo: Valore Descrizione: possiamo estendere la capacità del sistema aggiungendo HW Scala: TX/s supportate rispetto a un cluster di 1 server Goal: [2 server] 180% Goal: [3 server] 250% Goal: [4 server] 310%Nome: Stateless Tipo: Soluzione Descrizione: I server non conservano stato fra una richiesta HTTP e l’altra Supporta: ScalabileNome: Sessione-su-DB Tipo: Soluzione Descrizione: La sessione HTTP viene conservata sul DB Supporta: Scalabile, Stateless Impatta: Latenza Soluzioni alternativeNome: Sessione-su-cookie-crittato Tipo: Soluzione Descrizione: La sessione HTTP viene conservata in un cookie crittato stile Rails Supporta: Scalabile, Stateless Impatta: Sicurezza
  37. 37. Altro caso: il “progetto” stage studente
  38. 38. Per saperne di più
  39. 39. 1988 2005 EVO, Planguage
  40. 40. Kai Gilb, kickassproject.com
  41. 41. Grazie dell’attenzione! Extreme Programming:development & mentoring

×