$30 off During Our Annual Pro Sale. View Details »

Planning Patterns and Antipatterns

Matteo Vaccari
June 27, 2011
6

Planning Patterns and Antipatterns

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

Matteo Vaccari

June 27, 2011
Tweet

Transcript

  1. Planning patterns and antipatterns Matteo Vaccari matteo.vaccari@xpeppers.com @xpmatteo

  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 PO Che cosa può andare storto?
  3. Antipattern: sì bwana

  4. Tu mi dici quello che devo fare e io lo

    faccio. Corollario: poi se va male è colpa tua
  5. Siamo contractor o consulenti? Di chi è la responsabilità di

    progettare? Pretendiamo che sia il PO a trovare le soluzioni?
  6. Antipattern: Progettisti in erba

  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. Antipattern: Disconnessione

  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. 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. Antipattern: Se non ha valore per il PO allora non

    esiste
  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. Antipattern: i requisiti sono solo funzionali

  14. Esempio: “Riscrivetemi questo sistema!”

  15. Dove sono i requisiti non funzionali?? • Analizziamo l’applicazione vecchia

    con il cliente • Ricaviamo un backlog di user stories
  16. “Rick Kazman mio prof di architetture software diceva: i progetti

    falliscono per il non soddisfacimento dei requisiti non funzionali, raramente per il non soddisfacimento dei requisiti funzionali.” Francesco Cirillo, extremeprogramming-it, 18/02/2010
  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. 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. 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. 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. 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. 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€ Nome: Acquisto-Facile Tipo: Valore Stakeholder: Users Scala: tempo necessario per trovare e acquistare un determinato articolo Status [giu. 2011]: 150s Goal [dic. 2011]: 30s Nome: Disponibile Tipo: Valore Stakeholder: Davide, operations Scala: % di tempo in cui il sistema è disponibile Status [giu. 2011]: 90% Goal [dic. 2011]: 97% Nome: Aggiornamento-Facile Tipo: Valore Stakeholder: Luca, help desk Scala: Tempo necessario per aggiornare i banner Status [giu. 2011]: 290s Goal [dic. 2011]: 30s Nome: Codice-Pulito Tipo: Valore Stakeholder: Team di sviluppo Scala: McCabe Status [giu. 2010]: 2,7 Goal [sempre]: < 3 Nome: Modifiche-Facili Tipo: Valore 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. Pattern: Avere un piano

  24. Stakeholder Values! Quarterly Cycle Plan 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 Pratica: release plan As the XP customer, you have a right to an overall plan, ... to define software releases and to manage scope to get a quality release out on time. Extreme Programming Installed, 2000.
  25. Pattern: Distinguere i requisiti dalle soluzioni

  26. 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 Requisito o Soluzione tecnica?
  27. 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 Nome: Wizard-Iscrizione-Studenti Tipo: Soluzione Descrizione: Sequenza di passi orientata al compito di iscrivere gli studenti Nome: Crud-Studenti Tipo: Soluzione Descrizione: Maschere di gestione tabella studenti Soluzioni che supportano i Valori
  28. Product Owner Developers Committente Vuole descrivere soluzioni tecniche Fanno quel

    che gli si dice di fare Ha dei criteri di Valore che non sono considerati
  29. Product Owner Developers Stakeholder Decide quali Soluzioni tecniche producono maggior

    Valore per il costo Propongono Soluzioni tecniche Stakeholder Stakeholder Stakeholder Stakeholder Stakeholder Hanno Valori
  30. Caso: rifacimento di un sistema

  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. 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% Qual è il requisito più importante?
  33. 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, D Nome: Step-Feature-A Tipo: Step Descrizione: Implementare la feature A Criterio di accettazione: Un utente tipo I migrato con successo Nome: Step-Feature-B Tipo: Step Descrizione: Implementare la feature B Criterio di accettazione: Un utente tipo II migrato con successo 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% Come raggiungere questo obiettivo?
  34. Censimento Utenti Utenti tipo I - 3 utenti che necessitano

    di A Utenti tipo II - 7 utenti che necessitano di A, B Utenti tipo III - 400 utenti che necessitano di A, B, C, D 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 ... 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%
  35. Nome: Sincronizzare-DB-Legacy Tipo: Soluzione Descrizione: Ogni TX sul DB nuovo

    viene copiata sul DB vecchio Supporta: Migrazione-Utenti, Piano- Incrementale Database nuovo Linux App nuova Database legacy Windows App vecchia Batch Sync Utente tipo I Utente tipo II Admin Altre soluzioni tecniche 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%
  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: Scalabile Nome: Sessione-su-DB Tipo: Soluzione Descrizione: La sessione HTTP viene conservata sul DB Supporta: Scalabile, Stateless Impatta: Latenza Nome: Sessione-su-cookie-crittato Tipo: Soluzione Descrizione: La sessione HTTP viene conservata in un cookie crittato stile Rails Supporta: Scalabile, Stateless Impatta: Sicurezza Soluzioni alternative
  37. Altro caso: il “progetto” stage studente

  38. Per saperne di più

  39. 1988 2005 EVO, Planguage

  40. Kai Gilb, kickassproject.com

  41. Extreme Programming: development & mentoring Grazie dell’attenzione!