Individuare user story e task adatti al planning game

Una delle problematiche principali del software project management è l’ordinamento degli obiettivi e dei task relativi. Ci sono delle cose da fare prima e altre dopo, mentre nel frattempo dobbiamo essere in grado di dimostrare responsabilità da una parte e progressi concreti dall’altra. L’extreme programming non ci risparmia questa difficoltà, pur mettendo a nostra disposizione strumenti – come il planning game – atti ad analizzare queste problematiche e a sostenere le decisioni del team.

La pianificazione di piccolissimi incrementi di valore nel software si scontra con il bisogno di evitare una eccessiva parcellizzazione del lavoro, dovendo però comunque conservare la possibilità per il team di assorbire l’evoluzione delle specifiche e della sua conoscenza del dominio di interesse. Quindi, insomma, incrementi sì piccoli, ma non troppo.

Una volta chiaro che svilupperemo in successione insiemi parziali e separati di funzionalità, rimane la domanda: come individuo questi insiemi? Quali funzionalità sviluppo prima? Quali dopo?

Lo stesso sistema può essere tagliato in molti modi diversi, in dipendenza di fattori come

  • le caratteristiche del business modellato dal sistema
  • le esigenze del team di sviluppo
  • la conoscenza di dominio del team di sviluppo

Qualche volta si vuole realizzare il core di una applicazione, o addirittura del solo modello, ignorando le funzionalità di mero input/output; altre volte si vuole mettere rapidamente in produzione un sistema funzionante seppur minimale; altre volte il team teme alcune funzionalità le cui difficoltà di sviluppo si possono gestire anticipandone l’analisi e l’implementazione. Le motivazioni possono essere mille! È comunque sempre vero che i sistemi sono sempre troppo grandi perché possano essere descritti efficacemente da una singola user story, questo è poco ma sicuro.

Dobbiamo quindi trovare un metodo per decidere questo taglio.

Purtroppo un metodo non c’è: il taglio delle funzionalità di un sistema è un fatto largamente legato all’intuito – e quindi all’esperienza su cui l’intuito in ogni sua forma si basa. Possiamo porci due domande, per rompere il ghiaccio:

  1. Quale sottoinsieme di funzionalità rappresenta meglio l’essenza del sistema?
  2. Quale sottoinsieme mi aiuterà ad imparare di più?

Per fare alcuni esempi di risposte alla prima domanda:

  • Videogioco: alcune interazioni giocatore – sistema
  • Word processor: digitare del testo e vederlo sul monitor
  • Sito di e-commerce: una singola transazione di acquisto

La seconda domanda è fondamentale perché ci porta dritti verso il concetto di rischio e di conseguenza al concetto di project failure. Anche nel dubbio che scaturisce dal chiedersi “cosa conosco meno?“, imparare da qualche tentativo in più può svolgere un’importantissima funzione anti analysis paralysis.

Ci sono anche degli approcci analitici che possono aiutarci in queste situazioni. Wake, Leddy e Beck ne suggeriscono almeno due:

  1. L’ontogenesi ricapitola la filogenesi

    Una vecchia teoria proposta dallo zoologo Ernst Haeckel nel XIX secolo e fortemente ridimensionata al giorno d’oggi – seppur non completamente abbandonata – sostiene che lo sviluppo del singolo individuo – dallo stato embrionale a quello adulto – ripercorra lo storia della specie stessa – da organismo unicellulare fino allo stato completamente sviluppato. Seppur di interesse biologico ormai basso, questa teoria può servire come ispirazione per fare delle scelte architetturali importanti. Pensare a come il prodotto che si vuole sviluppare si sia evoluto negli anni può costituire una efficace linea guida per capire cosa sia stato importante in primo luogo per il mercato. Non è certo una regola completa! Se abbiamo in mente di sviluppare una novità rivoluzionaria per il mondo del software, beh… sviluppiamola subito!

  2. Strati trasparenti

    Come nelle vecchie enciclopedie si trovavano schemi anatomici del corpo umano basati su fogli trasparenti da sovrapporre (scheletro + organi + muscoli + pelle), così è possibile pensare di sviluppare un sistema nello stesso modo. Lo sviluppo di Tetris avrebbe potuto avere inizio con un gioco a singola colonna senza rotazione del pezzo, poi più colonne, poi con rotazione e infine con punteggi e preview del pezzo successivo. In ogni momento il sistema ha senso sebbene non sia completo come vorremo il sistema finale. Particolare ultimo ma non ultimo: l’ordine di questi strati trasparenti non è certo fissato in modo invariabile: man mano che impariamo possiamo cambiare idea ed anticipare, posticipare, eliminare, aggiungere…

A questi due approcci io voglio aggiungerne altri due, tirando in ballo anche l’opinione di tutti i lettori, che invito a lasciare commenti:

  1. User centered design

    I test di usabilità e le interviste agli utenti sono solo alcune delle pratiche dello user centered design (UCD) che permettono di ottenere una valutazione molto robusta ed empirica su cosa effettivamente costituisca l’essenza di un sistema. Cogliere questa essenza permette sicuramente di fare decisioni più lucide nell’individuare sottoinsiemi di funzionalità appropriati cui assegnare le priorità più alte.

  2. Sviluppo cross-layer

    Gli sviluppatori tendono a dividere le user story lungo linee tecniche. Facciamo un esempio, usando come esempio il caso di un forum web: la user story

    Come utente iscritto voglio inviare un post formattato

    è troppo grande per l’iterazione corrente e deve essere divisa in più storie più piccole. Gli sviluppatori tenderanno a dividerla in questo modo:

    Come utente iscritto voglio riempire la form del post

    e

    Come utente iscritto voglio che il mio post venga salvato nel database

    Così però alla fine della iterazione avremo implementato una user story inservibile producendo un valore nullo sia per l’utente che per il cliente. Un approccio che Bill Wake ha chiamato slicing the cake è sicuramente migliore e ci porta a dividere la user story in questo modo:

    Come utente iscritto posso inviare un post minimale descritto solo dal titolo e dal corpo del testo

    e

    Come utente iscritto posso formattare il testo di un post e salvarne il formato nel database.

    I vantaggi: in primis, stuzzicare da subito tutti i layer dell’architettura di un’applicazione riduce la probabilità di sorprese dell’ultim’ora; inoltre è bene che un’applicazione possa essere rilasciata alla fine di ogni iterazione con funzionalità quindi complete seppur più semplici di quanto inizialmente auspicato.

Pianificare il lavoro iterazione dopo iterazione non è affatto semplice, schiacciati fra le esigenze tecniche dello sviluppo, con le sue propedeuticità, e l’importanza di riscontrare, misurare e mostrare i progressi compiuti. Un’organizzazione intelligente delle user story e dei task è un’abilità che non si può automatizzare, completamente affidata all’intuito e all’esperienza del project manager. Abbiamo però visto alcune tecniche per rendere più semplice questo compito pur producendo codice di alta qualità rilasciabile alla fine di ogni iterazione.

June 20 2008 02:36 am | Esperti

Trackback URI | Comments RSS

Leave a Reply