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?
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!
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”
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
“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
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!
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€
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€
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€
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: 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
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.
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?
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
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
Product Owner Developers Stakeholder Decide quali Soluzioni tecniche producono maggior Valore per il costo Propongono Soluzioni tecniche Stakeholder Stakeholder Stakeholder Stakeholder Stakeholder Hanno Valori
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?
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?
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?
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%
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%
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
xpmatteo
destraynor
schacon
mojombo
shlominoach
afnizarnur
addyosmani
moore
garrettdimon
sachag
tammielis
keavy
thoeni