Olen töötanud esiotsa arendajana umbes kaks aastat ning osalenud väga erinevate projektide loomisel. Üks õppetund, mille sain, on see, et koostöö erinevate arendajameeskondade vahel, kellel on sama eesmärk, kuid neil on erinevad ülesanded ja vastutus, ei ole lihtne.
Teiste meeskonnaliikmete, disainerite ja arendajatega konsulteerides koostasin veebilehe loomise tsükli, mis on mõeldud väikestele meeskondadele (5-15 inimest). See sisaldab selliseid tööriistu nagu Confluence, Jira, Airtable ja Abstract. Selles artiklis jagan töövoo korraldamise funktsioone.
Skillbox soovitab: Kaheaastane praktiline kursus .
Tuletame meelde: kõigile "Habr" lugejatele - allahindlus 10 000 rubla, kui registreerute mis tahes Skillboxi kursusele, kasutades sooduskoodi "Habr".
Miks seda kõike vaja on?
Veebilehe nullist loomiseks vajalik minimaalne meeskond on disainer, programmeerija ja projektijuht. Minu puhul moodustati meeskond. Kuid pärast paari saidi avaldamist tekkis tunne, et sellega on midagi valesti. Mõnikord ei saanud me lihtsalt oma kohustustest lõpuni aru ja kliendiga suhtlemine jättis soovida. Kõik see aeglustas protsessi ja häiris kõiki.
Hakkasin probleemi lahendamisega tegelema.
Google'i otsing annab meie probleemile häid tulemusi.
Tehtud töö visuaalsemaks muutmiseks koostasin töövoo diagrammi, mis annab ülevaate, kuidas siin tööd tehakse.
Täiseraldusvõimega avamiseks klõpsake pildil.
Eesmärgid ja eesmärgid
Üks esimesi tehnikaid, mida otsustasin katsetada, oli "kaskaadimudel" (Waterfall). Kasutasin seda probleemide esiletõstmiseks ja nende lahendamise mõistmiseks.
Probleem: enamasti ei hinda klient veebilehe loomise protsessi modulaarselt, nagu seda teevad arendajad. Ta tajub seda tavalise saidina, see tähendab, et ta mõtleb üksikute lehtedena. Tema arvates loovad disainerid ja programmeerijad üksteise järel üksikuid lehti. Selle tulemusena ei saa klient lihtsalt aru, mis millele järgneb tegeliku protsessi käigus.
Ülesanne: Klienti pole mõtet veenda vastupidises, parim variant on ettevõttesisese veebilehe loomise modulaarne protsess lehekülgede kaupa.
Universaalseid disainimärke ja komponente haldavad nii arendajad kui ka disainerid.
Probleem: see on tavaline olukord, mida paljud strateegiad käsitlevad. Huvitavaid lahendusi on palju, enamasti tehakse ettepanek luua disainisüsteem, mida juhib stiilijuhend/teegi generaatorid. Kuid meie olukorras ei olnud arendusprotsessi veel ühe komponendi lisamine, mis võimaldaks meil hallata disainerite juurdepääsutasemeid, lihtsalt võimalik.
Ülesanne: luua universaalne süsteem, milles disainerid, arendajad ja juhid saavad töötada sünkroonselt ilma üksteist segamata.
Täpne arengu jälgimine
Probleem. Kuigi probleemide jälgimiseks ja üldise edu mõõtmiseks on saadaval palju kasulikke tööriistu, pole enamik neist paindlikud ega optimaalsed. Tööriist võib olla kasulik, kuna säästab meeskonna aega, mis tavaliselt kulub konkreetsete ülesannete küsimustele ja selgitustele. Samuti muudab see juhtide elu lihtsamaks, andes neile kogu projektist täpsema ülevaate.
Ülesanne: loo armatuurlaud, et jälgida erinevate meeskonnaliikmete ülesannete edenemist.
Tööriistade komplekt
Pärast erinevate tööriistadega katsetamist otsustasin järgmise komplekti järgi: Confluence, Jira, Airtable ja Abstract. Allpool kirjeldan igaühe eeliseid.
Liitumiskoht
Tööriista roll: teabe- ja ressursikeskus.
Confluence'i tööruumi on suhteliselt lihtne seadistada, sellel on palju funktsioone, integratsioonid erinevate rakendustega ja individuaalsed kohandatavad mallid. See ei ole universaalne lahendus, kuid see sobib ideaalselt teabe- ja ressursikeskuseks. See tähendab, et kõik projektiga seotud viited või tehnilised üksikasjad tuleb sisestada andmebaasi.
Tööriist võimaldab teil korralikult dokumenteerida iga komponendi ja kõik muud projekti üksikasjad.
Confluence'i peamine eelis on dokumendimallide kohandamine. Lisaks saab seda kasutada ühtse spetsifikatsioonide ja erinevate projektidokumentide hoidla rakendamiseks, eraldades osalejate juurdepääsutasemed. Nüüd ei pea te muretsema, et teil on käes spetsifikatsiooni vana versioon, nagu juhtub siis, kui saadate dokumente meili teel.
Lisateave tööriista kohta .
Jira
Tööriista roll: probleemide jälgimine ja ülesannete haldamine.
Jira on väga võimas projekti planeerimise ja juhtimise tööriist. Funktsionaalsuse põhiosa moodustab kohandatavate töövoogude loomine. Probleemide tõhusaks haldamiseks (mida me vajamegi) tasub erilist tähelepanu pöörata päringu tüübi ja probleemi tüübi (probleemi tüübi) õigele kasutamisele.
Seega, veendumaks, et arendajad ehitavad komponente õige projekti alusel, tuleb neid teavitada iga kord, kui projektis midagi muutub. Niipea kui komponent on värskendatud, peab disainer avama probleemi, määrama vastutava arendaja, määrates talle õige probleemi tüübi.
Jiraga võid olla kindel, et absoluutselt kõik protsessis osalejad (tuletan meelde, meie puhul on neid 5–15) saavad õiged ülesanded, mis ei eksi ära ja leiavad oma täitja.
Lisateave Jira kohta .
Airtable
Tööriista roll: komponentide haldamine ja edenemise tahvel.
Airtable on segu arvutustabelitest ja andmebaasidest. Kõik see võimaldab kohandada kõigi eespool käsitletud tööriistade tööd.
Näide 1: komponentide haldus
Mis puutub stiilijuhiste generaatorisse, siis seda pole alati mugav kasutada – probleem on selles, et disainerid ei saa seda redigeerida. Lisaks poleks hea otsus kasutada Sketchi komponentide teeki, kuna sellel on palju piiranguid. Tõenäoliselt ei saa te lihtsalt seda teeki väljaspool programmi kasutada.
Airtable pole ka täiuslik, kuid see on parem kui paljud teised sarnased lahendused. Siin on komponentide haldustabeli malli demo:
Kui arendaja võtab disainikomponendi vastu, hindab ta saadud ABEM-i, salvestades komponendi tabelisse. Kokku on 9 veergu:
- Nimi - komponendi nimetus ABEM põhimõtte järgi.
- Eelvaade – see on koht, kuhu paigutatakse teisest allikast alla laaditud komponendi ekraanipilt või pilt.
- Lingitud leht on link komponendi lehele.
- Alamkomponent – link alamkomponentidele.
- Modifier – kontrollib stiilivalikute olemasolu ja määrab need (näiteks aktiivne, punane jne).
- Komponendi kategooria on üldkategooria (tekst, reklaampilt, külgriba).
- Arengu staatus – tegelik arenduskäik ja selle määratlus (lõpetatud, pooleli jne).
- Vastutav – selle komponendi eest vastutav arendaja.
- Aatomitasand on selle komponendi aatomikategooria (vastavalt aatomi disaini kontseptsioonile).
- Andmeid saab viidata samas või erinevates tabelites. Punktide ühendamine väldib skaleerimisel segadust. Lisaks saab andmeid probleemideta filtreerida, sorteerida ja muuta.
Näide 2: lehe arendamise edenemine
Lehe arendamise edenemise hindamiseks vajate spetsiaalselt selleks otstarbeks loodud malli. Laud võib rahuldada nii meeskonna enda kui ka kliendi vajadusi.
Siia saab märkida igasuguse teabe lehe kohta. See on tähtaeg, link InVisioni prototüübile, sihtkoht, alamkomponent. Kohe hakkab silma, et toiminguid on väga mugav teha nii kujunduse dokumenteerimise ja uuendamise kui ka esi- ja tagaarenduse staatuse osas. Pealegi tehakse neid toiminguid samaaegselt.
Abstraktne
Tööriista roll: disainivarade versioonikontrolli üks allikas.
Abstracti võib Sketchi varade jaoks nimetada GitHubiks ja see säästab disainereid failide kopeerimise ja kleepimise eest. Tööriista peamine eelis on see, et see pakub disainihoidla, mis toimib "ainsa tõeallikana". Disainerid peavad värskendama põhiharu kinnitatud paigutuse uusimale versioonile. Pärast seda peavad nad sellest arendajaid teavitama. Need omakorda peaksid töötama ainult põhiharu disainerivaradega.
Kokkuvõtteks
Pärast uue arendusprotsessi ja kõigi ülalnimetatud tööriistade juurutamist kasvas meie töö kiirus vähemalt kaks korda. See ei ole ideaalne lahendus, kuid see on väga hea. Tõsi, selle toimimiseks peate palju pingutama - selle värskendamiseks ja töökorras hoidmiseks on vaja "käsitsi tööd".
Skillbox soovitab:
- Praktiline kursus .
- Veebikursus .
- Praktilise aasta kursus .
Allikas: www.habr.com