Non sarebbe stato normale avere un progetto senza intoppi, anche se i ragazzi hanno sempre assunto un buon comportamento, sia per quello che riguarda le metriche, sia per il lavoro svolto. Non è da sottovalutare la particolarità del momento. La necessità di prepararsi alle prove che hanno in questo momento dell'anno scolastico, le varie simulazioni e la preparazione del materiale d'esame possono portare anche ad una perdita di focus generale.
I ragazzi non sono a tempo pieno su Agile@School, quindi le loro priorità possono essere spesso variabili.
Però, un impegno è un impegno, e poi, per molti di loro, Agile@School diventa anche il materiale che servirà loro nelle giornate di esposizione orale all'esame. Quindi, una correzione, dopo questo sprint "in calo" era d'obbligo, sia da parte dello Scrum Master, sia da parte del sottoscritto, in qualità di coach, e quindi, di riferimento principale, soprattutto sul comportamento di crescita necessario del team. E non siamo stati molto "morbidi", proprio per far capire l'importanza del lavoro che stiamo facendo tutti.
Oggi non è stata una giornata felice per nessuno di noi, perché sono emersi i primi fallimenti. Ma senza questo punto di incontro di certo non si sarebbe raggiunta nemmeno l'ondata di ottimismo successiva, e nessuno avrebbe ripreso la "voglia di ripartire" per rimediare.
Ma perché dopo cinque incontri così positivi, ora parliamo di fallimenti?
Perché tramite essi ripartiremo e chiuderemo tutto alla grande, perché ho una grande fiducia in chi mi aiuta (la prof e Gabriele) e in chi sta lavorando per cogliere il valore aggiunto che questo progetto dà. Probabilmente, parte dei problemi è fisiologico, per i motivi di cui sopra e per una flessione normale che si ha nei processi di migrazione culturale. E non è tutta colpa di chi ha lavorato sul software. A volte, anche noi "dall'alto" sbagliamo, e sta a noi risolvere tali situazioni di stallo.
Quali sono stati i fallimenti?
Se vi ricordate, nel precedente post, abbiamo parlato di come presentare il lavoro, motivo per cui parte del team si è concentrato a creare presentazioni di business, manuali utente e tecnici. Nella fattispecie, abbiamo affrontato i seguenti topic: - Testing
- User's manual
- Technical documentation
- Business presentation (vorrei far capire l'importanza di presentare bene un progetto)
- Grafica e design (logo, colori, temi, brand, ecc.)
Testing
Il primo punto è quello che, purtroppo come spesso accade, ha fatto emergere maggiormente la scarsa qualità del lavoro in termini di funzionalità. Il distacco maggiore si è verificato soprattutto tra gli Acceptance Criteria e l'effettiva implementazione. Il 90% della frustrazione sta qui. I test sono falliti tutti, o quasi, e i bug creati sono proprio tanti. Il motivo? si sono letti con poca attenzione di PBI e i criteri. Come mai? Ragazzi non abituati a farlo, semplice. Problema di facile risoluzione.
Comunicazione interna al team
Nonostante la stesura di un manuale tecnico, di un manuale utente e di una presentazione di business siano tra loro collegati da un punto di vista di immagine (logo, colori, brand, temi, ecc.) nessuno, all'interno del team, si è posto il problema di condividere in un solo momento gli stili, l'idea di grafica di insieme. Risultato? Tanti contenuti un po' disordinati e poca uniformità nella presentazione. Il motivo? Stiamo parlando di due classi quinte differenti, che hanno avuto la possibilità di collaborare fisicamente nello stesso posto insieme troppo poco tempo. Come mai? Si è lavorato solo a scuola. Anche questo è un problema di facile risoluzione, investendo tempo insieme (anche online) al di fuori delle ore in classe.
Comunicazione con il team
Abbiamo slack, un toccasana per il lavoro in collaborazione. Eppure, sembra non essere utilizzato o, quanto meno, capito. Il motivo? Nonostante questi ragazzi siano sempre sullo smartphone, hanno percepito slack come un tool "da computer" e non si sono (alcuni) nemmeno posti il problema di cercare l'app sul proprio cellulare. Strano, ma vero. Alcuni ragazzi propongono watsapp, ma è troppo dispersivo. Chi ha usato slack bene in questi ultimi tempi, convincerà ed allineerà i "ritardatari". Problema quasi risolto, ma la correzione è stata necessaria.
Utilizzo dello strumento
Risulta tangibile il calo di attenzione sulla gestione dei task su Visual Studio Team Services. Stati errati, comunicazioni del progresso del lavoro frammentate. Il motivo? non è stato percepito a fondo il vero valore aggiunto di un software di team working. Come mai? maturità dei ragazzi, inesperienza, errori da parte del sottoscritto (sottovalutazioni). Il problema è da risolvere, ma probabilmente gli esempi più concreti fatti in questo incontro, potrebbero aver aperto gli occhi agli studenti. Ho preferito spiegare cosa succede pragmaticamente a tutti se non si usasse. Speriamo si possa definire almeno parzialmente risolto. Queste dinamiche non sono semplici da implementare nella mente di uno studente così giovane.
Conclusioni
Ad una prima lettura, si può pensare che sia tutto andato male. Al contrario, vedo tante cose positive. Ad esempio, il fatto che un processo di test sia già attivo, proprio QA, con tanto di test case, che si basano su user story scritte a puntino. In quanti possono dire di avere realmente processi ripetuti o team dedicati alla QA o anche solo momenti di test funzionale approfondito? In quanti investono sui processi che migliorino la qualità? E parlo di aziende, non solo di scuola.
Ma non è solo questo, è stato utilizzato uno strumento per la collaborazione (Slack) fin dall'inizio. E ogni lavoro è gestito da canali, da pin di elementi importanti, da video condivisi e da integrazioni con software esterni (wunderlist, dropbox, ecc.).
Ed infine, certo, ci sono problemi nel capire realmente l'utilità della gestione del lavoro con VSTS, ma esso è presente in tutta la scuola, sia per la parte di controllo del codice sorgente, sia per la gestione (da questo progetto in avanti) del teamworking.
Insomma, quello che voglio dire è che i problemi su processi esistenti sono risolvibili, mentre se un processo manca, si è in alto mare. Per questo confermo la mia visione. Finalmente abbiamo avuto problemi, che risolveremo e che ci daranno nuovi stimoli, per ripartire spediti verso l'esame!
Chiudo con una frase emblematica sul fallimento, di Michael Jordan: "I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times, I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed."
Stay tuned!
