Un flusso di lavoro di sviluppo web migliore: Confluence, Airtable, Jira e Abstract

Confluenza, Jira, Airtable e Abstract

中文 版 連結 (versione cinese) / Originariamente pubblicato su vinceshao.com

Lavorando come sviluppatore front-end per quasi due anni, ho avuto un'esperienza utile facendomi parte di numerosi progetti di sviluppo web di agenzie di design / digitali.

Una lezione ovvia ma preziosa che ho imparato è che collaborare tra ogni gruppo con un obiettivo ma responsabilità e scopi distinti non è facile. Esistono diversi aspetti e livelli di difficoltà in termini di collaborazione e la parte specifica di cui vorrei occuparmi qui è il processo del flusso di lavoro.

Sulla base della mia esperienza e con l'aiuto dei miei amici designer e sviluppatori, ho creato un flusso di lavoro per lo sviluppo di siti Web progettato per piccoli team (5-15 persone). Il sistema è composto da Confluence, Jira, Airtable e Abstract. In questo articolo, condividerò il perché e il come di questo flusso di lavoro.

Motivazione per la creazione di un nuovo flusso di lavoro

Per fornire un sito Web personalizzato senza utilizzare i modelli forniti dai costruttori di siti Web, i requisiti minimi di talento includono designer, sviluppatore e project manager. Dopo aver partecipato a un paio di casi, avevo la sensazione che ci fosse qualcosa di sbagliato nel flusso di lavoro che avevamo: informazioni importanti non erano sempre allineate sia internamente tra ruoli diversi che esternamente al cliente. Questa comunicazione inefficiente stava chiaramente rallentando il ciclo di sviluppo e danneggiando il team.

Quindi ho iniziato a risolvere questo problema.

Grandi risorse del flusso di lavoro di ricerca di Google: funzionalità dei sistemi di progettazione, risorse della guida di stile e definizione del flusso di lavoro

Google ha cercato risorse per stabilire e migliorare un flusso di lavoro. Sebbene abbia imparato molto da tutte le grandi risorse, non ho trovato quasi nessuno dei quali per progetti di sviluppo web in un'agenzia di design / digitale. Si trattava di un sistema di progettazione o di linee guida di codifica che riguardavano ruoli di progettazione o front-end o un flusso di lavoro creato per un team con il proprio prodotto.

Di conseguenza, ho deciso di scegliere le parti necessarie per risolvere i nostri problemi e ho creato un flusso di lavoro personalizzato per lo sviluppo del sito Web.

Problemi e obiettivi

Di seguito sono riportati i problemi che ho esaminato dal nostro flusso di lavoro esistente e i corrispondenti obiettivi di miglioramento:

1. Metodologia delle cascate

demo cascata modello astratto

Problema: in base alla mia esperienza, i progetti di siti Web adottano un approccio a cascata perché i clienti non hanno un concetto di prodotto minimo sostenibile (MVP). Invece di dividere le funzionalità da viste e modulizzazione, i clienti tendono a pensare al sito in modo tradizionale pagina per pagina, costringendo sia i progettisti che gli sviluppatori a lavorare pagina per pagina in sequenza. Questo fa sì che perdano una prospettiva universale in tutto il progetto. Questa situazione comporta numerose revisioni ridondanti avanti e indietro tra le pagine.

Obiettivo: cambiare la mentalità dei clienti è sia arrogante che irrealistico. L'obiettivo è trovare un modo per separare i requisiti dalle viste il più presto possibile e svilupparli nel modo più modulizzato possibile internamente in base al modello pagina per pagina.

2. Token e componenti di progettazione universali gestiti da designer e sviluppatori

token di progettazione di Salesforce

Problema: questo è un problema comune a cui molti articoli hanno condiviso grandi soluzioni, che per lo più propongono di costruire un sistema di progettazione gestito da generatori di guide / librerie di stile. Sebbene sia un'ottima soluzione, la gestione di un sito aggiuntivo che a malapena ha fornito autorizzazioni di modifica ai progettisti non era appropriata nella nostra situazione.

Obiettivo: ad eccezione della creazione di token e linguaggi di progettazione universali comprensibili a designer, sviluppatori e manager, creare un sistema che consenta a tutti di gestire le risorse in modo sincrono.

3. Dashboard di avanzamento accurato e aggiornato

abbiamo bisogno di una dashboard di avanzamento modificabile e accessibile

Problema: sebbene i tracker dei problemi, i kanban e altri modelli di gestione dei progetti siano utili e pratici, la maggior parte di essi non ha funzionato come una dashboard di avanzamento semplice, flessibile e amichevole. Questo tipo di dashboard risparmierebbe molto tempo al team perché impedirebbe ai membri del team di riferire attivamente o chiedere informazioni sulla situazione attuale di compiti specifici. Inoltre semplifica la vita dei manager se hanno una chiara conoscenza dell'intero progetto senza troppi sforzi.

Obiettivo: creare un sistema di dashboard che fornisca l'autorizzazione alla modifica per le persone incaricate di attività specifiche.

Diagramma del flusso di lavoro

Prima di approfondire l'introduzione dettagliata dello stack degli strumenti di gestione, diamo un'occhiata al flusso di lavoro semplificato astratto che ho organizzato. È praticamente solo una visualizzazione di un normale flusso di lavoro che la maggior parte delle agenzie ha, ma ci sono due punti da notare qui.

diagramma del flusso di lavoro che ho progettato

1. Valutazione dello sviluppatore

In primo luogo, quando i requisiti o i problemi provenienti dal cliente vengono approvati e documentati dal gestore, ad eccezione dell'invio dell'attività a un progettista, vanno anche a uno sviluppatore per la valutazione. In questo processo, lo sviluppatore esamina le specifiche dell'attività, verificando se sono incluse funzioni o caratteristiche piuttosto complicate. Se è positivo, lo sviluppatore potrebbe iniziare a lavorarci o informare preventivamente il progettista sui potenziali problemi.

2. Singola fonte di verità

Si noti inoltre che dopo che il prodotto consegnabile è stato approvato dal cliente e prima di passare l'attività alla mano dello sviluppatore, passa attraverso un processo di registrazione / modifica / eliminazione sul negozio di progettazione condotto dal progettista. Questo perché lo sviluppatore dovrebbe essere sempre esposto a una sola fonte del negozio di design, che contiene risorse costantemente mantenute e aggiornate pronte per lo sviluppo.

Ora possiamo immergerci nello stack degli strumenti di gestione che ho preparato e vedere come gli strumenti ci aiutano a risolvere i nostri problemi.

La pila di strumenti

Dopo aver sperimentato varie opzioni sul mercato, lo stack che sto proponendo qui è composto da Confluence, Jira, Airtable e Abstract. Oltre all'introduzione di base e ad alcuni esempi di applicazioni chiave, non tratterò tutti i dettagli dell'uso degli strumenti.

design atomico e ABEM

Nota: il sistema presuppone che il team di sviluppo adotti la metodologia di progettazione atomica e il sistema di denominazione ABEM.

1. Confluenza

Ruolo: centro informazioni e risorse

Sebbene all'inizio sia intimidatorio, Confluence offre un potente spazio di lavoro che è facile da organizzare e ha tonnellate di funzionalità, integrazione di app e modelli personalizzati. Non è sicuramente una soluzione universale a tutti i problemi, ma è perfetta per la documentazione di specifiche, requisiti, note di riunione e altro ancora.

Pertanto, Confluence in questo stack funziona come un centro di informazioni e risorse, il che significa che ogni collegamento e dettaglio relativo a questo progetto dovrebbe essere documentato correttamente qui.

Il mio vantaggio preferito di Confluence è la possibilità di personalizzare i modelli di documento. Questa funzionalità rende davvero conveniente standardizzare il flusso di lavoro.

fase di valutazione degli sviluppatori

Esempio: revisione della funzionalità dei componenti

Ho citato il processo di valutazione degli sviluppatori sopra, che in realtà è un lavoro complicato. Questo perché questo processo include informazioni di base sul componente, una revisione dell'FSM dello sviluppatore (se necessario), spazio FAQ e altro. Ma la flessibilità del modello e degli strumenti forniti da Confluence rende tutto ciò estremamente semplice. Crea un modello nelle impostazioni di configurazione e sei a posto.

modello personalizzato per la revisione dei componenti in Confluence

2. Jira

Ruolo: rilevamento dei problemi e gestione del tipo di azione

Membro della famiglia Atlassian, Jira è un software di monitoraggio e pianificazione dei progetti estremamente potente. La mia parte preferita è creare flussi di lavoro con problemi personalizzati. Dato che ci sono tonnellate di fantastici tutorial su come utilizzare il potere di Jira, l'unica cosa che voglio sottolineare qui è usare il tipo di problema come menzionato di seguito.

negozio di progettazione aggiornamento designer

Esempio: aggiorna lo sviluppatore sulle modifiche del design store per tipo di problema

Per garantire che gli sviluppatori stiano costruendo i componenti in base a viste di progettazione corrette, devono essere avvisati ogni volta che qualcosa nel design store viene aggiornato, che include azioni come registrazione, modifica ed eliminazione. Pertanto, quando un componente viene aggiornato, il progettista dovrebbe aprire un problema con lo sviluppatore responsabile assegnato e il tipo di problema / azione corretto selezionato.

Funzione di tipi di problemi di Jira

3. Airtable

Ruolo: gestione dei componenti e dashboard di avanzamento

Airtable, un mix di foglio di calcolo e database, è la cosa che fa funzionare questo stack. Esistono due straordinarie funzionalità che supportano il mio flusso di lavoro: quattro tipi di transizione di visualizzazione in una singola tabella e il collegamento di contenuti correlati. Mostrerò qui due esempi di utilizzo di queste due funzioni.

lo sviluppatore inizia a lavorare sull'attività

Esempio 1: gestione dei componenti

Come gestisci la tua libreria di componenti? Abbiamo scelto di non utilizzare un generatore di guide di stile, perché non è accessibile ai designer per la modifica. Anche l'utilizzo della libreria dei componenti di Sketch non era appropriato, perché ha troppe limitazioni se provassimo a usarlo al di fuori dell'ambito del software stesso.

Non direi che Airtable sia la soluzione perfetta, ma è l'opzione più semplice e flessibile che mi venga in mente. Dai un'occhiata al modello demo della tabella di gestione dei componenti qui:

tabella dei componenti

Una volta che una vista di progettazione appena registrata, pronta per essere sviluppata a livello di codice, viene inviata allo sviluppatore, valutano la vista in base al sistema ABEM e la registrano nella tabella. Ci sono 9 colonne nella tabella, tra cui:

1. Nome: denominazione del componente secondo il principio ABEM

2. Anteprima: screenshot o immagine esportata del componente

3. Pagina collegata: il collegamento alla pagina contiene questo componente

4. Componente figlio: il collegamento ai componenti figlio contiene questo

5. Modificatore: controlla se ci sono variazioni di stile (es: - attivo, - rosso)

6. Categoria del componente: una classificazione generale della categoria (es: testo, eroe, barra laterale)

7. Stato dello sviluppo: stato dell'avanzamento dello sviluppo (in sospeso, assegnato, in corso, completo, in revisione)

8. Assegnatario: sviluppatore responsabile di questo componente

9. Livello atomico: categoria atomica di questo componente (atomo, molecola, organismo)

La cosa migliore qui è che puoi fare riferimento ai dati sia nella stessa che in altre tabelle. Questa connessione di punti impedisce alle cose di diventare più disordinate man mano che la scala cresce. Si noti inoltre che è possibile filtrare, ordinare e modificare facilmente le viste.

Esempio 2: stato dello sviluppo della pagina

Poiché il presupposto qui è che valuteremo inevitabilmente l'avanzamento dello sviluppo pagina per pagina, è necessario un modello di tabella progettato per questo scopo. Questa tabella può essere una dashboard di avanzamento per entrambi i team interni e condivisa con il client contemporaneamente.

tabella elenco pagine

Qui è possibile organizzare qualsiasi informazione sulla pagina, compresi scadenza, collegamento prototipo InVision, assegnatario e componente figlio. Tieni presente che è molto conveniente documentare e aggiornare contemporaneamente lo stato di progettazione, front-end e back-end.

4. Estratto

Ruolo: singola fonte di verità e controllo della versione delle risorse di progettazione

Abstract è GitHub per gli asset di Sketch che salva i progettisti dall'inferno di copiare e incollare file. Non rientra nell'ambito di questo articolo per dimostrare i dettagli sulla gestione del flusso di controllo delle versioni. La chiave da asporto qui è che Abstract è il negozio di design che funge da unica fonte di verità. I progettisti dovrebbero continuare ad aggiornare il ramo master all'ultima versione del progetto confermato e quindi avvisare gli sviluppatori. D'altro canto, gli sviluppatori dovrebbero prendere come riferimento solo le risorse di progettazione nel ramo principale.

Modello di ramo astratto

Più lavoro da fare

Dalla mia esperienza, lo sviluppo dell'intero progetto dopo aver adottato questo nuovo flusso di lavoro è stato almeno due volte più veloce di prima. Non è una soluzione perfetta, perché richiede ancora molta manodopera per l'aggiornamento e la manutenzione.

Ma penso che potrebbe essere un utile riferimento ai team di sviluppo di siti Web che cercano un flusso di lavoro migliore e, si spera, più persone potranno condividere i loro flussi di lavoro in futuro!