Tutti gli articoli di michele.ferracin

Sulla costruzione di una squadra, ep. 1

-“Fissiamo già la prossima data!”

-“Sì sì sono d’accordo. Apriamo i calendari e decidiamo data e argomenti della prossima volta.”

L’entusiasmo era palpabile, persino quello dell’amministratore che si è prestato come moderatore nella nostra prima revisione tecnica. Non mi aspettavo un tale successo e invece la nostra prima attività vera di gruppo si è svolta alla grande.

La quotidianità stava per minare lo svolgersi di questo esperimento e farlo rimandare ma l’abbiamo scampata. Abbiamo scoperto quanto già in una prima e rudimentale versione di revisione di gruppo formale sia rapido lo scambio di conoscenze tecniche e di dominio del problema che si va ad analizzare. Quante cose ognuno di noi dia per scontate rispetto agli altri e viceversa. Quanto ci manchino linee guida, procedure e tecniche per rendere più snello il nostro lavoro e per renderlo il più coerente possibile all’interno della squadra.

Anche le persone stesse riservano grandi sorprese perché a fare il ruolo dell’autore è stata la persona che meno mi sarei aspettato ed è successo spontaneamente! Ha scelto autonomamente un pezzo di software da lui costruito e l’ha sottoposto all’esame della squadra senza alcun risentimento con la totale volontà di mettersi in gioco e crescere insieme.

 

Sfida accettata

Girando per vari blog ho trovato questo estratto sulle finestre modali / pop-up.

It’s not that users are morons or that they “forget” to think. It’s that users are trained to not think. Users very quickly learn from experience that:

  • Dialog boxes are modal. But users do not think of them as “modal”, they think of them as “preventing me from getting any work done until I get rid of them.”
  • Dialog boxes almost always go away when you click the leftmost or rightmost button.
  • Dialog boxes usually say “If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No”
  • If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen — in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

In short, from a user perspective, dialog boxes are impediments to productivity which provide no information. It’s like giving shocks or food pellets to monkeys when they press buttons — primates very quickly learn what gives them the good stuff and avoids the bad.

Come non essere completamente d’accordo!

Che strategie possiamo adottare per evitare di ricadere sempre nelle dialog-box / finestre pop-up?

Jeff Atwood suggerisce:

Well designed software avoids asking the user questions by…

Anticipating user needs (wizards, templates, autocomplete, IUI).
Remembering past preferences and using that to better anticipate future needs.
Silently and automatically protecting the user from the consequences of any negative actions (versioning, undo).

Inoltre suggerisce anche di porsi come obiettivo di realizzare una UI completamente senza dialog box. Sfida accettata!

vgufowbwbkzie

Vittoria

Un genio ti credevi
e mete altissime
di raggiunger speravi.

“Mi basta un’occasione
(ti vantavi) per fare
un balzo avanti, colossale…”

Ora il dubbio ti assale:
passati son molti anni,
con vani sogni, ahimè,
te stesso inganni.

Se avanzare tu vuoi
è il presente che conta.
Afferralo, e spremine
tutto quello che puoi.

– Herbert Kauffman

 

Fare giusto VS fare in fretta

Sappiamo tutti come ci si sente.

Inizia un progetto nuovo.

La possibilità di riscattarsi dalle schifezze del passato profuma di carta stampata. Vuoi dare il meglio e questa è la volta buona. I compromessi saranno pochi e ben calibrati.

Il mondo reale è inesorabile e pretende che tu consegni in quella fatidica data. Al cliente non interessa se hai usato MVC, ASP, SQL, Ruby, Perl o un rito voodoo. Basta che vada e che costi poco e sia facile da usare. Basta che la sua azienda possa fatturare e che nella sua carta di credito ci sia sempre disponibilità per fare il pieno alla sua Porsche Cayenne nera con cerchi di dimensioni improbabili e finestrini oscurati.

Ti senti un po’ sotto pressione e nella testa i neuroni che tifano per “fare giusto” e quelli che tifano per “fare in fretta” cominciano a scontrarsi. Allora qualche pezzo di codice ti scappa ma ti prometti che una volta consegnata una prima versione base tornerai indietro e sistemerai quel taccone e farai le cose fatte bene.

Quella promessa che ti sei appena fatto si fa chiamare debito tecnico intenzionale. Come i debiti finanziari, anche quelli tecnici hanno gli interessi. Adesso l’hai scampata andando veloce; loro però cammineranno inesorabili e, quando non avrai più il fiato per andare veloce, ti raggiungeranno e ti presenteranno il conto.
E, a quel punto…

Sulla costruzione di una squadra, prequel

In una stanza ci sono un fanboy Microsoft, uno Linux e due Apple.
La loro età media è di 25,75 anni. Ogni mattina si svegliano e cercano di battere i tasti e girare la rotellina del mouse più velocemente del giorno prima. Perché hanno voglia di fare, perché si sentono orgogliosi quando qualcosa funziona come dovrebbe e si sentono importanti a risolvere problemi dei clienti.

imagesDDGZ13FS

L’entusiasmo è la strada giusta ma intuiscono che digitare velocemente non è tutto. Intuiscono che serve qualcosa per diventare una squadra migliore.

Ed è così che decidono insieme di iniziare un percorso per capire come essere più veloci dei bug che riempiono le caselle e-mail e fanno suonare il telefono.

Non hanno ancora iniziato, presto lo faranno: agosto con le sue ferie dilata i tempi ma settembre porta con se i nuovi inizi, i nuovi propositi (un po’ come quelli per l’anno nuovo). Li vedo già curiosi e desiderosi di capire cosa potranno diventare, di guardarsi indietro tra un anno e dire “quanta strada abbiamo fatto!”.

Revisioni Tecniche Formali

Non sarebbe fantastico se esistesse un metodo per trovare circa il 60% dei difetti dei nostri software, che accorciasse i tempi di sviluppo e che quindi riducesse i costi? La bella notizia è che esiste! Questo metodo si chiama Revisione Tecnica Formale (formal inspection se vogliamo usare il gergo in inglese). È stato sviluppato da Michael Fagan all’IBM e molti studi di settore ne confermano ormai l’efficacia.

Questo tipo di revisione è efficace perché si distingue da altri metodi grazie a delle regole ben precise:

  • Utilizzo di checklist per concentrare i revisori su aree che hanno avuto problemi in passato;
  • Le revisioni hanno lo scopo di trovare difetti, non correggerli;
  • I revisori si preparano prima della riunione e partecipano con una lista di problemi da loro individuati;
  • I partecipanti hanno ruoli diversi;
  • Il moderatore della revisione non è l’autore del prodotto esaminato;
  • In ogni revisione vengono raccolti dei dati che serviranno anche per migliorare le future revisioni;
  • La dirigenza non partecipa a questo tipo di riunioni.

I ruoli

Moderatore

È il responsabile dell’andamento della revisione. Deve farla procedere a un ritmo sostenibile ma non troppo veloce, in maniera da trovare più errori possibili.

Autore

La persona che ha scritto o progettato il lavoro in esame. Svolge un compito di secondo piano in queste attività perché il codice revisionato dovrebbe “parlare da solo”. Il suo compito può essere chiarire punti oscuri.

Revisore

Chiunque ha un diretto coinvolgimento nel codice ma non ne è l’autore. Di solito il revisore trova i difetti in fase di preparazione.

Segretario

Compila il verbale della revisione registrando gli errori trovati e le assegnazioni delle attività che ne seguiranno.

Il Processo

1018px-Fagan_Inspection_Simple_flow.svg

Pianificazione

L’autore consegna il materiale al moderatore. Il moderatore decide chi parteciperà, chi revisionerà il materiale e dove.

Introduzione

Quando i revisori sono un po’ estranei al progetto in revisione, l’autore può fare un’introduzione. Questa può essere pericolosa perché potrebbe condizionare i revisori: il prodotto dovrebbe parlare da sé, non il suo autore.

Preparazione

Ogni revisore lavora in autonomia per trovare difetti con l’uso di checklist.

Riunione

Il moderatore sceglie un revisore e gli fa spiegare il codice. Tutta la logica viene spiegata, ogni ramo di ogni struttura logica. Il segretario registra gli errori quando vengono rilevati, la discussione si ferma quando un errore viene riconosciuto come tale. Il segretario annota il tipo e la severità dell’errore e la riunione prosegue. Se si accende la discussione il moderatore riporta all’ordine. Non si discutono soluzioni. La riunione dovrebbe durare meno di due ore.

Report

Entro un giorno dalla riunione il moderatore produce un report (e-mail o equivalente) che elenca ogni difetto, il suo tipo e la severità. Il report serve a garantire che ogni difetto venga corretto e per sviluppare una checklist che evidenzi problemi specifici nell’organizzazione. Si raccolgono dati sul tempo impiegato e sul numero di errori trovati nell’unità di tempo per misurare l’efficacia delle revisioni.

Rilavorazioni

Il moderatore assegna i difetti a qualcuno, molto spesso l’autore, per risolverli.

Follow-Up

Il moderatore è responsabile della verifica che il lavoro assegnato venga svolto. A seconda della gravità dei difetti corretti potrebbe (o no) seguire a lavoro ultimato un’altra revisione formale.

Non ho mai partecipato a revisioni di questo tipo ma ho la fortuna di lavorare in un ambiente dove siamo tutti aperti alle migliorie e ai cambiamenti e ne abbiamo già pianificata una tra qualche giorno. Presto faremo la prima revisione formale pilota e non vedo l’ora di toccare con mano tutti i vantaggi che finora ho solo letto studiando questo tipo di procedura. Sono sicuro che da qui a sei mesi avremmo fatto passi da giganti!

 

Noi non siamo gli utenti

Lì! Clicca lì! No, più a destra… più a destra… Clicca sul pulsante di scelta… Il pallino vuoto… (Pianta il dito sullo schermo) Ecco, qui devi cliccare.

Il miglior modo per sapere come pensa un utente è osservarlo. Chiedete a un utente di svolgere un compito “della vita reale” su un pezzo di software che state sviluppando, prendete i pop-corn, osservate e godetevi la scena.

È uno spettacolo perché nel giro di pochi secondi verranno smontate le vostre ipotesi di partenza con cui avete progettato l’UI.

Utente prende posto nella postazione a appoggia la mano sul mouse. Fissa lo schermo per qualche secondo come chiedendosi che roba è mai questa?

michael-scott3
Utente che usa il vostro programma per la prima volta

Legge qualche parola qua e là e poi proverà a fare ciò che gli avete chiesto. A questo punto vi state già accorgendo che Utente sta usando il programma in modo decisamente diverso da come l’avete immaginato. Crescerà in voi una fortissima tentazione di correggerlo, di guidarlo: la sofferenza che provate nel vedere che un’operazione da cinque secondi, per voi che avete sviluppato il programma, ci sta impiegando quasi mezzo minuto è insopportabile. Ecco allora che intervenite e dite qualcosa tipo la frase di apertura del post.

 

Quando Utente si bloccherà la prossima volta, sperando che non sia per un bug, usate le mani per prendere i pop-corn dal secchio che avete predisposto prima e riempitevi la bocca per non parlare. Probabilmente noterete che il suo sguardo si concentrerà sul punto dove è rimasto bloccato, senza andare a cercare aiuti in altri parti dell’interfaccia. Questa è una ragione del perché i menù di aiuto sono una scelta poco efficace. Le istruzioni di aiuto/messaggi di errore dovrebbero essere posizionati il più vicino possibile alla zona interessata dal problema.

RadGridView_Validation_030
Messaggio di aiuto ben posizionato.

Gli utenti usano il software intuitivamente, senza ragionare nel dettaglio. Trovano un modo che funziona per fare una cosa, anche se improprio, e poi la faranno sempre così. È meglio fornire un solo modo per fare un’operazione: il più ovvio possibile.

Tutto ciò accade perché gli utenti non passano tutto il tempo che passiamo noi al computer e, se lo fanno, è per scopi completamente diversi dai nostri. Noi usiamo il computer per il gusto di farlo: con talmente tanto gusto che il nostro mestiere che ci siamo liberamente scelti è far fare al computer ciò che vogliamo, plasmarlo al nostro volere, dominarlo. Un impiegato in ufficio invece subisce l’uso del computer: il suo lavoro è fatturare, inviare ordini ai fornitori, spostare materiale in un magazzino. Magari il computer anche lo odia, ha problemi di vista e soprattutto ragiona con schemi mentali completamente diversi da quelli che noi programmatori usiamo mille volte al giorno.

 

Rispetto del codice

Quella roba l’ha scritta Giovanni, io non la tocco! Problema suo!

Pranzando con altre persone del settore IT di altre aziende spesso sento dei “capi programmatori” che si lamentano dei loro sottoposti perché si concentrano solo sulla loro parte di codice e quando vedono errori di altri sono pronti a puntare il dito.

Non conosco nel dettaglio come mai succedano queste dinamiche in alcuni gruppi di lavoro; tuttavia penso che siano sintomo di una errata gestione delle persone, di scarsa stima e rispetto reciproco.

Credo che dovremmo aver un rispetto inteso in senso lato del codice su cui lavoriamo: per noi stessi e per i nostri compagni di team. Tutti sappiamo quanto facile sia commettere errori. In teoria potremmo, per esempio, impegnarci per lasciare il sorgente sempre un po’ migliore di come lo abbiamo trovato, prima di eseguire git push.

Cosa succederebbe se seguissimo questa semplice regola? Cosa succederebbe se ci impegnassimo a migliorare il codice, anche di poco, indipendentemente da chi sia stato l’autore originale?

Io penso che porterebbe a un sistema poco a poco sempre migliore, porterebbe a creare un intero team che ha a cuore il sorgente nella sua completezza invece di individui che tengono solamente alla loro piccola fetta…
Prendersi cura del proprio codice è un discorso. Invece, i membri di un team coeso si aiutano e si correggono a vicenda.

P.S.: A proposito di git push, un collega ha appeso questa sulla nostra lavagna

in case of git
In caso di incendio salvare il salvabile!

Atteggiamento

Quando uscite di casa, alzate il mento, su la testa, respirate profondo, bevetevi la luce del sole. Salutate gli amici con un sorriso e mettete l’anima in ogni stretta di mano. Non abbiate timore di venire fraintesi e non sprecate nemmeno un minuto a pensare ai vostri nemici. Chiaritevi bene in mente quello che volete fare e poi andate alla meta senza esitazioni. Pensate alle cose belle e positive che volete fare, un giorno, e l’occasione per coronare i vostri sogni vi si presenterà senza che neppure ve ne accorgiate. Come un animaletto del corallo succhia elementi vitali da una marea che passa e va. Immaginate nella vostra mente la persona onesta, leale, nobile che vorreste essere e cercate di somigliarle il più possibile… Il pensiero è il più forte. Conserva un corretto atteggiamento mentale, portato al coraggio, alla franchezza, alla gentilezza d’animo. Pensare nel modo giusto è già fare. Tutto proviene dal desiderio e le preghiere sincere non sono mai vane. Perseguiamo serenamente le nostre mete. Alzate il mento, su la testa. Gli uomini sono degli dei in crisalide.

– Elbert Hubbard