A.S. 2018-2019

Istituto di Istruzione Superiore G. Marconi

TPSI

Benvenuti ragazzi!

Questo materiale riepiloga quanto detto a lezione negli scorsi giorni.

Le risposte alle domande dei compiti in classe sono tutte incluse in questo materiale.

I riferimenti al libro di testo sono tra parentesi quadre, come ad esempio [pag. 1].

Il testo in questi box sono per approfondimento. La lettura di questo materiale non è strettamente necessaria per le verifiche, ma è consigliata per vostra cultura personale e in quanto sapere indispensabile per chi vuole diventare un informatico.

Buon studio e buon lavoro.

In questo capitolo vedremo quali sono i buoni principi alla base dello sviluppo software ai giorni nostri.

In questo corso impareremo a sviluppare una applicazione web in HTML5.

Sviluppare una applicazione per il web può sembrare inizalmente semplice, perché le tecnologie base usate (HTML5, browser) sono molto diffuse e abbastanza semplici da usare. Tuttavia, ci sono delle insidie nascoste: le applicazioni web oggi devono soddisfare le esigenze di un mondo che cambia velocemente, sia per quanto riguarda il mercato, sia per le le tecnologie al contorno utilizzate, ad esempio i dispositivi, le librerie software usate, etc.

Per evitare problemi ricorrenti, nel corso del tempo sono si sono consolidate delle strategie di sviluppo che si sono dimostrate efficaci. Facciamo un rapido riepilogo storico per vedere come siamo arrivati alle metodologie che useremo in questo corso.

Nel 1970, Winston W. Royce era direttore del Software Technology Center della Lockheed Martin ad Austin, in Texas. Fu un pioniere dello sviluppo software, e in un suo celebre articolo descrisse le 5 fasi necessarie per la realizzazione di un prodotto software:

1. Analisi dei requisiti
2. Design
3. Implementazione (coding)
4. Testing
5. Manutenzione

Questo flusso divenne in seguito noto come waterfall. Con il passare degli anni e la prova sul campo, si è visto che queste 5 fasi sono teoricamente corrette, ma capitava troppo spesso che imprevisti di vario genere facessero rallentare o fermare del tutto il progetto.

I problemi divennero evidenti quando una celebre statistica del 1994, chiamata CHAOS Report, mostrò come il 96% dei progetti software analizzati non fossero stati completati fase hanno statisticamente un'alta percentuale di fallimento.

• Type 1: progetti conclusi con le funzionalità previste, nel rispetto del budget e dei tempi di consegna
• Type 2: progetti conclusi ma con meno funzionalità di quelle previste, o non rispettando il budget o i tempi di consegna
• Type 3: progetti abortiti durante lo sviluppo

Era evidente ormai che serviva qualche modifica a modello waterfall.

Dopo il CHAOS Report del 1994, un gruppo di consulenti software si è messo al lavoro per ragionare su nuove metodologie di sviluppo. I problemi identificati alla base degli insuccessi nello sviluppo software riguardavano soprattutto l'impossibilità di elencare tutti i requisiti all'inizio del progetto e considerarli immutabili, e i rapporti interpersonali all'interno del team e verso l'esterno.

Ci fu un incontro storico nella località sciistica di Snowbird, in Utah (USA) nel 2001, durante il quale pubblicarono il manifesto Agile, contenente i valori e principi che secondo loro dovevano essere alla base di un buon progetto software per avere le maggiori probabilità di riuscire.

Alla base delle metodologie Agile ci sono 4 valori fondamentali.

In ognuno dei valori, la parte a destra è importante, ma quella a sinistra è considerata più importante. Tutte le metodologie Agile si basano su questi valori, e compiono delle scelte significative di conseguenza.

Definire dei processi e degli strumenti aziendali è importante, ma non bisogna mai dimenticarsi che il software alla fine è sviluppato da persone che usano strumenti e processi, non dagli strumenti e processi da soli. Qualsiasi strumento usato male o controvoglia non può funzionare. Al contrario, un piccolo gruppo di persone può realizzare grandi risultati se c'è affiatamento e determinazione.

Sulla base di questo valore, quando qualcuno del team ha un problema ad usare uno strumento o a seguire un processo, bisogna cercare di favorire sempre la persona, e riadattare processi e strumenti di conseguenza.

Un prodotto software senza documentazione può essere difficile da mantenere, e questo è tristemente noto alla maggior parte degli utenti e sviluppatori. Tuttavia, un software che non funziona è impossibile da usare, con tutta la buona volontà, ed è quindi inutile. Nello sviluppo del prodotto quindi è preferibile concentrarsi maggiormente sul far funzionare il software rispetto a scrivere una documentazione perfetta e completa di qualcosa che non esiste.

Attenzione: quando qui parliamo di documentazione, intendiamo quella necessaria allo sviluppo interno del progetto, in altre parole quella interna all'azienda, e non la documentazione per l'utente finale. La documentazione finale può essere considerata parte integrante del prodotto, e va quindi realizzata e completata come tutto il resto del software.

I contratti firmati sono necessari per partire con un lavoro e accordarsi sui punti fondamentali, ma non devono essere una scusa dietro cui nascondersi. Se c'è qualche imprevisto e qualcosa sta andando storto, meglio avvertire il cliente il prima possibile e renderlo partecipe dei problemi, cercando una possibile soluzione. In ogni caso, mai rendere noti i problemi a ridosso della consegna, o peggio ancora inventare scuse.

Questo punto, similmente al primo, mette al primo posto le persone rispetto agli strumenti e alle carte. In questo caso però l'attenzione è rivolta verso l'esterno del team e dell'azienda.

La capacità di seguire un piano prestabilito è una delle caratteristiche fondamentali che distinguono uno sviluppatore professionista. Tuttavia i requisti del cliente cambiano, così come le situazioni all'interno dell'azienda, e gli imprevisti capitano continuamente. Un framework Agile deve incorporare strutturalmente la capacità di reagire ai cambiamenti e agli imprevisti, minimizzando problemi e danni.

Attenzione però a non esagerare dal lato opposto: se i piani cambiano troppo frequentemente, si arriva a quella che si può chiamare pianificazione isterica, in cui tutto cambia continuamente e non si arriva mai a destinazione. Un buon framework deve trovare il bilanciamento fra questi due aspetti.

Nella pratica, come facciamo a implementare questi valori?

Esistono varie proposte concrete, chiamate metodologie o framework, che sono nate nel corso degli anni. Le più importanti sono:

• Scrum[1990s]: uno dei primi framework, nato già prima della pubblicazione del manifesto; definisce piccoli team (dalle 5 alle 9 persone), cicli iterazione brevi (dalle 2 alle 4 settimane), e una chiara definizione dei ruoli.
• eXtreme Programming [1996]: molto orientato ai programmatori, si concetra sulla negoziazione continua tra sviluppatore e cliente, ha cicli di iterazione brevissimi (1 giorno), si basa sul pair programming e sul Test Driven Development
• Lean [2003]: è la trasposizione per lo sviluppo SW del Lean Manufacturing di Toyota, si focalizza sull’eliminazione dello spreco (waste) e cerca di ritardare le decisioni il più possibile

In questo corso noi approfondiremo il framework Scrum.

Scrum è un framework agile nato per lo sviluppo software, ma è attualmente usato anche per realizzare altri tipi di progetti non informatici.

Si basa su:

• piccoli gruppi di lavoro, dalle 5 alle 9 persone
• la divisione del ruolo tradizionale del product manager in più ruoli
• cicli di iterazione brevi, detti anche sprint, tipicamente due settimane

Ken Schwaber e Jeff Sutherland sono tra i fondatori di questo framework, negli anni '90, ed hanno partecipato alla scrittura del manifesto Agile nel 2001.

Noi applicheremo il framework Scrum a scuola, che è un contesto diverso rispetto a quello aziendale per cui è nato. Per questo motivo apporteremo alcune modifiche, in particolare il nostro team sarà composto da 3 studenti più il docente, come vedremo.

Il team scrum prevede che ad ogni membro del team venga assegnato un ruolo ben definito.

Tradizionalmente esisteva la figura del Product Manager che aveva molti compiti e responsabilità, tra cui:

• definire gli obiettivi e le scadenze
• assegnare le attività
• interfacciarsi con i livelli alti dell'azienda ed il cliente
• validare i requisiti
• decidere se gli obiettivi sono stati raggiunti
• fare da coach a tutti
• assicurarsi che siano seguite le linee guida aziendali

Tutte le altre persone del team erano sostanzialmente dei semplici esecutori, con poteri decisionali molto limitati.

Questo modello si è rivelato un fallimento, per motivi abbastanza evidenti: una singola persona non può avere né il tempo né tutte le capacità tecniche e relazionali richieste. Scrum vuole quindi suddividere questi compiti in più ruoli e più figure all'interno del team.

Fanno parte del team di sviluppo i programmatori che andranno effettivamente a realizzare e testare il codice.

Il team di sviluppo scrum si dice che si auto-organizza (self-organizing) perché ha le seguenti caratteristiche.

• decide autonomamente come dividersi il lavoro: i task non vengono assegnati ai singoli individui dall'esterno ma i membri del team si dividono i compiti tra di loro in autonomia
• decide autonomamente il tempo necessario ad implementare i singoli task
• può scegliere gli strumenti e le tecnologie da usare per raggiungere gli obiettivi, all'interno delle linee guida aziendali
• dimostra il lavoro realizzato al Product Owner per validazione ed accettazione

La responsabilità principale del Product Owner è che il prodotto rispetti le aspettative del cliente.

Nel dettaglio:

• definisce le funzionalità del progetto
• decide le date di rilascio ed il relativo contenuto
• responsabile del ROI (Return On Investment)
• può cambiare funzionalità solo oltre i 30 giorni
• accetta o rifiuta il lavoro del team

Il Product Owner non è equivalente al tradizionale Product Manager: ha infatti solo parte delle responsabilità di quest'ultimo. Inoltre non è il capo, dimenticatevi questa organizzazione gerarchica all'interno del team: tutti i membri sono pari, con ruoli e responsabilità differenti.

Lo Scrum Master deve assicurarsi che il team sia produttivo e che il metodo Scrum sia applicato correttamente.

In particolare:

• rimuove gli impedimenti, ad esempio computer rotti, licecnze mancanti, problemi burocratici, etc.
• si assicura che le regole scrum e le linee guida aziendali siano rispettate
• protegge il team dalle interferenze esterne (amministratore delegato invadente, clienti ansiosi, etc.)

Lo Scrum Master è un po' il vigile del team, che si assicura che tutto vada per il verso giusto. È la figura meno coinvolta nello specifico progetto, e non è raro che segua più progetti contemporaneamente o che sia esterno all'azienda.

Nel nostro caso, il vostro Scrum Master è il docente, che quindi avrà questo ruolo in tutti i team della classe.

Il ciclo di sviluppo Scrum è tipicamente di due settimane, al termine del quale si deve presentare un piccolo prototipo funzionante.

In altre parole, Scrum (ed in generale Agile) si concentra sul fatto che bisogna rilasciare il più frequentemente possibile dei prodotti che possano essere testati non solo dal team di sviluppo, ma anche dal cliente ed eventualmente dal cliente finale per ricevere feedback il prima possibile.

Volendo fare il classico paragone con la creazione di una macchina, in Scrum si sviluppa prima un triciclo, poi una bicicletta, poi un motorino, e così via fino ad arrivare al prodotto finale. Questo si contrappone al tradizionale metodo di sviluppare i componenti finali separatamente: prima il motore, poi la carrozzeria, le ruote, etc. In questo modo si può provare il prodotto (la macchina) solo alla fine del progetto. È abbastanza evidente quindi che il metodo Scrum è più adatto nei constesti in cui i requisiti sono incerti e mutevoli, mentre il metodo tradizionale dove si ha la ragionevole certezza che nulla cambierà durante lo sviluppo del prodotto. Nel mondo contemporaneo, tuttavia, quest'ultima situazione non accade praticamente mai.

Ogni ciclo di sviluppo in termine tecnico viene chiamato anche sprint.

Nel nostro contesto scuola, adatteremo la lunghezza dello sprint in base alle esigenze del calendario scolastico.

Il ciclo di sviluppo Scrum prevede i seguenti incontri:

• planning meeting, all'inizio dello sprint
• review meeting, alla fine dello sprint
• daily meeting, ogni giorno

Può esserci un ulteriore incontro chiamato "retrospettiva", dopo la review, dove si analizza cosa è andato bene e cosa male, e come migliorare.

Si decidono le storie ed i task da realizzare nello Sprint che sta iniziando.

Le storie sono la forma con cui si definiscono i requisiti in Scrum. Hanno un aspetto più informale rispetto ai requisiti classici, e si concentrano sulla narrazione del progetto, in modo tale che ogni progetto non sia solo un insieme di cose da fare ma acquisisca un senso chiaro e definito sia nelle menti sia del cliente che degli sviluppatori

Ogni storia ha la forma:

Come ogni storia che conosciamo, gli elementi fondamentali sono: i personaggi (qualcuno), l'azione (qualcosa) ed il fine che muove il personaggio all'azione (valore). Le storie devono essere scritte in modo che possano essere comprese da chiunque, quindi non devono contenere termini tecnici, perché sono il mezzo di comunicazione scritto privilegiato tra tutti i membri del team, dell'azienda e con il cliente.

Dopo aver definito le storie, queste vanno messe in priorità dal Product Owner. Si comincieranno ad implementare quindi prima le storie con priorità più alta.

Le storie solitamente, prima di essere implementate, devono essere suddivise in task operativi che contengono invece i dettagli su cosa in pratica deve essere fatto. I task possono contenere anche un linguaggio tecico, perché sono strumenti interni al team di sviluppo, di solito non escono fuori da quest'ambito.

Ad ogni storia o task vengono inoltre assegnati dei punti, che ne definiscono la difficoltà. Ad esempio:

• 1 punto: facilissimo
• 2 punti: facile
• 4 punti: impegnativo
• 8 punti: esageratamente impegnativo

Si preferisce assegnare punti e non ore alle singole storie, perché per gli esseri umani è molto più facile valutare la difficoltà di un compito che il suo tempo di esecuzione, e quindi alla fine la stima viene più precisa. Inoltre evita che si creeino situazioni di tensione, spesso inutili, nel caso in cui i tempi non vengano rispettati esattamente.

Ogni team ha un proprio numero di punti che riesce a completare in uno sprint, chiamato velocità (velocity). La velocity viene calcolata empiricamente dopo un certo numero di sprint. Per ogni sprint, si possono pianificare un numero di punti uguale o inferiori alla velocity fissata, mai un numero maggiore: infatti non è teoricamente corretto prevedere di fare straordinari già in fase di planning. Scrum insiste molto sul fatto che il ritmo di lavoro deve essere sostenibile, e che non bisogna fare continuamente sforzi oltre le proprie possibilità.

Ad ogni storia o task si assegna un proprietario (owner), in modo che sia chiaro chi è che ha la responsabilità che quella storia o task venga completata.

Le storie devono essere tra di loro quanto più possibili indipendenti, da eseguire in serie o in parallelo, ma non intrecciarsi fra di loro. Se questo accade, conviene spezzare le storie, per renderle indipendenti.

In questa fase ogni membro del team di sviluppo implementa le proprie storie o task. Quando comincia l'implementazione, lo sviluppatore segna il task o la storia in "Work in progress" nel cartellone del team o qualche altro strumento di tracciamento, anche digitale. Man mano che li completa, segna la storia o task come completato (done) e passa al successivo. Ad ogni momento, ognuno deve essere su un unico task.

Non è possibile cambiare i storie o task in questa fare, per nessun motivo, neanche da parte dell'amministratore dell'azienda o del cliente: è cura dello Scrum Master assicurarsi di questo.

Alla fine della fase di esecuzione, i vari owner dimostrano le storie e task che hanno completato al Product Owner, che valuta se sono effettivamente complete come si aspetta il cliente, o c'è qualcosa di incogruente e devono essere riviste. Quest'ultime devono essere sempre ri-pianificate nello sprint successivo e ricominciare il ciclo, non possono per nessun motivo essere "corrette al volo", perché in questo modo si perde facilmente il controllo della situazione.

Attenzione: non si possono dimostrare storie incomplete (non in done), anche se manca solo il 10%: una storia o è completa, o è fallita, nessuna via di mezzo. Una storia parzialmente completa si considera fallita e si rivaluta nella pianificazione successiva. Il Product Owner decide se le storie sono effettivamente complete o no.

Lo Scrum Master si assicura che tutto il processo sia eseguito correttamente.

C'è un ulteriore importante cerimonia Scrum che si celebra ogni mattina, il "Daily Meeting": è un incontro giornaliero di massimo 15 minuti, interno al team (gli esterni non possono partecipare), in cui ci si assicura che tutto stia procedendo come previsto. Visto che i partecipanti devono stare in piedi per favorire la concentrazione, viene anche detto "Stand-up meeting". Noi non faremo ogni giorno perché sarebbe molto difficile da eseguire nel contesto scolastico, ma vediamo se riusciamo a inserirlo in qualche occasione.

In questo capitolo vedremo come progettare un'applicazione software in modo che si abbia la ragionevole certezza che soddisfi effettivamente le necessità del cliente.

Se ancora non si hanno le idee chiare su cosa si deve realizzare, è utile fare una fase di brainstorming.

Il termine brainstorming è spesso abusato, ma identifica invece un insieme di regole e tecniche ben definite che servono a massimizzare l'efficacia dell'incontro.

L'obiettivo in questa fase è di far emergere la maggior parte di idee da parte dei partecipanti. Non è fondamentale che siano effettivamente realizzabili: questa valutazione di fattibilità sarà un passo successivo.

È importante notare anche come il brainstorming sia consultivo e non decisionale. Non avrebbe senso far terminare l'incontro con delle decisioni definitive; al contrario è utilissimo per chi dovrà fare il design avere una base di idee su cui lavorare.

Ci sono vari modi per implementare un incontro di brainstorming. Noi prendiamo in prestito quella utilizzano in Google, come descritta in questo articolo.

Ci sono 4 principi fondamentali da tenere sempre a mente:

• concentrarsi sulla quantità, non sulla qualità: tirare fuori tutte le idee che vengono in mente
• limitare le critiche: sia quelle alle proprie idee che quelle degli altri
• strane idee sono OK: vanno bene anche idee che all'inizio possono sembrare assurde, non si sa mai cosa può saltare fuori dopo un po' di riflessione
• combinare: va bene combinare le idee fra loro, anche di persone diverse

Tenendo a mente i principi qui sopra, si può realizzare in pratica un brainstorming come segue:

• 10 minuti: ognuno scrive le proprie idee in una lista su carta; è fondamentale carta e penna in questo momento, perché è dimostrato che aiutano la concentrazione e la fantasia
• 2 minuti: ognuno seleziona 2 delle proprie idee, che gli sembrano migliori
• a turno ognungo espone le proprie 2 idee agli altri, e dopo breve discussione si segnano su una lavagna
• alla fine si effettua una votazione su quali idee sembrano migliori al gruppo.

Come dicevamo all'inizio, il brainstorming non è decisionale, quindi non "vince" l'idea con più voti. Però, chiaramente, le idee di maggiore successo saranno quelle prese più in considerazione dai responsabili del progetto.

Una volta che si hanno le idee chiare su cosa deve fare il progetto nel suo complesso, è il momento di scrivere il primo documento prescrittivo su cui si baseranno tutti gli altri.

Con prescrittivo si intende un documento che deve deve essere rispettato, e su cui non si può andare in deroga. In altre parole è una "fonte di verità", e in caso di contraddizione tra documenti, ha priorità il documento con valore prescrittivo.

Il brief è un documento tipicamente abbastanza breve che deve contenere i risultati attesi dal punto di vista business. Non si concentra su come il progetto deve essere implementato, ma su cosa deve fare e a chi è rivolto. Il brief sarà il documento a cui ci si riferirà sempre in caso di indecisione su una scelta di design o di implementazione.

Per noi, deve contenere almeno le seguenti informazioni:

• obiettivo: una frase preliminare, in cui si cerca di identificare l'ambito del progetto ed eventualmente i suoi punti di forza e unicità
• destinatari: a chi è rivolto, in base alla pertinenza si può specificare l'intervallo di età, la professione, l'area geografica, etc.
• sintesi: una descrizione più lunga in cui si descrive meglio l'ambito del progetto, il problema dei destinatari, la soluzione proposta a tale problema, i punti di forza di questo progetto
• dispositivi di riferimento: è importante qui specificare anche con quali dispositivi e piattaforme si è interessati: desktop, tablet, smartphone, smartTV, Chrome, Safari, Explorer, etc.

Altre informazioni utili che si possono aggiungere al brief sono il background del progetto e le motivazioni. In generale si può aggiungere tutto quello che si pensa potrà essere utile in fase nelle fasi successive.

Si consiglia di usare il tempo presente, e non futuro, perché come ce lo porteremo per tutto il tempo del progetto.

Sito per organizzare eventi aziendali. I destinatari sono i dipendenti dell'azienda. Il sito permette di creare eventi da parte dei dipendenti, e poter dare la propria adesione o manifestazione di interesse ad eventi creati da altri. Il dispositivo di riferimento è lo smartphone.