En bedre arbejdsudvikling til webudvikling: Confluence, Airtable og mere

Arbejdet som en front-end-udvikler i næsten to år, har jeg fået god erfaring fra at være en del af flere webudviklingsprojekter fra design / digitale bureauer.

En åbenbar, men værdifuld lektion, jeg har lært, er, at samarbejde mellem hver gruppe med et mål, men forskellige ansvarsområder og formål ikke er let. Der er forskellige aspekter og niveauer af vanskeligheder med hensyn til samarbejde, og den specifikke del, som jeg gerne vil tage fat på her, er arbejdsgangsprocessen.

Baseret på min erfaring og med hjælp fra mine designer- og udviklervenner byggede jeg en arbejdsgang til udvikling af websteder designet til et lille team (5–15 personer). Systemet er sammensat af Confluence, Jira, Airtable og Abstract. I denne artikel deler jeg hvorfor og hvordan denne arbejdsgang er.

Motivation til opbygning af en ny arbejdsgang

For at levere et tilpasset websted uden brug af skabeloner leveret af webstedsudviklere inkluderer minimumskravet til talent en designer, udvikler og projektleder. Efter at have deltaget i et par sager havde jeg en fornemmelse af, at der var noget galt med den arbejdsgang, vi havde: vigtig information var altid ikke tilpasset både internt mellem forskellige roller og eksternt til klienten. Denne ineffektive kommunikation bremsede klart udviklingscyklussen og skadede holdet.

Så jeg begyndte at løse dette problem.

Jeg Google søgte på ressourcer om oprettelse og forbedring af en arbejdsgang. Selvom jeg lærte meget af alle de store ressourcer, fandt jeg næsten ingen af ​​dem til webudviklingsprojekter i et design / digitalt bureau. Det var enten et designsystem eller kodningsretningslinjer, der omfattede design eller frontend-roller, eller en workflow, der blev bygget til et team med sit eget produkt.

Som et resultat besluttede jeg at kirsebærplukke de dele, jeg havde brug for til at løse vores problemer, og dannede en skræddersyet arbejdsgang til webstedsudvikling.

Problemer og mål

Følgende er de problemer, jeg inspicerede fra vores eksisterende arbejdsgang, og de tilsvarende forbedringsmål:

1. Vandfaldsmetode

Problem: Baseret på min erfaring anvender webstedsprojekter en vandfaldstilgang, fordi kunder ikke har et koncept om et minimum levedygtigt produkt (MVP). I stedet for at opdele funktionaliteter fra visninger og modulering har klienter tendens til at tænke på webstedet på en traditionel side-for-side måde, hvilket tvinger både designere og udviklere til at arbejde side for side i rækkefølge. Dette får dem til at miste et universelt perspektiv på tværs af projektet. Denne situation resulterer i masser af frem og tilbage overflødige ændringer mellem sider.

Mål: At ændre klienters tankegang er både arrogant og urealistisk. Målet er at finde en måde at adskille krav fra visninger så hurtigt som muligt og udvikle sig på en så moduleret måde som muligt internt baseret på side-for-side-model.

2. Universelle design tokens og komponenter styret af både designere og udviklere

Problem: Dette er et almindeligt problem, som mange artikler har delt gode løsninger på, som for det meste foreslår at opbygge et designsystem, der styres af stilguide / biblioteksgeneratorer. Selvom det er en god løsning, var det ikke hensigtsmæssigt i vores situation at administrere et ekstra websted, der næppe gav redigeringstilladelse til designere.

Mål: Bortset fra at skabe universelle design tokens og sprog, som designere, udviklere og ledere alle kan forstå, skal du opbygge et system, der giver alle mulighed for at administrere aktiverne på en synkron måde.

3. Nøjagtigt, opdateret statusdashboard

Problem: Selvom problemsporere, kanban og flere projektstyringsmodeller er nyttige og praktiske, fungerede de fleste af dem ikke som et ligetil, fleksibelt og venligt instrumentpanel. Denne form for instrumentbræt sparer holdet meget tid, fordi det forhindrer teammedlemmer i at rapportere aktivt eller spørge om den aktuelle situation for specifikke opgaver. Det letter også ledernes liv, hvis de har et klart kendskab til hele projektet uden for meget indsats.

Mål: Byg et dashboard-system, der giver redigeringstilladelse til personer, der har ansvaret for specifikke opgaver.

Workflow diagram

Før vi dykker ned i den detaljerede introduktion af stakken til styringsværktøjer, lad os se på den abstrakte forenklede arbejdsgang, jeg organiserede. Det er stort set bare en visualisering af en normal arbejdsgang, som de fleste bureauer har, men der er to punkter, der skal bemærkes her.

1. Udviklerevaluering

For det første, når krav eller problemer, der kommer fra klienten, er godkendt og dokumenteret af manager, med undtagelse af at sende opgaven til en designer, går de også til en udvikler til evaluering. I denne proces gennemgår udvikleren specifikationen af ​​opgaven og kontrollerer, om der er nogen ret komplicerede funktioner eller funktioner inkluderet. Hvis det er positivt, kan udvikleren begynde at arbejde på det eller underrette designeren om de potentielle problemer på forhånd.

2. Enkel kilde til sandhed

Bemærk også, at når designlevering er godkendt af klienten, og før opgaven overdrages til udviklerens hånd, gennemgår den en proces med registrering / ændring / sletning over designbutik udført af designeren. Dette skyldes, at udvikleren altid skal udsættes for en eneste kilde til designbutik, som indeholder konstant vedligeholdte og opdaterede aktiver, der er klar til udvikling.

Nu kan vi dykke ned i den stack, jeg forberedte ledelsesværktøjer, og se hvordan værktøjerne hjælper os med at løse vores problemer.

Værktøjerne stables

Efter at have eksperimenteret med forskellige muligheder på markedet, er stakken, jeg foreslår her, sammensat af Confluence, Jira, Airtable og Abstract. Ud over grundlæggende introduktion og få eksempler på vigtige applikationer dækker jeg ikke alle detaljerne i brugen af ​​værktøjerne.

Bemærk: systemet antager, at udviklingsteamet anvender atomdesignmetoden og ABEM-navngivningssystemet.

1. Sammenløb

Rolle: informations- og ressourcecenter

Selvom det i første omgang er skræmmende, giver Confluence et kraftigt arbejdsområde, der er let at organisere, og det har masser af funktioner, integration af apps og tilpassede skabeloner. Det er bestemt ikke en universel løsning på alle problemer, men det er perfekt til dokumentation af specifikationer, krav, møderotater og mere.

Derfor fungerer Confluence i denne stak som et informations- og ressourcecenter, hvilket betyder, at alle relaterede link og detaljer om dette projekt skal dokumenteres korrekt herinde.

Min foretrukne fordel ved Confluence er muligheden for at tilpasse dokumentskabeloner. Denne funktion gør det virkelig bekvemt at standardisere arbejdsgangen.

Eksempel: Komponentfunktionalitetsanmeldelse

Jeg nævnte udviklerevalueringsprocessen ovenfor, hvilket faktisk er et kompliceret job. Dette skyldes, at denne proces inkluderer grundlæggende oplysninger om komponenten, en udviklers FSM-gennemgang (om nødvendigt), FAQ-plads og mere. Men fleksibiliteten i skabelonen og værktøjerne Confluence giver gør det super nemt. Bare bygg en skabelon i konfigurationsindstillingerne, så er du klar.

2. Jira

Rolle: Sporing af spørgsmål og styring af handlingstype

Jira er også medlem af Atlassian-familien og er en superkraftig software til sporing af problemer og projektplanlægning. Min yndlingsdel om det er at lave tilpassede problemarbejdsprocesser. Da der er masser af gode tutorials om, hvordan man bruger Jira-kraften, er det eneste, jeg vil påpege her, at bruge emnetype som nævnt nedenfor.

Eksempel: Opdater udvikleren om ændringer i designbutikken efter problemtype

For at sikre, at udviklere bygger komponenterne på baggrund af korrekte designvisninger, skal de underrettes, når noget i designbutikken opdateres, hvilket inkluderer handlinger som at registrere, ændre og slette . Så når en komponent opdateres, skal designeren åbne et problem med den ansvarlige udvikler tildelt og den korrekte problem / handlingstype valgt.

3. Luftbord

Rolle: komponentadministration og status dashboard

Airtable, en blanding af regneark og database, er den ting, der får denne stak til at fungere. Der er to fantastiske funktioner, der understøtter min arbejdsgang: fire typer visningsovergang i enkelt tabel og relateret indholdslink. Jeg viser to eksempler på brug af disse to funktioner her.

Eksempel 1: Komponentstyring

Hvordan administrerer du dit komponentbibliotek? Vi valgte ikke at bruge en stilguide-generator, fordi den ikke er tilgængelig for designere at redigere. Brug af Sketch-komponentbiblioteket var heller ikke passende, fordi det har for mange begrænsninger, hvis vi forsøgte at bruge det uden for selve softwarens anvendelsesområde.

Jeg vil ikke sige, at Airtable er en perfekt løsning, men det er den nemmeste og mest fleksible mulighed, jeg kunne tænke på. Se på demo-skabelonen til komponentstyringstabellen her:

Når en nyregistreret designvisning, der er klar til at blive udviklet programmatisk, er sendt til udvikleren, vurderer de visningen baseret på ABEM-systemet og registrerer den i tabellen. Der er 9 kolonner i tabellen, herunder:

1. Navn: navngivning af komponenten i ABEM-princippet

2. Eksempel: skærmbillede eller eksporteret billede af komponenten

3. Tilknyttet side: link til siden indeholder denne komponent

4. Komponent for børn : link til underordnede komponenter indeholder denne

5. Modifikator: kontrollerer om der er stilvariationer (f.eks: - aktiv, - rød)

6. Komponentkategori: en generel kategoriklassifikation (f.eks. Tekst, helt, sidebjælke)

7. Udviklingsstatus: status for udviklingsforløb (afventende, tildelt, i gang, afsluttet, under revision)

8. Modtager: udvikler ansvarlig for denne komponent

9. Atomniveau: atomkategori for denne komponent (atom, molekyle, organisme)

Det bedste her er, at du kan henvise til data i både den samme og andre tabeller. Denne forbindelse af prikker forhindrer ting i at blive mere rodet, når skalaen vokser. Bemærk også, at du nemt kan filtrere, sortere og ændre visninger.

Eksempel 2: Sideudviklingsstatus

Da antagelsen her er, at vi uundgåeligt vurderer udviklingsforløb side for side, er en tabelskabelon designet til dette formål nødvendig. Denne tabel kan være et fremskridtsdashboard for begge interne teams og deles med klienten på samme tid.

Alle oplysninger om siden, inklusive deadline, InVision-prototype-link, tilskud og børnekomponent kan organiseres her. Bemærk, at det er meget praktisk at dokumentere og opdatere design, front-end og back-end udviklingsstatus på samme tid.

4. Abstrakt

Rolle: enkelt kilde til sandhed og design aktiveres versionskontrol

Abstrakt er GitHub for Sketch-aktiver, der redder designere fra helvede med at kopiere og indsætte filer. Det er uden for denne artikels anvendelsesområde at demonstrere detaljer i styring af versionskontrolflow. Nøglen til afhentning her er, at Abstrakt er designbutikken, der fungerer som den eneste kilde til sandhed . Designere bør fortsætte med at opdatere mastergren til den nyeste version af bekræftet design og derefter underrette udviklere. På den anden side skal udviklere kun tage designaktiver i mastergrenen som reference.

Mere arbejde, der skal udføres

Fra min egen erfaring har udviklingen af ​​hele projektet efter vedtagelsen af ​​denne nye arbejdsgang været mindst to gange hurtigere end før. Det er ikke en perfekt løsning, fordi det stadig kræver masser af manuelt arbejde for at opdatere og vedligeholde.

Men jeg tror, ​​det kan være en nyttig reference til webstedsudviklingsteams, der søger efter en bedre arbejdsgang, og forhåbentlig kan flere mennesker dele deres arbejdsgange i fremtiden!

? 中文版 連結 (kinesisk version)  / Oprindeligt udgivet på vinceshao.com