Beyond Sprint 0: un'alternativa per l'integrazione dei team

Scrum è la metodologia di project management più popolare al mondo con oltre il 72% dei team che utilizzano Scrum o uno Scrum Hybrid. È probabile che se lavori nello sviluppo web stai usando Scrum in qualche modo.

Una tendenza attuale in Scrum è lo "Sprint 0" o il suo cugino più artistico il "Design Sprint". Molto è stato scritto sul fatto che questi siano veri sprint (non lo sono), ma meno è stato detto sul perché esistono in primo luogo, perché rimangono così ostinatamente in giro e quali alternative esistono.

Personalmente amo Scrum e sono sempre alla ricerca di modi per migliorare in modo incrementale il modo in cui lo implemento. In questo articolo, vorrei condividere i metodi che ho incorporato nel mio flusso di lavoro e uno che trovo utile per unire UX/UI e sviluppo, oltre a creare visioni di progetto più forti.

Alcune rapide definizioni prima di iniziare:

• Sprint 0
  Lo sforzo iniziale di un team per creare i documenti guida richiesti per i progetti Scrum: una visione, un product backlog e stime di rilascio del prodotto.
• Sprint di progettazione
  Lo sforzo iniziale di un team per creare un progetto guida per il resto del rilascio.
  

Perché Sprint 0 e lo Sprint di design esistono

Va bene dire: "Sprint 0 non è un vero sprint, non farlo". Ma questi adattamenti sprint esistono per una ragione. Molti team li adottano perché il loro progetto ha un'esigenza insoddisfatta che va oltre l'ambito immediato di Scrum. La mia osservazione è che lo Sprint 0 e gli sprint di design sono spesso usati per affrontare le seguenti situazioni:

1. Mancanza di una forte visione guida;
2. Mancanza di integrazione del design nel flusso di lavoro di sviluppo.

Il processo Scrum presuppone che una visione chiara sia stata sviluppata e comunicata dal Product Owner. Ma alza la mano se hai lavorato su progetti in cui la visione è debole, sbagliata o invisibile. Anch'io! Sprint 0 è un tentativo del team di sviluppo di colmare il vuoto visivo. Non è l'idea peggiore, quindi qual è il problema? Da una prospettiva agile, Sprint 0 non è iterativo, non utilizza i talenti dell'intero team e fornisce risultati nebulosi. E prima che tu faccia notare: "Ehi, il vero problema qui è che i team di Scrum non dovrebbero dover fare il lavoro del Product Owner", in realtà credo che un team agile interdisciplinare sia uno dei migliori ambienti per sviluppare un visione e obiettivi.

Propongo un metodo più agile per costruire una visione che ho utilizzato con successo in progetti senza trasferimento. Esplorerò entrambe le situazioni in cui vengono utilizzati questi adattamenti simili allo sprint e descriverò come questo primo sprint alternativo supporta meglio il flusso di lavoro agile.

Visione e il prototipo Sprint

Nella prima situazione, dove manca una visione forte, la documentazione o le idee guida sono troppo deboli per iniziare veramente un progetto Scrum. Per qualsiasi processo (incluso Scrum), hai bisogno di indicazioni prima di iniziare il viaggio. Agile è ottimo per capire il modo migliore per raggiungere un obiettivo, ma generare la visione iniziale non rientra nel suo scopo. In effetti, in Scrum manca del tutto una descrizione della visione richiesta per l'inizio del processo di sviluppo. Che si tratti davvero di Scrum o meno, Sprint 0 è solo un team web in prima linea, che usa gli strumenti di cui dispone, cercando di capire cosa devono fare prima di iniziare a farlo.

Il vero svantaggio di Sprint 0 è che la creazione del documento guida per il progetto nel momento in cui si hanno meno informazioni fornisce un valore basso al processo di sviluppo che segue.

Le visioni guida del progetto che non si allineano con la realtà iterativamente emergente devono passare attraverso il costoso processo di un altro Sprint 0, o più spesso semplicemente essere ignorate.

Un'alternativa migliore è lo sprint prototipo: un primo sprint che coinvolge l'intero team mentre costruisce effettivamente il prototipo iniziale stesso.

Il Prototipo Sprint Vision Process

Le idee di brainstorming vengono tradotte in una bassa fedeltà visiva, prototipo funzionante il più rapidamente possibile. Il prototipo è scritto in un framework HTML e CSS di front-end funzionale, ovvero il linguaggio condiviso del team. Non tutti possono capire una scheda tecnica o una dichiarazione di visione. Tutti possono capire un sito Web e la comunicazione è più semplice e incorpora una gamma più ampia di discipline.

Entro la fine del primo sprint, il prototipo è pronto per i test iniziali su diversi fronti, tra cui usabilità generale, accessibilità e reattività mobile. Nelle mie squadre questo è un valido e importante incremento fatto. Lo sprint prototipo produce anche un backlog di prodotti iniziale. Man mano che gli elementi del backlog vengono completati negli sprint futuri, il prototipo guadagna in fedeltà. Il prototipo non è un codice usa e getta: è fondamentale.

In alcuni progetti viene generata una visione scritta mentre viene prodotto il prototipo. Ma in molti progetti, il prototipo è la visione. Parla nella lingua condivisa del team e, ovviamente, non è mai fuori passo con il prodotto.

Esempio

L'esempio seguente è di un prototipo funzionante per un'app di e-commerce, completato dallo schema di massima nella proposta di proposta iniziale. Per quanto ruvido sia, è stato determinante nel concentrare le energie del team in una direzione produttiva, scavalcando molte potenziali distrazioni e insidie ​​per concentrarsi su criteri funzionali.

Un prototipo iniziale comporterà spesso modifiche ai requisiti, che sono semplicemente le migliori ipotesi fino a quando non vengono mantenute alla luce dell'esperienza dell'utente. Ad esempio, una delle intuizioni che abbiamo ottenuto dallo sprint del prototipo mostrato sopra è che il prezzo e il pulsante "acquista" erano originariamente troppo bassi sulla pagina. La richiesta iniziale era di inserirli sotto le informazioni sul prodotto e sopra i consigli, ma un prototipo funzionale ha mostrato rapidamente che la gerarchia non era molto funzionale.

Un'altra funzionalità che è emersa è stata che originariamente le immagini della galleria dovevano essere grandi e estendersi per l'intera larghezza della pagina. Invece di esporre alle parti interessate ragioni ipotetiche per cui ciò non avrebbe funzionato, il prototipo è stato in grado di dimostrare i problemi in un linguaggio condiviso che l'intero team comprende. In una sessione di potere con le parti interessate, abbiamo rapidamente riorganizzato questa pagina in una gerarchia universalmente concordata.

Poiché il prototipo nasce accessibile e reattivo, possiamo iniziare subito i test su più dispositivi e tecnologie. Sebbene il design (se si può anche chiamare così in questa fase iniziale) sia intenzionalmente mantenuto a bassa fedeltà, è stato immediatamente evidente che la messaggistica del commutatore dell'anno su desktop era troppo grande sui dispositivi mobili e interferiva con l'usabilità (a sinistra). Abbiamo aggiornato rapidamente il prototipo per utilizzare uno switcher più piccolo nell'intestazione (a destra).

Alcuni altri problemi sono emersi rapidamente durante questo sprint prototipo:

• Il cliente, dopo aver cliccato sulla navigazione funzionale, si è subito reso conto di aver perso un importante componente funzionale nelle sue specifiche: un blog. Ciò ha influito sulla stima e sui tempi, ma siamo stati in grado di adeguarci rapidamente.
• Era evidente al team dell'interfaccia utente che la visualizzazione dei prezzi era eccessivamente complessa e confusa. Abbiamo esplorato altre possibilità con il cliente e siamo stati in grado di prototipare rapidamente e testare diverse soluzioni durante lo sprint del prototipo.

Invece di essere potenzialmente un ostacolo o diventare obsoleto non appena inizia lo sviluppo, in uno sprint prototipo la visione ei criteri funzionali vengono sviluppati insieme e si supportano a vicenda. E poiché la visione è generata dal team, non c'è trasferimento al team ed evita facilmente quel periodo rischioso nel processo di sviluppo.

Il design e lo sprint del prototipo

Nella seconda situazione, la mancanza di integrazione del design con lo sviluppo, è spesso quando vedrai uno "sprint di design" utilizzato. Trovo questa direzione ancora più controproducente di uno Sprint 0. Le sfide dell'integrazione del design in un processo di sviluppo complesso sono reali, ma uno sprint di design è un approccio controproducente. Lo sprint di progettazione è un aiuto per il sintomo — la sfida di creare team integrati — ma non affronta il problema di fondo — la sfida di comprendere e soddisfare le esigenze degli utenti. Il caricamento frontale della progettazione in uno sprint evita la sfida dell'integrazione, ma i vantaggi di un processo di progettazione integrato e incrementale e la finestra che si apre per comprendere e raggiungere gli utenti sono completamente persi.

Lo sprint prototipo che utilizzo nei progetti no-handoff è un'alternativa produttiva e completamente agile allo sprint di design. È collaborativo e unisce UI/UX e sviluppo sin dalle prime fasi del progetto. Anche il team di progettazione più esperto può trarre vantaggio dal coinvolgimento di altre discipline e, in modo critico, garantisce che il codice e gli obiettivi di progettazione non siano in contrasto tra loro.

Spesso ci si aspetta che lo sprint di progettazione arricchisca anche la visione. Questa è una mossa disperata basata su una comprensione vaga ma perspicace che il processo di progettazione è meglio attrezzato per generare visione che sviluppo. Tuttavia, una visione generata dal design è un povero sostituto di uno sforzo reale, collaborativo e a livello di team.

I poveri designer hanno il compito di generare un prodotto finale per avviare lo sviluppo senza le informazioni interdisciplinari necessarie per rendere questo sforzo davvero prezioso. Anche se un designer con conoscenze tecniche e più esperienza avrà maggiori possibilità di farlo bene, è comunque molto rischioso. Senza un prodotto potenzialmente spedibile alla fine della fase da testare contro le congetture, lo sviluppo continua. Se il progetto non ha centrato il segno, o se le specifiche cambiano, possono verificarsi lunghi ritardi quando torna al team di progettazione. Agile è fondamentalmente un processo di gestione del rischio e possiamo fare di meglio che avviare i nostri progetti agili con uno sprint di progettazione intrinsecamente rischioso.

Il processo di progettazione dello sprint del prototipo

Il cambiamento più importante rispetto a uno sprint di design più tradizionale è che durante lo sprint del prototipo il team passa direttamente dalla carta al prototipo e salta l'uso di Sketch, InVision, Photoshop o altri programmi di layout digitale. Fungono da stampella visiva in questa fase, sembrando introdurre valore molto rapidamente (perché i bravi designer fanno cose belle), ma il valore reale di un mockup ad alta fedeltà così presto è molto basso, mentre il potenziale pericolo che introduce: le parti interessate del matrimonio alle soluzioni sbagliate - è alto.

Questi strumenti sono i migliori per prototipi piatti ad alta fedeltà, ma il prototipo iniziale non è né ad alta fedeltà né piatto. La lavagna, la matita e la carta consentono al team di elaborare rapidamente le idee senza essere legato ad esse. Quindi trasforma questo pensiero in un prototipo funzionale il prima possibile.

Ogni membro del team, inclusi i designer, dovrebbe acquisire familiarità ed essere in grado di lavorare sul prototipo direttamente durante le fasi lo-fi. Ma se ciò non è possibile (o è un obiettivo a lungo termine e devi andare avanti ora), allora un approccio accoppiato in cui un designer e uno sviluppatore lavorano fianco a fianco è buono. Gli schizzi possono essere descritti dal progettista e interpretati dallo sviluppatore insieme, ampliando la loro comprensione condivisa di ogni punto di vista.

Esempio

L'esempio seguente mostra il nostro processo di distillazione di un'analisi approfondita di un sito Web esistente direttamente in un prototipo funzionale. Ha permesso di valutare i risultati del rapporto in un ambiente web nativo, un'esperienza molto diversa dall'analisi intellettuale delle raccomandazioni in un documento cartaceo:

Inoltre, a differenza del documento di approfondimento (per quanto utile) il prototipo funzionale è privo di gergo e utilizza un linguaggio verbale e visivo condiviso che tutti possono comprendere. Apre la conversazione su display visivo a tutti i membri del team e le discipline.

La nostra domanda principale durante la creazione di questo modello era la quantità di dettagli di progettazione da includere. Poiché avevamo un documento ricco di analisi da cui attingere, avremmo potuto portare il prototipo oltre. Ma, tenendo presente che gli elementi visivi possono spostarsi rapidamente (e involontariamente) dal regno dell'idea al regno dei fatti, abbiamo mantenuto il layout non vincolante e distillato il documento solo nei suoi elementi e significato essenziali.

I test interni ci hanno portato nel campo di una soluzione più incentrata sull'utente, scavalcando molti potenziali problemi, ma abbiamo evitato consapevolmente di prendere decisioni di progettazione raffinate all'inizio del processo. È importante soppesare continuamente tutte le idee ei suggerimenti, compresi quelli del cliente, con i dati conosciuti e ricordare che il nostro pool di conoscenze è più piccolo a questo punto di quanto lo sarà in qualsiasi altra fase del progetto.

Un altro motivo per cui è fondamentale mantenere il prototipo iniziale lo-fi e non includere alcun elemento di "design" è che l'adesione del team può essere deragliata da elementi visivi irrilevanti che suscitano reazioni viscerali non intenzionali. Stiamo lontani dal colore e non includiamo nemmeno il logo del cliente (usiamo invece uno spazio vuoto o una scatola grigio chiaro come segnaposto). La conversazione deve essere continuamente guidata verso criteri funzionali come la gerarchia dei contenuti, l'accessibilità, l'usabilità, il linguaggio e il significato. Rassicurare la squadra che le "cose ​​divertenti" arriveranno, ma non in questa fase iniziale.

In effetti, un obiettivo importante di uno sprint prototipo di successo è prendere il minor numero possibile di decisioni di progettazione anticipate. La progettazione di successo è alimentata dall'esperienza dell'utente, quindi lascia il tempo per le conoscenze di progetto emergenti per informare l'interfaccia utente.

Quando è completo lo sprint del prototipo

Lo sprint è completo quando il prototipo e gli artefatti di accompagnamento vengono approvati dall'intero team (compreso il cliente) e il prototipo viene ritenuto pronto per i test iniziali di usabilità e accessibilità.

Un primo prototipo funzionale dà vita alla visione del progetto attraverso la scala (numero di pagine, ambito di navigazione e altri elementi principali dell'interfaccia utente), la complessità futura (contenuto segnaposto con descrittori utili, possibilmente alcune funzionalità iniziali codificate) e l'identificazione dei bisogni (tecnologie specifiche necessarie , dove verranno distribuiti, eventuali dipendenze). Le decisioni relative a strumenti, ambiente di lavoro e stack di codice verranno prese con l'input dell'intero team.

Raggiungere questo incremento può richiedere anche solo un giorno per un team esperto con un client reattivo, ma in genere dura circa una settimana e non più di due settimane. Gli sprint prototipo dovrebbero muoversi a un ritmo veloce e superare il periodo di due settimane può essere una bandiera rossa. Potrebbe significare che ci sono altri problemi in gioco.

Alcuni problemi comuni a cui prestare attenzione durante uno sprint prototipo

Alcuni problemi comuni a cui prestare attenzione quando si implementa lo sprint prototipo includono:

• Abbraccia il valore della bassa fedeltà ed evita l'enfasi sulla grafica. Sii vigile su questo punto poiché i team che sono nuovi a questo approccio potrebbero aver bisogno di aiuto e rassicurazioni mentre vanno oltre "dov'è il logo" e si concentrano su questioni più profonde di funzionalità e gerarchia.
• Un aspetto diverso di quanto sopra, sii vigile anche per non attaccarti alle tue idee di design/layout. È utile ricordare durante gli sprint dei prototipi che non viene generato nulla di prezioso e rimanere distaccati dai risultati finali. Inoltre, è un altro motivo per mantenere i prototipi minimi e, francamente, piuttosto brutti. Serve allo scopo di mantenere gli utenti distaccati.
• L'acquisizione iniziale del processo da parte della leadership è fondamentale . Poiché l'intero team è coinvolto, il tuo cliente, il tuo capo e gli sviluppatori devono tutti supportare e coltivare il processo con il loro impegno, creatività e tempo. Non essere una cheerleader solitaria, tutta la tua squadra ha bisogno di sventolare i pompon!
• La scarsa comunicazione è il tallone d'Achille di tutto il lavoro di squadra . Lo sprint del prototipo non risolverà i problemi di comunicazione persistenti, ma li porterà alla ribalta prima che l'intero team si tufferà in un flusso di lavoro collaborativo quasi immediatamente. Eventuali problemi di comunicazione già esistenti emergeranno presto e spesso in uno sprint prototipo mentre lavori verso il consenso e il tuo primo incremento. Cogli l'opportunità di migliorare la comunicazione e coinvolgi l'intero team nella ricerca di soluzioni.
• Scegli il framework front-end giusto . Se non ne hai già uno, potresti dover provare vari framework front-end prima di trovarne uno che si adatti al flusso di lavoro del tuo team. Consiglio di esaminare strutture minime come Fomantic o Bulma e di non rimanere impantanato da campane e fischietti. Tuttavia, il framework giusto è sempre quello che funziona per il tuo team.
• Il team UI/UX deve sviluppare un livello di comfort e l'accesso al framework front-end. Idealmente, lavoreranno direttamente sul prototipo, evitando il trasferimento non necessario e la necessità di traslazione da un supporto all'altro (es. da Sketch al prototipo). Se il tuo team front-end non ha familiarità con CSS e HTML, anche un approccio accoppiato (con un designer e un programmatore che lavorano insieme sul framework) funziona bene.
• Ultimo ma non meno importante, ricorda che diventerai migliore e più veloce come squadra ! Gestire uno sprint prototipo produttivo è un'abilità che cresce con la pratica.

Cosa succede dopo

L'incremento fatto del primo sprint, il prototipo funzionale a bassa fedeltà, pone le basi per tutti gli sprint successivi. Con un prototipo funzionante, i test utente per usabilità, accessibilità e reattività possono iniziare immediatamente, assicurando che gli sprint futuri siano informati dall'esperienza utente.

Lo sprint del prototipo è un ottimo inizio per qualsiasi processo di Scrum, ma nei miei progetti il ​​prossimo passo è passare a un flusso di lavoro a doppia traccia in cui l'interfaccia utente/UX funziona per metà o per l'intero sprint prima dello sviluppo, facendo discovery e aggiornando visivamente il prototipo per riflettere nuove intuizioni.

Il prototipo si sviluppa organicamente e diventa sempre più raffinato, alimentato dalla ricerca UX e da realistiche esigenze funzionali. Tali informazioni, non disponibili durante lo sprint del prototipo, emergono solo in modo incrementale con l'avanzare del progetto. UI/UX e sviluppo si alimentano reciprocamente nei flussi di lavoro attraverso il processo agile a doppio binario.

Non c'è alcun passaggio dal design allo sviluppo da costruire o un'app sviluppata da progettare su skin. Invece, lo sprint del prototipo coinvolge l'intero gruppo dall'inizio e costituisce una solida base per un flusso di lavoro agile e collaborativo durante tutto il progetto.

La visione guida che risulta da uno sprint prototipo non sarà perfetta e probabilmente cambierà man mano che si apprende di più, ma il riconoscimento che all'inizio sappiamo meno che in qualsiasi altra fase di un progetto è al centro del flusso di lavoro agile. Quando applichiamo questa stessa filosofia all'emergere della visione e del design del progetto attraverso uno sprint prototipo, il risultato è un incremento attuabile, artefatti realmente utili, adesione condivisa e un modello di lavoro di squadra e collaborazione che può essere sostenuto durante tutto il progetto .

Una nota sulle impostazioni dell'agenzia

Se lavori in un'agenzia potresti pensare che questo approccio sarà difficile da vendere. Sfortunatamente, probabilmente hai ragione. Molte agenzie sono intrinsecamente poco agili e si impegnano attivamente per il trasferimento totale del progetto, spesso con l'approvazione ufficiale e ripercussioni accuratamente documentate per apportare modifiche lungo la strada. Sostenere uno sprint prototipo in un'organizzazione non agile non è un punto di partenza: semplicemente non è nel loro DNA. Una volta che un'organizzazione abbraccia team agili e interdisciplinari, può facilmente considerare se lo sprint prototipo senza trasferimento migliorerà il loro processo.

Conclusione

Lo Sprint 0 e gli sprint di design affrontano le sfide reali che molti Scrum Team devono affrontare: mancanza di visione, mancanza di design integrato o entrambe. Sono risposte comprensibili e logiche, ma non forniscono un valore elevato né contribuiscono a creare team agili forti.

Sostituirli con uno sprint prototipo è un modo pratico per affrontare gli svantaggi dello Sprint 0 e degli sprint di design, gettando contemporaneamente le basi per una collaborazione più agile e più forte durante gli sprint futuri.

Uno sprint prototipo utilizza i talenti dell'intero team, genera la visione necessaria, si traduce nel primo incremento fatto del team ed evita il trasferimento del progetto. Attraverso questo processo, i team costruiscono la proprietà condivisa della visione del progetto e una base più solida per la cooperazione interdisciplinare nello spirito agile.

Ulteriori letture su SmashingMag:

• Diventare un facilitatore migliore
• Adattamento agile per i team part-time
• L'importanza delle retrospettive di progetto
• Portare un migliore processo di progettazione alla tua organizzazione