ProHoster > Blogi > netin uutisia > Järjestämme tehokkaan työnkulun verkkokehittäjille: Confluence, Airtable ja muut työkalut
Järjestämme tehokkaan työnkulun verkkokehittäjille: Confluence, Airtable ja muut työkalut
Olen työskennellyt front-end-kehittäjänä noin kaksi vuotta ja osallistunut monenlaisten projektien luomiseen. Yksi oppimistani on, että yhteistyö eri kehittäjäryhmien välillä, joilla on sama tavoite, mutta joilla on erilaiset tehtävät ja vastuut, ei ole helppoa.
Yhteistyössä muiden tiimin jäsenten, suunnittelijoiden ja kehittäjien kanssa loin pienille tiimeille (5-15 henkilöä) suunnitellun verkkosivujen luontisyklin. Se sisältää työkaluja, kuten Confluence, Jira, Airtable ja Abstract. Tässä artikkelissa jaan työnkulun järjestämisen ominaisuudet.
Muistutamme sinua:kaikille "Habrin" lukijoille - 10 000 ruplan alennus ilmoittautuessaan mille tahansa Skillbox-kurssille "Habr" -tarjouskoodilla.
Miksi kaikkea tätä tarvitaan?
Vähimmäisryhmä, joka tarvitaan verkkosivuston luomiseen tyhjästä, on suunnittelija, ohjelmoija ja projektipäällikkö. Minun tapauksessani joukkue muodostettiin. Mutta muutaman sivuston julkaisun jälkeen minulle tuli tunne, että siinä on jotain vialla. Joskus emme yksinkertaisesti ymmärtäneet täysin velvollisuuksiamme, ja yhteydenpito asiakkaan kanssa jätti paljon toivomisen varaa. Kaikki tämä hidasti prosessia ja häiritsi kaikkia.
Aloin työskennellä ongelman ratkaisemiseksi.
Google-haku antaa hyviä tuloksia ongelmaamme.
Tehdäkseni työstä visuaalisempaa, tein työnkulkukaavion, joka antaa käsityksen siitä, miten työtä täällä tehdään.
Klikkaa kuvaa avataksesi täyden resoluution.
Tavoitteet ja tavoitteet
Yksi ensimmäisistä tekniikoista, joita päätin testata, oli "kaskadimalli" (Waterfall). Käytin sitä korostamaan ongelmia ja ymmärtämään, kuinka ne ratkaistaan.
Ongelma: Useimmiten asiakas ei arvioi verkkosivuston luomisprosessia modulaarisesti, kuten kehittäjät tekevät. Hän näkee sen tavallisena sivustona, toisin sanoen hän ajattelee yksittäisinä sivuina. Hänen mielestään suunnittelijat ja ohjelmoijat luovat yksittäisiä sivuja yksi toisensa jälkeen. Tämän seurauksena asiakas ei yksinkertaisesti ymmärrä mitä seuraa varsinaisen prosessin aikana.
Tehtävä: Asiakasta ei kannata vakuuttaa toisin, vaan paras vaihtoehto on kehittää yrityksen sisällä modulaarinen prosessi sivukohtaiseen malliin perustuvan verkkosivun luomiseen.
Sekä kehittäjät että suunnittelijat hallinnoivat universaaleja suunnittelutunnuksia ja komponentteja.
Ongelma: Tämä on yleinen tilanne, johon monet strategiat puuttuvat. Mielenkiintoisia ratkaisuja on monia, useimmissa tapauksissa ehdotetaan suunnittelujärjestelmän luomista, jota ohjataan tyylioppaan / kirjastogeneraattoreiden avulla. Mutta meidän tilanteessamme toisen komponentin lisääminen kehitysprosessiin, jonka avulla voisimme hallita suunnittelijoiden käyttöoikeustasoja, ei yksinkertaisesti ollut mahdollista.
Tehtävä: rakentaa universaali järjestelmä, jossa suunnittelijat, kehittäjät ja johtajat voivat työskennellä synkronisesti häiritsemättä toisiaan.
Tarkka kehityksen seuranta
Ongelma: Vaikka käytettävissä on monia hyödyllisiä työkaluja ongelmien seuraamiseen ja yleisen edistymisen mittaamiseen, useimmat eivät ole joustavia tai optimaalisia. Työkalu voi olla hyödyllinen, koska se säästää tiimin aikaa, joka normaalisti kuluisi tiettyjen tehtävien kysymyksiin ja selvennyksiin. Se helpottaa myös esimiesten elämää antamalla heille tarkemman käsityksen koko projektista.
Tehtävä: luo kojelauta seurataksesi eri tiimin jäsenten suorittamien tehtävien edistymistä.
työkalusarja
Kokeilun jälkeen eri työkaluilla päädyin seuraavaan sarjaan: Confluence, Jira, Airtable ja Abstract. Alla paljastan kunkin hyödyt.
yhtymäkohta
Työkalun rooli: tieto- ja resurssikeskus.
Confluencen työtila on suhteellisen helppo asentaa, ja siinä on paljon ominaisuuksia, integrointi eri sovelluksiin ja yksilöllisiä, muokattavissa olevia malleja. Se ei ole yksikokoinen ratkaisu, mutta se on ihanteellinen tieto- ja resurssikeskukseksi. Tämä tarkoittaa, että kaikki hankkeeseen liittyvät viitteet tai tekniset yksityiskohdat on syötettävä tietokantaan.
Työkalun avulla voit dokumentoida oikein kunkin komponentin ja muut projektin tiedot.
Confluencen tärkein etu on asiakirjamallien mukauttaminen. Lisäksi sillä voidaan toteuttaa yksi spesifikaatioiden ja erilaisten projektidokumenttien arkisto, joka erottaa osallistujien käyttöoikeustasot. Nyt sinun ei tarvitse huolehtia siitä, että sinulla on vanha versio spesifikaatiosta käsillä, kuten tapahtuu, kun lähetät asiakirjoja sähköpostitse.
Työkalun rooli: ongelmien seuranta ja tehtävien hallinta.
Jira on erittäin tehokas projektisuunnittelun ja -hallinnan työkalu. Pääosa toiminnallisuudesta on mukautettavien työnkulkujen luominen. Jotta ongelmat voitaisiin hallita tehokkaasti (jota me tarvitsemme), on syytä kiinnittää erityistä huomiota pyyntötyypin ja ongelmatyypin (ongelmatyypin) oikeaan käyttöön.
Jotta kehittäjät pystyisivät rakentamaan komponentteja oikean suunnitelman perusteella, heille on ilmoitettava aina, kun jokin suunnittelussa muuttuu. Heti kun komponentti on päivitetty, suunnittelijan on avattava ongelma, määritettävä vastuullinen kehittäjä ja määritettävä hänelle oikea ongelmatyyppi.
Jiran avulla voit olla varma, että ehdottoman kaikki prosessiin osallistujat (muistutan, että meillä niitä on 5-15) saavat oikeat tehtävät, jotka eivät eksy ja löytävät toteuttajansa.
Työkalun rooli: komponenttien hallinta ja edistymiskortti.
Airtable on sekoitus laskentataulukoita ja tietokantoja. Kaikki tämä mahdollistaa kaikkien edellä käsiteltyjen työkalujen toiminnan mukauttamisen.
Esimerkki 1: Komponenttien hallinta
Mitä tulee tyyliopasgeneraattoriin, se ei ole aina kätevää käyttää - ongelma on, että suunnittelijat eivät voi muokata sitä. Lisäksi ei olisi hyvä päätös käyttää Sketch-komponenttikirjastoa, koska sillä on monia rajoituksia. Todennäköisesti et yksinkertaisesti voi käyttää tätä kirjastoa ohjelman ulkopuolella.
Airtable ei myöskään ole täydellinen, mutta se on parempi kuin monet muut vastaavat ratkaisut. Tässä on esittely Component Management Table -mallista:
Kun kehittäjä hyväksyy suunnittelukomponentin, hän arvioi tuloksena olevan ABEM:n kirjaamalla komponentin taulukkoon. Sarakkeita on yhteensä 9:
Nimi - komponentin nimi ABEM-periaatteen mukaisesti.
Esikatselu – tähän sijoitetaan joko kuvakaappaus tai kuva toisesta lähteestä ladatusta komponentista.
Linkitetty sivu on linkki komponentin sivulle.
Lapsikomponentti - linkki lapsikomponentteihin.
Modifier - tarkistaa tyylivaihtoehtojen olemassaolon ja määrittää ne (esimerkiksi aktiivinen, punainen jne.).
Komponenttiluokka on yleinen luokka (teksti, mainoskuva, sivupalkki).
Kehityksen tila - todellinen kehityksen edistyminen ja sen määritelmä (valmis, käynnissä jne.).
Vastuullinen - kehittäjä, joka on vastuussa tästä komponentista.
Atomitaso on tämän komponentin atomiluokka (atomisuunnittelun käsitteen mukaan).
Tiedot voidaan viitata samassa tai eri taulukoissa. Pisteiden yhdistäminen estää sekaannukset skaalattaessa. Lisäksi tiedot voidaan suodattaa, lajitella ja muuttaa ilman ongelmia.
Esimerkki 2: sivun kehityksen edistyminen
Sivun kehityksen edistymisen arvioimiseksi tarvitset mallin, joka on luotu erityisesti tätä tarkoitusta varten. Pöytä voi palvella sekä joukkueen itsensä että asiakkaan tarpeita.
Kaikki sivua koskevat tiedot voidaan merkitä tänne. Tämä on määräaika, linkki InVision-prototyyppiin, kohde, alikomponentti. Välittömästi huomaa, että toiminnot ovat erittäin käteviä suorittaa niin suunnittelun dokumentoinnissa ja päivittämisessä kuin etu- ja taustakehityksen tilan suhteen. Lisäksi nämä toiminnot suoritetaan samanaikaisesti.
Abstrakti
Työkalun rooli: yksi suunnitteluresurssien versionhallintalähde.
Abstractia voidaan kutsua Sketchin resurssien GitHubiksi, ja se säästää suunnittelijoita tiedostojen kopioimisesta ja liittämisestä. Työkalun tärkein etu on, että se tarjoaa suunnitteluvaraston, joka toimii "yksittäisenä totuuden lähteenä". Suunnittelijoiden on päivitettävä päähaara hyväksytyn asettelun uusimpaan versioon. Sen jälkeen heidän on ilmoitettava siitä kehittäjille. Niiden puolestaan tulisi toimia vain päätoimialan suunnittelijoiden resurssien kanssa.
Johtopäätöksenä
Kun otimme käyttöön uuden kehitysprosessin ja kaikki edellä mainitut työkalut, työmme nopeus nousi ainakin kaksinkertaiseksi. Se ei ole täydellinen ratkaisu, mutta se on erittäin hyvä. Totta, jotta se toimisi, sinun on ponnisteltava paljon - se vaatii "manuaalista työtä" sen päivittämiseksi ja pitämiseksi toimintakunnossa.