Le cose cambiano molto rapidamente. Quando Moze ha iniziato a essere un'agenzia web, organizzavamo il nostro lavoro in base alle attività (Basecamp era un'ottima lista di controllo all'epoca).
Quando siamo passati dalla realizzazione di semplici siti web all'assistenza a startup e aziende per la costruzione di prodotti digitali, abbiamo fatto alcuni tentativi ben intenzionati ma sbagliati per organizzare il nostro lavoro implementando Scrum e successivamente Kanban, nessuno dei quali era adatto a noi. Il primo era troppo complicato per uno studio piccolo come noi, il secondo non ci aiutava a stabilire scadenze chiare.
Così abbiamo fatto quello che fa qualsiasi team che sperimenta una teoria: ci siamo adattati. Abbiamo creato il nostro framework di sviluppo agile, ispirato principalmente a Scrum.
La descrizione che segue è ciò che abbiamo scoperto essere il modo migliore per organizzare il design e il lavoro tecnico di un piccolo studio di circa 10-12 persone che progetta e costruisce il front-end dei prodotti software.
Fase 1: capire le cose
Mi piace il modo in cui Ryan Singer di Basecamp identifica due fasi principali per il lavoro di progetto: configurare le cose e realizzare le cose.
Ogni lavoro ha due fasi. Innanzitutto c'è una fase di “salita”*, in cui si definisce il proprio approccio. Si ha un'idea di base del compito, ma non si è ancora capito come sarà la soluzione o come risolvere tutte le incognite.
Poi, dopo aver esplorato ciò che funziona e ciò che non funziona, si raggiunge un punto in cui non ci sono più problemi irrisolti. È come stare in cima alla collina. Si riesce a vedere chiaramente fino all'altro versante. La fase di discesa riguarda solo l'esecuzione.
- Ryan Singer
1. Mappare
Nella fase ascendente conosciamo il nostro cliente, i suoi obiettivi e vincoli, le metriche chiave dell'azienda e i lavori precedenti. Cerchiamo poi di capire cosa costruire (lo scopo del lavoro) utilizzando una tecnica Agile chiamata User Story Mapping: un modo per descrivere le caratteristiche dal punto di vista dell'utente finale.
Questo permette a tutti i membri del team di essere allineati sugli obiettivi e sulla portata e di essere coinvolti nella conversazione fin dall'inizio.
Una volta mappata l'esperienza dell'utente finale, di solito costruiamo un prototipo statico (InVision va benissimo). Questo può essere fatto utilizzando tecniche di co-design con il cliente o eseguendo un Design Sprint - un processo di cinque giorni per testare una nuova idea.
2. Prototipare e intervistare gli utenti
Un prototipo fornisce a tutto il team un'idea chiara del lavoro da svolgere, riducendo al minimo le cecità. Inoltre, facilita la stima sia per i progettisti che per gli sviluppatori.
A questo punto, di solito testiamo il nostro prototipo con un certo numero di potenziali utenti, alla ricerca di eventuali problemi di usabilità, prima di iniziare qualsiasi sforzo di sviluppo.
Organizziamo il lavoro di sviluppo in sprint - un periodo di tempo fisso di due settimane con un team fisso di designer e sviluppatori (uno sviluppatore a tempo pieno e un designer part-time di solito vanno bene per i nostri progetti).
Anche i contratti con i nostri clienti sono organizzati in sprint, il che consente un maggiore margine di manovra e una trasparenza totale sul nostro lavoro in un singolo sprint, che viene illustrato ai nostri clienti in dettaglio ogni due settimane.
3. Stimare e pianificare
Con il prototipo, la Story Map e i punti storia stimati, possiamo poi fare un piano di rilascio. Per esempio, se un insieme di caratteristiche (identificate come release) si aggira intorno ai 32 punti storia - e sappiamo che il nostro team può bruciare otto punti per sprint (la cosiddetta velocity in agile) - possiamo prevedere che avremo bisogno di quattro sprint per completare quell'ambito di lavoro.
Questo funziona anche per i rilasci incrementali, anche se tendiamo a evitare di fare una pianificazione dettagliata per più di due mesi di lavoro pianificato.
Fase 2: fare le cose per bene
Tra la fase 1 e la fase 2 di solito conduciamo un'analisi tecnica sulla tecnologia e sull'architettura generale del software - poiché il nostro lavoro si concentra principalmente sul front-end, questo viene fatto in collaborazione con il team tecnico del cliente.
1. Sprint di setup
Quando tutto è pronto, il nostro team inizia a lavorare in sprint. Chiamiamo il primo sprint “sprint di setup”, perché prepariamo i nostri ambienti di sviluppo con la tecnologia selezionata (librerie di sviluppo front-end, test, routing e navigazione di base).
Le storie utente della Story Map vengono importate in un backlog di Trello. Alla fine di uno sprint diamo al cliente una demo dettagliata di ciò che abbiamo fatto e discutiamo l'ambito dello sprint successivo. Ogni colonna dello sprint in Trello viene riempita finché non corrisponde alla nostra capacità di velocità prevista.
Sprint dopo sprint iniziamo ad affrontare piccoli pezzi del software uno per uno, seguendo l'esperienza lineare dell'utente finale descritta nella Story Map iniziale (da sinistra a destra).
2. Sviluppo incrementale
Alla fine di ogni sprint abbiamo del software funzionante da provare e puntiamo a zero difetti noti. In ogni sprint preferiamo impegnarci su meno cose piuttosto che finire per tralasciare delle funzionalità (cioè non consegnare alla fine dello sprint); questo tende a mantenere alta la motivazione del team, evitando tensioni di qualsiasi tipo.
Quando le cose sono quasi pronte per il primo rilascio, di solito organizziamo con il nostro cliente una beta su invito e aiutiamo a raccogliere il feedback degli utenti utilizzando strumenti come Google Form o organizzando interviste.
3. Misurare
Per capire l'impatto del design, o della riprogettazione di un prodotto esistente, di solito aiutiamo i nostri clienti a implementare il tracciamento degli eventi con Google Analytics e i cruscotti con Google Data Studio per avere report in tempo reale dei principali indicatori di performance, di solito costruiti intorno a alle categorie AARRR (Acquisition, Activation, Retention, Referral, Revenue).
Con questo modo semplice ma efficiente di organizzare il lavoro del software abbiamo progettato e sviluppato con successo il front-end di diverse applicazioni web e mobili.
Dai un'occhiata ad alcuni dei nostri lavori recenti in cui abbiamo applicato questo principio.
Rataran - App web (Vue.js)
Rataran valorizza i trader più competenti e offre loro visibilità e prestigio nel mondo della finanza, premiando i metodi di trading più performanti.
Talent Garden — App mobile per iOS e Android (React Native)
Talent Garden è la piattaforma di innovazione digitale e la rete di coworking leader in Europa con 23 campus in 8 paesi.
Wanderio - Android app mobile (React Native)
Wanderio è un'applicazione web che completa la vostra esperienza di viaggio online, confrontando diversi mezzi di trasporto (tra cui voli, treni e servizi di trasferimento da/per gli aeroporti) e classificando le alternative per permettervi di scegliere e prenotare la soluzione più adatta a voi.
