Ek werk al vir ongeveer twee jaar as 'n front-end ontwikkelaar en het deelgeneem aan die skepping van 'n wye verskeidenheid projekte. Een van die lesse wat ek geleer het, is dat samewerking tussen verskillende spanne ontwikkelaars wat dieselfde doelwit deel, maar verskillende take en verantwoordelikhede het, nie maklik is nie.
In oorleg met ander spanlede, ontwerpers en ontwikkelaars het ek 'n webwerf-skeppingsiklus geskep wat ontwerp is vir klein spanne (5-15 mense). Dit sluit gereedskap soos Confluence, Jira, Airtable en Abstract in. In hierdie artikel sal ek die kenmerke van die organisering van die werkvloei deel.
Skillbox beveel aan: Twee-jaar praktiese kursus .
Ons herinner: vir alle lesers van "Habr" - 'n afslag van 10 000 roebels wanneer u inskryf vir enige Skillbox-kursus met behulp van die "Habr"-promosiekode.
Hoekom is dit alles nodig?
Die minimum span wat nodig is om 'n webwerf van nuuts af te skep, is 'n ontwerper, programmeerder en projekbestuurder. In my geval is die span gevorm. Maar na die vrystelling van 'n paar webwerwe, het ek die gevoel gekry dat daar iets fout is daarmee. Soms het ons eenvoudig nie ons verantwoordelikhede ten volle verstaan nie, en kommunikasie met die kliënt het veel te wense oorgelaat. Dit alles het die proses vertraag en almal gesteur.
Ek het begin werk om die probleem op te los.
'n Google-soektog gee goeie resultate oor ons probleem.
Om die werk wat gedoen word meer visueel te maak, het ek 'n werkvloeidiagram geskep wat 'n begrip gee van hoe werk hier gedoen word.
Klik op die prent om in volle resolusie oop te maak.
Doelwitte en doelwitte
Een van die eerste tegnieke wat ek besluit het om te toets, was die “cascade model” (Waterval). Ek het dit gebruik om probleme uit te lig en te verstaan hoe om dit op te los.
Probleem: Meestal evalueer die kliënt nie die webwerf-skeppingsproses modulêr soos ontwikkelaars doen nie. Hy sien dit as 'n gereelde webwerf, dit wil sê hy dink in terme van individuele bladsye. Na sy mening skep ontwerpers en programmeerders individuele bladsye, een na die ander. Gevolglik verstaan die kliënt eenvoudig nie wat volg wat tydens die werklike proses nie.
Taak: Daar is geen sin om die kliënt anders te oortuig nie; die beste opsie is om 'n modulêre proses te ontwikkel vir die skep van 'n webwerf binne die maatskappy gebaseer op 'n bladsy-vir-bladsy-model.
Universele ontwerptokens en komponente word deur beide ontwikkelaars en ontwerpers bestuur.
Probleem: Dit is 'n algemene situasie wat baie strategieë aanspreek. Daar is baie interessante oplossings, in die meeste gevalle word voorgestel om 'n ontwerpstelsel te skep wat beheer word deur 'n stylgids / biblioteekopwekkers. Maar in ons situasie was dit eenvoudig nie moontlik om nog 'n komponent by die ontwikkelingsproses by te voeg wat ons in staat sou stel om toegangsvlakke vir ontwerpers te bestuur nie.
Taak: bou van 'n universele stelsel waarin ontwerpers, ontwikkelaars en bestuurders sinchronies kan werk sonder om met mekaar in te meng.
Akkurate ontwikkelingsopsporing
Probleem: Alhoewel daar baie nuttige gereedskap beskikbaar is om probleme op te spoor en algehele vordering te meet, is die meeste nie buigsaam of optimaal nie. Die instrument kan nuttig wees deur die spantyd te bespaar wat normaalweg aan vrae en verduidelikings oor spesifieke take bestee sou word. Dit maak ook die lewe vir bestuurders makliker deur hulle 'n meer akkurate begrip van die hele projek te gee.
Taak: skep 'n dashboard om die vordering van take wat deur verskillende spanlede uitgevoer word, na te spoor.
Stel gereedskap
Nadat ek met verskillende gereedskap geëksperimenteer het, het ek op die volgende stel besluit: Confluence, Jira, Airtable en Abstract. Hieronder sal ek die voordele van elkeen openbaar.
Samevloeiing
Rol van die instrument: inligting- en hulpbronsentrum.
Confluence se werkspasie is relatief maklik om op te stel, het baie funksies, integrasies met verskillende toepassings, en het individuele, aanpasbare sjablone. Dit is nie 'n een-grootte-pas-almal-oplossing nie, maar dit is ideaal as 'n inligting- en hulpbronsentrum. Dit beteken dat enige verwysing of tegniese detail met betrekking tot die projek in die databasis ingevoer moet word.
Die instrument laat jou toe om elke komponent en enige ander besonderhede oor die projek behoorlik te dokumenteer.
Die grootste voordeel van Confluence is die aanpassing van dokumentsjablone. Daarbenewens kan dit gebruik word om 'n enkele bewaarplek van spesifikasies en verskeie projekdokumentasie te implementeer, wat die toegangsvlakke van deelnemers skei. Nou hoef jy nie bekommerd te wees dat jy 'n ou weergawe van die spesifikasie op jou hande het nie, soos wat gebeur wanneer jy dokumente per e-pos stuur.
Meer inligting oor die instrument .
jira
Rol van die instrument: probleemmonitering en taakbestuur.
Jira is 'n baie kragtige instrument vir projekbeplanning en bestuur. Die hoofdeel van die funksionaliteit is die skepping van aanpasbare werkstrome. Om kwessies doeltreffend te bestuur (dit is wat ons nodig het), is dit die moeite werd om spesiale aandag te skenk aan die korrekte gebruik van die versoektipe en kwessietipe (kwessietipe).
Dus, om seker te maak dat ontwikkelaars komponente bou gebaseer op die korrekte ontwerp, moet hulle elke keer in kennis gestel word wanneer iets in die ontwerp verander. Sodra die komponent opgedateer is, moet die ontwerper 'n kwessie oopmaak, 'n verantwoordelike ontwikkelaar toewys, en aan hom die korrekte kwessietipe toewys.
Met Jira kan jy seker wees dat absoluut alle deelnemers aan die proses (laat ek jou herinner, in ons geval is daar 5–15 van hulle) korrekte take ontvang wat nie verlore raak en hul eksekuteur vind nie.
Kom meer te wete oor Jira .
Airtable
Rol van die instrument: komponentbestuur en vorderingsbord.
Airtable is 'n mengsel van sigblaaie en databasisse. Dit alles maak dit moontlik om die werking van al die gereedskap wat hierbo bespreek is, aan te pas.
Voorbeeld 1: Komponentbestuur
Wat die stylgidsgenerator betref, is dit nie altyd gerieflik om te gebruik nie - die probleem is dat ontwerpers dit nie kan redigeer nie. Daarbenewens sal dit nie 'n goeie besluit wees om die Sketch-komponentbiblioteek te gebruik nie, aangesien dit baie beperkings het. Heel waarskynlik sal jy eenvoudig nie hierdie biblioteek buite die program kan gebruik nie.
Airtable is ook nie perfek nie, maar dit is beter as baie ander soortgelyke oplossings. Hier is 'n demonstrasie van die komponentbestuurtabel-sjabloon:
Wanneer 'n ontwikkelaar 'n ontwerpkomponent aanvaar, evalueer hy die gevolglike ABEM deur die komponent in 'n tabel aan te teken. Daar is altesaam 9 kolomme:
- Naam - die naam van die komponent volgens die ABEM-beginsel.
- Voorskou - Dit is waar óf 'n skermskoot óf 'n prent van die komponent wat van 'n ander bron afgelaai is, geplaas word.
- 'n Gekoppelde bladsy is 'n skakel na 'n komponent se bladsy.
- Kind komponent - 'n skakel na kind komponente.
- Wysiger - kontroleer vir die teenwoordigheid van stylopsies en definieer hulle (byvoorbeeld aktief, rooi, ens.).
- Komponentkategorie is 'n algemene kategorie (teks, promosieprent, sybalk).
- Ontwikkelingstatus - die werklike ontwikkelingsvordering en die definisie daarvan (voltooi, aan die gang, ens.).
- Verantwoordelik - die ontwikkelaar wat verantwoordelik is vir hierdie komponent.
- Atoomvlak is die atoomkategorie van hierdie komponent (volgens die konsep van atoomontwerp).
- Daar kan na data in dieselfde of in verskillende tabelle verwys word. Deur die kolletjies te verbind, sal verwarring tydens skaal voorkom. Daarbenewens kan die data sonder enige probleme gefiltreer, gesorteer en verander word.
Voorbeeld 2: vordering met bladsyontwikkeling
Om die vordering van bladsyontwikkeling te evalueer, benodig jy 'n sjabloon wat spesifiek vir hierdie doel geskep is. Die tafel kan beide die behoeftes van die span self en die kliënt dien.
Enige inligting oor die bladsy kan hier aangeteken word. Dit is 'n sperdatum, 'n skakel na die InVision-prototipe, 'n bestemming, 'n kinderkomponent. Dit word dadelik opmerklik dat die bewerkings baie gerieflik is om uit te voer, beide met betrekking tot die dokumentering en opdatering van die ontwerp, sowel as die status van front-end en back-end ontwikkeling. Boonop word hierdie operasies gelyktydig uitgevoer.
Abstract
Rol van die instrument: 'n enkele bron van weergawebeheer vir ontwerpbates.
Abstract kan die GitHub vir bates in Sketch genoem word, en dit spaar ontwerpers om lêers te kopieer en te plak. Die grootste voordeel van die instrument is dat dit 'n ontwerpbewaarplek bied wat dien as 'n "enkele bron van waarheid." Ontwerpers moet die meestertak opdateer na die nuutste weergawe van die goedgekeurde uitleg. Daarna moet hulle die ontwikkelaars in kennis stel. Dié moet op hul beurt net met ontwerperbates van die hooftak werk.
As gevolgtrekking
Nadat ons die nuwe ontwikkelingsproses en al die gereedskap hierbo genoem geïmplementeer het, het die spoed van ons werk minstens twee keer toegeneem. Dit is nie 'n perfekte oplossing nie, maar dit is 'n baie goeie een. Dit is waar, om dit te laat werk, moet jy baie moeite doen - dit verg "handwerk" om dit alles in werkende toestand op te dateer en te onderhou.
Skillbox beveel aan:
- Praktiese kursus .
- Aanlyn kursus .
- Praktiese jaarkursus .
Bron: will.com