Jeg har arbejdet som front-end udvikler i omkring to år og har deltaget i skabelsen af en lang række projekter. En af de erfaringer, jeg lærte, er, at samarbejde mellem forskellige teams af udviklere, der deler det samme mål, men har forskellige opgaver og ansvar, ikke er let.
I samråd med andre teammedlemmer, designere og udviklere skabte jeg en hjemmesideoprettelsescyklus designet til små teams (5-15 personer). Det inkluderer værktøjer som Confluence, Jira, Airtable og Abstract. I denne artikel vil jeg dele funktionerne i at organisere arbejdsgangen.
Skillbox anbefaler: To-årigt praktisk kursus .
Påmindelse: for alle læsere af "Habr" - en rabat på 10 rubler ved tilmelding til ethvert Skillbox-kursus ved hjælp af "Habr"-kampagnekoden.
Hvorfor er alt dette nødvendigt?
Det minimumsteam, der skal til for at lave en hjemmeside fra bunden, er en designer, programmør og projektleder. I mit tilfælde blev holdet dannet. Men efter udgivelsen af et par websteder, fik jeg en følelse af, at der var noget galt med det. Nogle gange forstod vi simpelthen ikke helt vores ansvar, og kommunikationen med kunden lod meget tilbage at ønske. Alt dette bremsede processen og forstyrrede alle.
Jeg begyndte at arbejde på at løse problemet.
En Google-søgning giver gode resultater på vores problem.
For at gøre arbejdet mere visuelt, har jeg lavet et workflowdiagram, der giver en forståelse af, hvordan arbejdet udføres her.
Klik på billedet for at åbne i fuld opløsning.
Mål og mål
En af de første teknikker, som jeg besluttede at teste, var "kaskademodellen" (vandfald). Jeg brugte det til at fremhæve problemer og forstå, hvordan man løser dem.
Problem: Oftest evaluerer klienten ikke hjemmesideoprettelsesprocessen modulært, som udviklere gør. Han opfatter det som et almindeligt site, det vil sige, at han tænker i individuelle sider. Efter hans mening opretter designere og programmører individuelle sider, den ene efter den anden. Som følge heraf forstår kunden simpelthen ikke, hvad der følger efter under selve processen.
Opgave: Det nytter ikke noget at overbevise kunden om andet; den bedste mulighed er at udvikle en modulær proces til at skabe en hjemmeside i virksomheden baseret på en side-for-side-model.
Universelle design-tokens og komponenter administreres af både udviklere og designere.
Problem: Dette er en almindelig situation, som mange strategier adresserer. Der er mange interessante løsninger, i de fleste tilfælde foreslås det at skabe et designsystem, der styres af en stilguide / biblioteksgeneratorer. Men i vores situation var det simpelthen ikke muligt at tilføje en anden komponent til udviklingsprocessen, som ville give os mulighed for at administrere adgangsniveauer for designere.
Opgave: opbygning af et universelt system, hvor designere, udviklere og ledere kan arbejde synkront uden at forstyrre hinanden.
Nøjagtig udviklingssporing
Problem: Selvom der er mange nyttige værktøjer til rådighed til at spore problemer og måle overordnede fremskridt, er de fleste ikke fleksible eller optimale. Værktøjet kan være nyttigt ved at spare den teamtid, der normalt ville blive brugt på spørgsmål og afklaringer på specifikke opgaver. Det gør også livet lettere for ledere ved at give dem en mere præcis forståelse af hele projektet.
Opgave: Opret et dashboard til at spore fremskridtene for opgaver udført af forskellige teammedlemmer.
værktøjskasse
Efter at have eksperimenteret med forskellige værktøjer, besluttede jeg mig for følgende sæt: Confluence, Jira, Airtable og Abstract. Nedenfor vil jeg afsløre fordelene ved hver.
Confluence
Værktøjets rolle: informations- og ressourcecenter.
Confluences arbejdsområde er relativt nemt at sætte op, har en masse funktioner, integrationer med forskellige apps og har individuelle, tilpasselige skabeloner. Det er ikke en ensartet løsning, men den er ideel som informations- og ressourcecenter. Det betyder, at enhver reference eller teknisk detalje relateret til projektet skal indtastes i databasen.
Værktøjet giver dig mulighed for korrekt at dokumentere hver komponent og alle andre detaljer om projektet.
Den største fordel ved Confluence er tilpasningen af dokumentskabeloner. Derudover kan den bruges til at implementere et enkelt lager af specifikationer og forskellig projektdokumentation, der adskiller deltagernes adgangsniveauer. Nu behøver du ikke bekymre dig om, at du har en gammel version af specifikationen på hånden, som det sker, når du sender dokumenter via e-mail.
Mere information om værktøjet .
Jira
Værktøjets rolle: problemovervågning og opgavestyring.
Jira er et meget kraftfuldt projektplanlægnings- og styringsværktøj. Hoveddelen af funktionaliteten er oprettelsen af tilpassede arbejdsgange. For effektivt at håndtere problemer (hvilket er, hvad vi har brug for), er det værd at være særlig opmærksom på den korrekte brug af anmodningstypen og problemtypen (problemtypen).
Så for at sikre, at udviklere bygger komponenter baseret på det korrekte design, skal de have besked, hver gang noget ændrer sig i designet. Så snart komponenten er opdateret, skal designeren åbne et problem, tildele en ansvarlig udvikler og tildele ham den korrekte problemtype.
Med Jira kan du være sikker på, at absolut alle deltagere i processen (lad mig minde om, i vores tilfælde er der 5–15 af dem) får korrekte opgaver, der ikke farer vild og finder deres bobestyrer.
Få mere at vide om Jira .
Airtable
Værktøjets rolle: komponentstyring og fremdriftstavle.
Airtable er en blanding af regneark og databaser. Alt dette gør det muligt at tilpasse driften af alle de værktøjer, der er diskuteret ovenfor.
Eksempel 1: Komponentstyring
Hvad angår stilguidegeneratoren, er den ikke altid praktisk at bruge - problemet er, at designere ikke kan redigere den. Derudover ville det ikke være en god beslutning at bruge Sketch-komponentbiblioteket, da det har mange begrænsninger. Mest sandsynligt vil du simpelthen ikke være i stand til at bruge dette bibliotek uden for programmet.
Airtable er heller ikke perfekt, men det er bedre end mange andre lignende løsninger. Her er en demo af skabelonen Component Management Table:
Når en udvikler accepterer en designkomponent, evaluerer han den resulterende ABEM ved at registrere komponenten i en tabel. Der er i alt 9 kolonner:
- Navn - navnet på komponenten i henhold til ABEM-princippet.
- Forhåndsvisning - Her placeres enten et skærmbillede eller et billede af den komponent, der er downloadet fra en anden kilde.
- En linket side er et link til en komponents side.
- Underordnet komponent - et link til underordnede komponenter.
- Modifikator - kontrollerer tilstedeværelsen af stilindstillinger og definerer dem (for eksempel aktiv, rød osv.).
- Komponentkategori er en generel kategori (tekst, reklamebillede, sidebjælke).
- Udviklingsstatus - det faktiske udviklingsforløb og dets definition (afsluttet, i gang osv.).
- Ansvarlig - udvikleren, der er ansvarlig for denne komponent.
- Atomniveau er atomkategorien for denne komponent (i henhold til begrebet atomdesign).
- Data kan refereres i samme eller i forskellige tabeller. Forbindelse af prikkerne vil forhindre forvirring ved skalering. Derudover kan dataene filtreres, sorteres og ændres uden problemer.
Eksempel 2: fremskridt i sideudvikling
For at evaluere udviklingen af siden skal du bruge en skabelon, der er skabt specielt til dette formål. Bordet kan tjene både teamets og klientens behov.
Eventuelle oplysninger om siden kan noteres her. Dette er en deadline, et link til InVision-prototypen, en destination, en underordnet komponent. Det bliver straks bemærket, at operationerne er meget bekvemme at udføre, både med hensyn til at dokumentere og opdatere designet, samt status for front-end og back-end udvikling. Desuden udføres disse operationer samtidigt.
Abstrakt
Værktøjets rolle: en enkelt kilde til versionskontrol for designaktiver.
Abstrakt kan kaldes GitHub for aktiver i Sketch, og det sparer designere fra at skulle kopiere og indsætte filer. Den største fordel ved værktøjet er, at det giver et designlager, der fungerer som en "enkelt kilde til sandhed." Designere skal opdatere mastergrenen til den seneste version af det godkendte layout. Derefter skal de underrette udviklerne. Disse bør til gengæld kun arbejde med designeraktiver fra hovedgrenen.
Som konklusion
Efter at vi implementerede den nye udviklingsproces og alle ovennævnte værktøjer, steg hastigheden af vores arbejde mindst to gange. Det er ikke en perfekt løsning, men det er en meget god løsning. Sandt nok, for at det kan fungere, skal du lægge en stor indsats - det kræver "manuelt arbejde" at opdatere og vedligeholde det hele i funktionsdygtig stand.
Skillbox anbefaler:
- Praktisk kursus .
- Online kursus .
- Praktisk årskursus .
Kilde: www.habr.com