Durante lo sviluppo di un progetto, soprattutto se di tipo commerciale, è essenziale mantenere traccia dell’avanzamento dei lavori. Se da un lato questa attività ruba tempo prezioso allo sviluppo (che inevitabilmente verrà rallentato), è anche vero che i benefici superano di gran lunga i costi. Una comunicazione efficace e tempestiva può davvero salvare la vita ad un progetto, che senza i clienti a cui è destinato rimarrebbe un puro esercizio di programmazione!
Le varie metodologie Agili forniscono diversi strumenti per gestire questa comunicazione e collaborazione fra team di sviluppo, clienti, utenti finali, management. In questa sede ci limiteremo ad evidenziare:
- cosa è stato fatto, ovvero: quanti degli use case inizialmente previsti sono stati effettivamente realizzati?
- problemi riscontrati;
- eventuali cambiamenti delle specifiche;
- prossimi sviluppi;
- varie ed eventuali.
Questa “scaletta”, come qualcuno potrebbe notare, sembra proprio un ordine del giorno per la classica riunione del lunedì in azienda… e in effetti lo è! Immagineremo quindi di essere tutti riuniti in una stanza virtuale a discutere del progetto.
Cosa è stato fatto
Nel secondo articolo di questa serie abbiamo steso un documento di specifica composto dagli schizzi (mock) delle schermate, accompagnati da descrizioni testuali. Di questi use case abbiamo realizzato:
- “Use case #1: homepage”:
- template di pagina, utilizzato da tutta l’applicazione;
- menu, con i link alle varie pagine anche se non ancora implementate;
- contenuti: tabella con gli annunci recenti;
- non è stato ancora implementato il link e relativo feed RSS.
- “Use case #3: dettaglio annuncio”: la pagina non esiste ancora, ma sono state realizzate le funzionalità ad essa necessaria negli strati DAO e Service (metodo getInsertion() in InsertionService e InsertionDao).
Problemi riscontrati
Nascondere i problemi non è la scelta giusta, sul lavoro come (è una nostra opinione) nella vita. Quando si sviluppa software il rischio è di far aumentare il cosiddetto “debito tecnico” (technical debt) che, come tutti i debiti, prima o poi dovrà essere saldato con gli interessi!
I problemi maggiori si sono potuti osservare nella gestione del build; Maven è un sistema molto sofisticato e complesso, inoltre il suo buon funzionamento non dipende solo dalla correttezza di Maven stesso ma anche da altri fattori come: corretta gestione delle librerie da parte dei repository, preparazione degli sviluppatori che lo usano, affidabilità delle infrastrutture che lo sorreggono. Nel nostro caso è successo che, a progetto già iniziato e ad articoli già pubblicati, ci siamo accorti che una dipendenza (javax:javaee-api:6.0-SNAPSHOT) non era corretta. Abbiamo quindi deciso di non correggere “silenziosamente” gli articoli passati, perché in questo modo non saremmo riusciti avvisare i lettori in maniera efficace; abbiamo quindi optato per una soluzione il più possibile completa:
- abbiamo inserito un avviso negli articoli incriminati;
- abbiamo spiegato la situazione nell’articolo n.7, quando è avvenuta la scoperta del problema;
- sempre nell’articolo n.7 abbiamo fornito un archivio zip contenente il progetto completo, come realizzato fino a quel punto.
Cambiamenti di specifiche
Non essendo un progetto “vero”, ovvero con dei clienti reali che bussano ogni giorno alla porta… ehm all’email con nuove richieste, ripensamenti, furbate e fraintendimenti, il problema delle “specifiche mobili” non è molto sentito, ma potremmo provare a simulare questa situazione in futuro.
Prossimi sviluppi
Nei prossimi articoli procederemo con l’implementazione di altri use case, possibilmente affrontando aspetti il più possible eterogenei fra di loro.
Linkografia
- Technical debt – Martin Fowler;
- SCRUM meetings: tipologie di meeting utilizzate nella metodologia di sviluppo SCRUM.
