Jeg har jobbet som front-end-utvikler i ca. to år, og har deltatt i opprettelsen av en lang rekke prosjekter. En av lærdommene jeg har lært er at samarbeid mellom ulike team av utviklere som deler samme mål, men har ulike oppgaver og ansvar, ikke er lett.
I samråd med andre teammedlemmer, designere og utviklere, laget jeg en syklus for å lage nettsider designet for små team (5-15 personer). Den inkluderer verktøy som Confluence, Jira, Airtable og Abstract. I denne artikkelen vil jeg dele funksjonene ved å organisere arbeidsflyten.
Skillbox anbefaler: Toårig praktisk kurs .
Vi minner om: for alle lesere av "Habr" - en rabatt på 10 000 rubler når du melder deg på et hvilket som helst Skillbox-kurs ved å bruke kampanjekoden "Habr".
Hvorfor er alt dette nødvendig?
Minimumsteamet som trengs for å lage et nettsted fra bunnen av er en designer, programmerer og prosjektleder. I mitt tilfelle ble laget dannet. Men etter utgivelsen av et par nettsteder fikk jeg følelsen av at noe var galt med det. Noen ganger forsto vi rett og slett ikke vårt ansvar fullt ut, og kommunikasjonen med klienten la mye tilbake å ønske. Alt dette bremset prosessen og forstyrret alle.
Jeg begynte å jobbe med å løse problemet.
Et Google-søk gir gode resultater på problemet vårt.
For å gjøre arbeidet mer visuelt laget jeg et arbeidsflytdiagram som gir en forståelse av hvordan arbeidet gjøres her.
Klikk på bildet for å åpne i full oppløsning.
Mål og mål
En av de første teknikkene jeg bestemte meg for å teste var "kaskademodellen" (foss). Jeg brukte den til å fremheve problemer og forstå hvordan jeg skulle løse dem.
Problem: Oftest evaluerer ikke klienten prosessen for å lage nettsiden modulært, slik utviklere gjør. Han oppfatter det som et vanlig nettsted, det vil si at han tenker på enkeltsider. Etter hans mening lager designere og programmerere individuelle sider, etter hverandre. Som et resultat forstår kunden rett og slett ikke hva som følger etter under selve prosessen.
Oppgave: Det er ingen vits i å overbevise kunden om noe annet; det beste alternativet er å utvikle en modulær prosess for å lage en nettside i selskapet basert på en side-for-side-modell.
Universelle designsymboler og komponenter administreres av både utviklere og designere.
Problem: Dette er en vanlig situasjon som mange strategier adresserer. Det er mange interessante løsninger, i de fleste tilfeller er det foreslått å lage et designsystem som styres av en stilguide / biblioteksgeneratorer. Men i vår situasjon var det rett og slett ikke mulig å legge til en annen komponent til utviklingsprosessen som ville tillate oss å administrere tilgangsnivåer for designere.
Oppgave: bygge et universelt system der designere, utviklere og ledere kan jobbe synkront uten å forstyrre hverandre.
Nøyaktig utviklingssporing
Problem: Selv om det er mange nyttige verktøy tilgjengelig for å spore problemer og måle generell fremgang, er de fleste ikke fleksible eller optimale. Verktøyet kan være nyttig ved å spare teamtiden som normalt ville blitt brukt på spørsmål og avklaringer på spesifikke oppgaver. Det gjør også livet enklere for ledere ved å gi dem en mer nøyaktig forståelse av hele prosjektet.
Oppgave: lag et dashbord for å spore fremdriften til oppgaver utført av forskjellige teammedlemmer.
verktøysett
Etter å ha eksperimentert med forskjellige verktøy, bestemte jeg meg for følgende sett: Confluence, Jira, Airtable og Abstract. Nedenfor vil jeg avsløre fordelene med hver.
Confluence
Verktøyets rolle: informasjons- og ressurssenter.
Confluences arbeidsområde er relativt enkelt å sette opp, har mange funksjoner, integrasjoner med forskjellige apper, og har individuelle, tilpassbare maler. Det er ikke en løsning som passer alle, men den er ideell som et informasjons- og ressurssenter. Dette betyr at enhver referanse eller teknisk detalj knyttet til prosjektet må legges inn i databasen.
Verktøyet lar deg dokumentere hver komponent og andre detaljer om prosjektet på riktig måte.
Den største fordelen med Confluence er tilpasningen av dokumentmaler. I tillegg kan den brukes til å implementere et enkelt oppbevaringssted for spesifikasjoner og forskjellig prosjektdokumentasjon, som skiller tilgangsnivåene til deltakerne. Nå trenger du ikke bekymre deg for at du har en gammel versjon av spesifikasjonen for hånden, slik det skjer når du sender dokumenter på e-post.
Mer informasjon om verktøyet .
Jira
Verktøyets rolle: problemovervåking og oppgavehåndtering.
Jira er et veldig kraftig prosjektplanleggings- og styringsverktøy. Hoveddelen av funksjonaliteten er å lage tilpassbare arbeidsflyter. For å effektivt håndtere problemer (som er det vi trenger), er det verdt å være spesielt oppmerksom på riktig bruk av forespørselstype og problemtype (problemtype).
Så for å sikre at utviklere bygger komponenter basert på riktig design, må de varsles hver gang noe endres i designet. Så snart komponenten er oppdatert, må designeren åpne et problem, tildele en ansvarlig utvikler, tildele ham den riktige problemtypen.
Med Jira kan du være sikker på at absolutt alle deltakere i prosessen (la meg minne om, i vårt tilfelle er det 5–15 av dem) får korrekte oppgaver som ikke går seg vill og finner sin eksekutør.
Lær mer om Jira .
Airtable
Verktøyets rolle: komponentstyring og fremdriftstavle.
Airtable er en blanding av regneark og databaser. Alt dette gjør det mulig å tilpasse driften av alle verktøyene diskutert ovenfor.
Eksempel 1: Komponentstyring
Når det gjelder stilguidegeneratoren, er den ikke alltid praktisk å bruke - problemet er at designere ikke kan redigere den. I tillegg vil det ikke være en god beslutning å bruke Sketch-komponentbiblioteket, siden det har mange begrensninger. Mest sannsynlig vil du ganske enkelt ikke kunne bruke dette biblioteket utenfor programmet.
Airtable er heller ikke perfekt, men det er bedre enn mange andre lignende løsninger. Her er en demo av komponentadministrasjonstabellmalen:
Når en utvikler godtar en designkomponent, evaluerer han den resulterende ABEM ved å registrere komponenten i en tabell. Det er 9 kolonner totalt:
- Navn - navnet på komponenten i henhold til ABEM-prinsippet.
- Forhåndsvisning - Her plasseres enten et skjermbilde eller et bilde av komponenten lastet ned fra en annen kilde.
- En koblet side er en lenke til en komponents side.
- Underordnet komponent - en lenke til underordnede komponenter.
- Modifikator - sjekker for tilstedeværelsen av stilalternativer og definerer dem (for eksempel aktiv, rød, etc.).
- Komponentkategori er en generell kategori (tekst, reklamebilde, sidefelt).
- Utviklingsstatus - den faktiske utviklingsfremdriften og dens definisjon (fullført, pågår osv.).
- Ansvarlig - utvikleren som er ansvarlig for denne komponenten.
- Atomnivå er atomkategorien til denne komponenten (i henhold til konseptet atomdesign).
- Data kan refereres til i samme eller i forskjellige tabeller. Å koble sammen prikkene vil forhindre forvirring ved skalering. I tillegg kan dataene filtreres, sorteres og endres uten problemer.
Eksempel 2: sideutviklingsfremgang
For å evaluere fremdriften for sideutvikling trenger du en mal som er laget spesielt for dette formålet. Bordet kan betjene både teamets og klientens behov.
Eventuell informasjon om siden kan merkes her. Dette er en frist, en lenke til InVision-prototypen, en destinasjon, en underordnet komponent. Det blir umiddelbart merkbart at operasjonene er svært praktiske å utføre, både med tanke på å dokumentere og oppdatere designet, samt status for front-end og back-end utvikling. Dessuten utføres disse operasjonene samtidig.
Abstrakt
Verktøyets rolle: en enkelt kilde til versjonskontroll for designelementer.
Abstrakt kan kalles GitHub for eiendeler i Sketch, og det sparer designere fra å måtte kopiere og lime inn filer. Den største fordelen med verktøyet er at det gir et designlager som fungerer som en "enkelt kilde til sannhet." Designere må oppdatere hovedgrenen til siste versjon av den godkjente layouten. Etter det må de varsle utviklerne. Disse skal på sin side bare fungere med designereiendeler fra hovedgrenen.
Som en konklusjon
Etter at vi implementerte den nye utviklingsprosessen og alle verktøyene nevnt ovenfor, økte hastigheten på arbeidet vårt minst to ganger. Det er ikke en perfekt løsning, men den er veldig god. Det er sant, for at det skal fungere, må du legge ned mye innsats - det krever "manuelt arbeid" for å oppdatere og vedlikeholde alt i orden.
Skillbox anbefaler:
- Praktisk kurs .
- Online kurs .
- Praktisk årskurs .
Kilde: www.habr.com