Planning patterns and antipatterns

Matteo Vaccarimatteo.vaccari@xpeppers.com

@xpmatteo

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?

Antipattern: sì bwana

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

Corollario: poi se va male è colpa tua

Siamo contractor o consulenti?

Di chi è la responsabilità di progettare?

Pretendiamo che sia il PO a trovare le soluzioni?

Antipattern: Progettisti in erba

PO Progettista in erba

• Questo bottone mettilo più in qua

• Ci deve essere il mio logo lampeggiante!

• E questo fammelo un po’ più viola

Antipattern: Disconnessione

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”

Antipattern: Se non ha valore per il PO allora non esiste

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

Antipattern: i requisiti sono solo funzionali

Esempio: “Riscrivetemi questo sistema!”

Dove sono i requisiti non funzionali??

• Analizziamo l’applicazione vecchia con il cliente

• Ricaviamo un backlog di user stories

“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ù-FatturatoTipo: Requisito non funzionaleDescrizione: Fatturare di più che con il sistema vecchioScala: € fatturati al meseStatus [dec. 2010]: 123 K€Goal [dec. 2011]: 180 K€

Nome: Più-FatturatoTipo: Requisito di qualitàDescrizione: Fatturare di più che con il sistema vecchioScala: € fatturati al meseStatus [dec. 2010]: 123 K€Goal [dec. 2011]: 180 K€

Nome: Più-FatturatoTipo: ValoreDescrizione: Fatturare di più che con il sistema vecchioScala: € fatturati al meseStatus [dec. 2010]: 123 K€Goal [dec. 2011]: 180 K€

Nome: Più-FatturatoTipo: ValoreStakeholder: Gino Rossi, proprietarioDescrizione: Fatturare di più che con il sistema vecchioScala: € fatturati al meseStatus [dec. 2010]: 123 K€Goal [dec. 2011]: 180 K€

Nome: Più-FatturatoTipo: ValoreStakeholder: Gino Rossi, proprietarioDescrizione: Fatturare di più che con il sistema vecchioScala: € fatturati al meseStatus [dec. 2010]: 123 K€Goal [dec. 2011]: 180 K€

Nome: Acquisto-FacileTipo: ValoreStakeholder: UsersScala: tempo necessario per trovare e acquistare un determinato articoloStatus [giu. 2011]: 150sGoal [dic. 2011]: 30s Nome: Disponibile

Tipo: ValoreStakeholder: Davide, operationsScala: % di tempo in cui il sistema è disponibileStatus [giu. 2011]: 90%Goal [dic. 2011]: 97%

Nome: Aggiornamento-FacileTipo: ValoreStakeholder: Luca, help deskScala: Tempo necessario per aggiornare i bannerStatus [giu. 2011]: 290sGoal [dic. 2011]: 30s

Nome: Codice-PulitoTipo: ValoreStakeholder: Team di sviluppoScala: McCabeStatus [giu. 2010]: 2,7Goal [sempre]: < 3

Nome: Modifiche-FaciliTipo: ValoreStakeholder: Proprietà XPeppersScala: Tempo necessario a implementare una modifica definitaStatus [giu. 2011, modifica=nuova home page]: 30 pomodoriGoal [set.2011, modifica=nuova home page]: 10 pomodori

Pattern: Avere un piano

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

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.

Pattern: Distinguere i requisiti dalle soluzioni

Nome: Informazioni-StudentiTipo: Requisito funzionale (?)Descrizione: I segretari possono visualizzare e aggiornare le informazioni [A,B,C,...] di uno studente

Nome: Produttività-SegreteriaTipo: ValoreDescrizione: Il segretario esegue la procedura amministrativa [XYZ] più agevolmenteScala: Tempo necessario ad eseguire [XYZ] (secondi)Status [giu. 2011]: 350s Goal: 20s

Requisito o Soluzione tecnica?

Nome: Produttività-SegreteriaTipo: ValoreDescrizione: Il segretario esegue la procedura amministrativa [XYZ] più agevolmenteScala: Tempo necessario ad eseguire [XYZ] (secondi)Status [giu. 2011]: 350s Goal: 20s Nome: Wizard-Iscrizione-Studenti

Tipo: SoluzioneDescrizione: Sequenza di passi orientata al compito di iscrivere gli studenti

Nome: Crud-StudentiTipo: SoluzioneDescrizione: 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 Soluzionitecniche producono maggior

Valore per il costo

Propongono Soluzionitecniche

StakeholderStakeholder

Stakeholder

Stakeholder

Stakeholder

Hanno Valori

Caso: rifacimento di un sistema

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-UtentiTipo: ValoreDescrizione: l’Utente prosegue la sua operatività con il nuovo sistemaScala: % degli Utenti migratiGoal: [01/01/2012] 100%

Qual è il requisito più importante?

Censimento UtentiUtenti tipo I - 3 utenti che necessitano della feature AUtenti tipo II - 7 utenti che necessitano delle feature A, BUtenti tipo III - 400 utenti che necessitano delle feature A, B, C, D

Nome: Step-Feature-ATipo: StepDescrizione: Implementare la feature ACriterio di accettazione: Un utente tipo I migrato con successo

Nome: Step-Feature-BTipo: StepDescrizione: Implementare la feature BCriterio di accettazione: Un utente tipo II migrato con successo

Nome: Migrazione-UtentiTipo: ValoreDescrizione: l’Utente prosegue la sua operatività con il nuovo sistemaScala: % degli Utenti migratiGoal: [01/01/2012] 100%

Come raggiungere questo obiettivo?

Censimento UtentiUtenti tipo I - 3 utenti che necessitano di AUtenti tipo II - 7 utenti che necessitano di A, BUtenti tipo III - 400 utenti che necessitano di A, B, C, D

Nome: Step-Feature-ATipo: StepDescrizione: Implementare la feature ACriterio di accettazione: Un utente di tipo I migrato con successo

Nome: Step-Feature-BTipo: StepDescrizione: Implementare la feature BCriterio di accettazione: Un utente di tipo II migrato con successo

Nome: Piano-IncrementaleVersione: 0.1 Passo 0: Step-Feature-APasso 1: Step-Feature-BPasso 2: Step-Feature-C...

Nome: Migrazione-UtentiTipo: ValoreDescrizione: l’Utente prosegue la sua operatività con il nuovo sistemaScala: % degli Utenti migratiGoal: [01/01/2012] 100%

Nome: Sincronizzare-DB-LegacyTipo: SoluzioneDescrizione: Ogni TX sul DB nuovo viene copiata sul DB vecchioSupporta: 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-UtentiTipo: ValoreDescrizione: l’Utente prosegue la sua operatività con il nuovo sistemaScala: % degli Utenti migratiGoal: [01/01/2012] 100%

Nome: ScalabileTipo: ValoreDescrizione: possiamo estendere la capacità del sistema aggiungendo HWScala: TX/s supportate rispetto a un cluster di 1 serverGoal: [2 server] 180% Goal: [3 server] 250% Goal: [4 server] 310%

Nome: StatelessTipo: SoluzioneDescrizione: I server non conservano stato fra una richiesta HTTP e l’altraSupporta: Scalabile

Nome: Sessione-su-DBTipo: SoluzioneDescrizione: La sessione HTTP viene conservata sul DBSupporta: Scalabile, StatelessImpatta: Latenza

Nome: Sessione-su-cookie-crittatoTipo: SoluzioneDescrizione: La sessione HTTP viene conservata in un cookie crittato stile RailsSupporta: Scalabile, StatelessImpatta: Sicurezza

Soluzioni alternative

Altro caso: il “progetto” stage studente

Per saperne di più

1988 2005

EVO, Planguage

Kai Gilb, kickassproject.com

Extreme Programming:development & mentoring

Grazie dell’attenzione!