Esercizio - scelta del processo e pianificazione di uno sprint (progetto originale)
Esercizio originale, nello stile del progetto d'esame (scelta del modello di processo e pianificazione). Teoria: Processi di sviluppo - modelli plan-based, metodi agili e ScrumUn processo software è un insieme strutturato di attività (specifica, progetto e realizzazione, validazione, evoluzione) e si descrive con attività, prodotti, ruoli e condizioni; i processi plan-driven pianificano tutto in anticipo e misurano il progresso sul piano (cascata, modello a V con i livelli di test corrispondenti, sviluppo incrementale pianificato, integrazione e configurazione di componenti, con prototipi e consegna incrementale per gestire il cambiamento, e miglioramento del processo con i livelli di maturità SEI), mentre i metodi agili pianificano in modo incrementale e accolgono il cambiamento (manifesto agile, XP con i suoi valori e le sue dodici pratiche, storie dell'utente e story point); Scrum organizza il lavoro in sprint con tre ruoli (Product Owner, Scrum Master, team), eventi (planning, daily scrum, review, retrospective) e artefatti (product backlog, sprint backlog, incremento), stimando con il planning poker; non c'è un processo giusto, ma priorità diverse (stabilità dei requisiti, criticità, dimensione e distribuzione del team).Processi di sviluppo - modelli plan-based, metodi agili e Scrum →, Ingegneria dei requisiti - requisiti funzionali e non funzionaliUn requisito è la descrizione di un servizio o di un vincolo del sistema, scritta ad astrazione diversa per chi decide (requisiti utente, in linguaggio naturale) e per chi realizza (requisiti di sistema, strutturati e dettagliati); si dividono in funzionali (servizi e comportamento), non funzionali (proprietà e vincoli: prodotto, organizzativi, esterni, da scrivere con una misura verificabile) e di dominio; il processo di ingegneria dei requisiti è iterativo (elicitazione con interviste, etnografia, storie e scenari; analisi e negoziazione; specifica; validazione; gestione del cambiamento con identificatori e tracciabilità) e produce il documento dei requisiti, che dice cosa fa il sistema e non come; i modelli UML (contesto, casi d'uso, sequenza, classi, stati) aiutano a chiarire i requisiti.Ingegneria dei requisiti - requisiti funzionali e non funzionali →.
Testo
Parte A. Per ciascuno dei tre progetti dire, motivando, quale modello di processo conviene (cascata o modello a V, sviluppo incrementale, integrazione e configurazione, metodo agile) e quali pratiche aggiungere:
- il software di controllo di una pompa per infusione di farmaci, con certificazione obbligatoria e requisiti fissati dalla norma;
- un'applicazione web per la biblioteca comunale, con un cliente sempre disponibile, requisiti incerti e rilascio entro tre mesi, sviluppata da quattro studenti;
- un sistema informativo per l'amministrazione di una piccola impresa, per cui esistono già pacchetti commerciali di contabilità e magazzino.
Parte B. Il team della biblioteca ha completato nei tre sprint passati 18, 22 e 20 story point. Il product backlog, in ordine di priorità deciso dal Product Owner, è:
| id | storia | story point |
|---|---|---|
| S1 | registrare un prestito | 5 |
| S2 | registrare una restituzione | 3 |
| S3 | cercare nel catalogo | 8 |
| S4 | calcolare la multa | 5 |
| S5 | prenotare un documento | 5 |
| S6 | avviso di disponibilità | 8 |
| S7 | statistiche per la direttrice | 13 |
Pianificare il prossimo sprint: calcolare la velocità, scegliere le storie, dire che cosa va nello sprint backlog, e descrivere gli eventi dello sprint (con la durata del daily scrum e che cosa si discute alla retrospettiva). Dire come cambia il piano se a metà sprint la direttrice chiede di anticipare S7.
Soluzione
Parte A
| progetto | modello | motivazione | pratiche da aggiungere |
|---|---|---|---|
| 1. pompa per infusione | cascata / modello a V (plan-driven) | requisiti stabili e fissati dalla norma, sistema critico per la sicurezza, certificazione che richiede documentazione completa e tracciabilità; il cambiamento in corso d'opera deve essere minimo; è il caso in cui la rigidità della cascata è un pregio | modello a V (test progettati insieme a ogni fase), requisiti con identificatori e tracciabilità verso i test, ispezioni e revisioni formali, test di accettazione con il cliente; i metodi agili si possono usare dentro le fasi (TDD, integrazione continua) |
| 2. web app della biblioteca | agile (Scrum con pratiche XP), su sviluppo incrementale | requisiti incerti, cliente disponibile, scadenza breve, gruppo piccolo: feedback frequente, consegna incrementale delle storie più importanti per prime | sprint di 2 settimane, product backlog con storie e story point, TDD (JUnit), integrazione continua, retrospettiva; requisiti brevi ma con identificatori per collegare i test |
| 3. sistema per piccola impresa | integrazione e configurazione (riuso di componenti COTS), con consegna incrementale | esistono pacchetti già pronti: costi e rischi minori, consegna più veloce; si accettano compromessi sui requisiti | scoperta e valutazione dei pacchetti, raffinamento dei requisiti in base a ciò che esiste, configurazione, scrittura di adattatori per integrare (Pattern strutturali - Adapter, Decorator, Composite, Facade e ProxyI pattern strutturali compongono classi e oggetti in strutture più grandi: Adapter converte l'interfaccia di una classe in quella attesa dal client (di oggetto, per composizione, o di classe, per ereditarietà multipla di classe e interfaccia); Decorator aggiunge responsabilità a un oggetto con un involucro che ha la stessa interfaccia (l'ordine dei decoratori conta); Composite tratta in modo uniforme foglie e contenitori in una struttura ad albero; Facade offre un'interfaccia semplice a un sottosistema (non cerca il polimorfismo, a differenza dell'Adapter); Proxy è un sostituto con la stessa interfaccia che controlla l'accesso (virtuale, di protezione, di cache, dinamico); Bridge e Flyweight completano le sette forme del catalogo.Pattern strutturali - Adapter, Decorator, Composite, Facade e Proxy →); attenzione alla dipendenza dal fornitore e alla scarsità di controllo sull'evoluzione |
Parte B
Velocità. Media degli sprint passati: story point. Si pianifica al massimo circa 20 punti, non di più (la velocità serve a prevedere con i dati, non a promettere).
Scelta delle storie. Si prendono nell'ordine di priorità finché stanno nella velocità:
| storia | punti | totale | scelta |
|---|---|---|---|
| S1 registrare un prestito | 5 | 5 | sì |
| S2 registrare una restituzione | 3 | 8 | sì |
| S3 cercare nel catalogo | 8 | 16 | sì |
| S4 calcolare la multa | 5 | 21 | no: supera i 20 |
Lo sprint contiene S1, S2, S3 (16 punti). Restano 4 punti di margine: S4 (5 punti) non entra intera e non si spezza per forza (dividere una storia deve avere senso per il cliente); si può chiedere al Product Owner se esiste una parte di S4 da 4 punti consegnabile da sola, altrimenti il margine serve per l'imprevisto e il debito tecnico. S4, S5, S6 e S7 restano nel backlog: 5 + 5 + 8 + 13 = 31 punti, più di un altro sprint intero.
Sprint backlog. Le tre storie scomposte in compiti (per esempio per S1: leggere la tessera, verificare il limite, creare il prestito, test JUnit, stampa della ricevuta), con una task board a tre colonne (da fare, in corso, fatto) e un burndown chart dei punti rimasti.
Eventi dello sprint (durata fissa, per esempio 2 settimane).
| evento | contenuto |
|---|---|
| sprint planning | si sceglie S1, S2, S3, si discute l'obiettivo dello sprint e si scompongono in compiti; le stime si fanno con il planning poker |
| daily scrum | ogni giorno, in piedi, circa 15 minuti: che cosa ho fatto, che cosa farò, quali impedimenti ho |
| sprint review | si mostra l'incremento funzionante (prestito, restituzione, ricerca) a direttrice e bibliotecari e si raccoglie il feedback, che aggiorna il product backlog |
| retrospective | il team riflette sul processo (non sul prodotto): che cosa è andato bene, che cosa migliorare (per esempio test scritti troppo tardi, riunioni lunghe), con uno o due miglioramenti concreti per lo sprint seguente |
Anticipare S7 a metà sprint. Lo sprint ha obiettivo e backlog fissi: il Product Owner non può cambiarli a metà strada (il Team protegge lo sprint). Le possibilità: (1) S7 (13 punti) va nel product backlog con priorità alta e si pianifica nello sprint successivo; (2) se la richiesta è davvero più importante dell'obiettivo dello sprint, il Product Owner può annullare lo sprint (caso estremo, costoso: si perde il lavoro non completato) e si ricomincia con una nuova planning; (3) si rinegozia lo scopo senza cambiare l'obiettivo, togliendo una storia di pari punti. Nei metodi agili il cambiamento è accolto, ma tra gli sprint, per non rompere la prevedibilità.
Versione ripasso
- Parte A, scelta del modello:
| progetto | modello | perché |
|---|---|---|
| pompa per infusione | cascata / modello a V | requisiti stabili e imposti dalla norma, sicurezza critica, certificazione, tracciabilità; pratiche agili solo dentro le fasi |
| web app della biblioteca | agile (Scrum + XP), incrementale | requisiti incerti, cliente disponibile, tempi brevi, gruppo piccolo |
| sistema per piccola impresa | integrazione e configurazione (COTS) | pacchetti già pronti: meno costi e rischi, compromessi sui requisiti |
Pratiche: V-model con test progettati per fase, requisiti con identificatori e revisioni formali (1); sprint, story point, TDD, integrazione continua, retrospettiva (2); valutazione dei pacchetti, adattatori, attenzione alla dipendenza dal fornitore (3).
- Parte B, velocità: story point; non si pianifica di più.
- Scelta nell'ordine di priorità: S1 5 (5), S2 3 (8), S3 8 (16), S4 5 (21: supera 20). Sprint = S1 + S2 + S3 = 16 punti; margine di 4 punti; S4 non si spezza per forza (solo se la parte ha senso per il cliente); nel backlog restano S4 + S5 + S6 + S7 = 5 + 5 + 8 + 13 = 31 punti.
- Sprint backlog: le storie scomposte in compiti (S1: leggere la tessera, verificare il limite, creare il prestito, test JUnit, ricevuta); task board (da fare, in corso, fatto); burndown chart.
- Eventi: planning (obiettivo, storie, compiti, planning poker); daily scrum (in piedi, circa 15 minuti: che ho fatto, che farò, impedimenti); review (incremento mostrato, feedback sul prodotto); retrospective (sul processo, uno o due miglioramenti concreti).
- Anticipare S7 a metà sprint: lo sprint è fisso; S7 (13 punti) va in cima al backlog e si pianifica nello sprint successivo; solo se più importante dell'obiettivo il PO può annullare lo sprint (costoso); oppure si rinegozia lo scopo togliendo una storia di pari punti. Il cambiamento è accolto tra gli sprint.
- Errori tipici: usare la cascata per requisiti instabili; agile senza test né integrazione continua; pianificare oltre la velocità; cambiare il backlog dello sprint a metà strada; confondere review (prodotto) e retrospective (processo); stimare a punti senza il team.