Kuinka ja miksi ei-insinöörejä opetetaan käyttämään GitHubia Threadissa

Threadilla yksi keskeisistä vakaumuksistamme on, että tekniikka mahdollistaa suuria muutoksia. Tämä on tärkeää tuotteellemme, mutta se on myös tärkeää, kuinka toimimme sisäisesti.

Tämän työskentelytavan takia yritämme edustaa kaikkea tietoa - tuotteita, mittoja, tyylejä, toimittajia, varastomme sijainteja, tukea lippujen päätöslauselmia ja monia muita asioita, joista et koskaan edes ajatellut.

Kaikkien näiden tietomallien kustannukset edellyttävät tietä yritykselle, joka käyttää niitä tietojen ylläpitämiseen. Tämä tarkoittaa editointirajapintojen rakentamista validoinnilla, tietokannan suunnittelulla ja käyttöliittymällä. Usein meillä ei vain ole aikaa tehdä tämä - uudet ominaisuudet ovat etusijalla, ja lisäksi insinööri voi päivittää vain muutama datatiedosto tarvittaessa oikein?

Vaikka tämä on lyhyellä aikavälillä huomattavasti nopeampi ratkaisu, insinöörin on kontekstissa poistettava työnsä, seurattava julkaisun menemistä ulos ja varmistettava, että mikään ei mene vikaan - että kaikki vahingoittaa tuottavuutta. Ehkä tärkeämpää on kuitenkin se, että henkilö, joka tarvitsee päivitetyt tiedot, ei enää ole koko prosessin omistuksessa ja luottaa jonkun toisen aikatauluun.

Viime kädessä tämä prosessi voi olla hyödyllinen ominaisuuden saamiseksi ovesta nopeasti, mutta aiheuttaa aivan liian paljon kitkaa toimimaan pitkällä aikavälillä.

Parempi ratkaisu

Muistan, kun GitHub avasi ensimmäisen kerran web-editorin - minusta ei ollut vaikuttunut. Miksi kukaan muokkaisi koodia selaimessa? Miksi käyttäisin editoria, joka pystyi muuttamaan vain yhden tiedoston kohden? Hyvin vuosia myöhemmin olen tajunnut, etten ole toimittajan kohderyhmä.

Thread opettaa nyt säännöllisesti suunnittelutiimin ulkopuolisille niille, miten ne voivat osallistua tietokantaamme GitHub-web-käyttöliittymän kautta, jotta he voivat hallita päivittääkseen tietoja, joita he tarvitsevat toimiakseen tehokkaasti.

Meillä on nyt ollut pääkoodikoodissamme enemmän tekijöitä, jotka ovat ei-teknisissä tehtävissä, kuin kaikilla insinööreillä ja urakoitsijoilla, jotka ovat myötävaikuttaneet vuosien mittaan.

Onko se toiminut?

Tuoteryhmän insinöörinä voin keskittää pyrkimyksesi rakentaa ominaisuuksia, jotka hyödyttävät asiakkaitamme ja siirtää tietoja, sen sijaan, että rakentaisin enemmän CRUD-rajapintoja. Pystyn myös lähettämään A / B-testit nopeammin, koska voimme usein ohittaa testiversion sisäiset työkalut, jotta editoidaan tietojen siirtämistä datatiedostojen kautta aluksi. Kun olemme tulleet projektin toimitusvaiheeseen, voimme sitten laittaa aikaa muokkausrajapintoihin, koska meillä ei ole vain käsitys ominaisuuden arvosta, vaan myös parempi käsitys siitä, kuinka sisäiset käyttäjät haluavat käyttöliittymät toimimiseen.

Se ei myöskään rajoitu datatiedostoihin; monet thread.com-sivuston sivut ovat pääosin staattista HTML-koodia, sivut, kuten toimitus UKK, palautuskäytäntö tai ehdot. Oppimalla GitHubin käytön operaatiotiimimme voi pitää nämä ajan tasalla kysymättä apua. Lahjatiimimme kykenee myös muokkaamaan työpaikkasivumme reagoimalla päivittäin yleisiin kysymyksiin, jotka nousevat esiin puhuttaessa ehdokkaiden kanssa.

Kaikki tämä tarkoittaa, että suunnittelutiimin ulkopuolella olevat tiimimme jäsenet voivat olla paljon enemmän omistautuneita työlleen ja heillä on vähemmän kitkaa tehdä muutoksia, jotka heidän kokemuksensa mukaan heille on välttämätöntä.

Kuinka teemme sen?

Ensimmäinen asia, jonka teemme, on ajaa GitHub-opetusohjelmia aina uudelleen, kun meillä on muutama uusi aloittelija opetettavaksi. Käsittelemme arkiston perusasioita vertaamalla sitä dokumenttien tarkistushistorioihin Google-dokumenteissa, mitä tarkoittaa tiedoston lähettämistä ja mitä haara on. Puhumme näistä vain korkeatasoisilla tavoilla, koska emme kata komentoriviliittymää lainkaan nykyisessä opetusmuodossa.

Seuraavaksi käydään läpi kuinka muokata tiedostoa GitHub-web-käyttöliittymässä, miten kirjoittaa sitoutumisviesti, mikä on vetämispyyntö ja mitä Jenkinsin rakennustilan raportointi tarkoittaa.

Viimeiseksi pyydämme muita kuin teknisiä avustajia valitsemaan Slackissa käytettävissä olevan insinöörin, joka painaa yhdistämispainiketta, kun rakennus on vihreä.

Olemme kohdanneet ongelmia

Kaiken kaikkiaan mielestämme tämä on valtava voitto koko joukkueelle. Suunnittelemme jatkaa koulutusta ja rohkaista lisää osallistujia kasvaessaan, mutta olemme muuttaneet prosessiamme hieman, kun tämä on kehittynyt.

Ensinnäkin, olemme käyttäneet GitHub-rooleja ja lukittuja sivukonttoreita estämään vahingossa tapahtuvat sitoumukset hallita. GitHub-verkkorajapinta ei ole erityisen selvä henkilölle, joka ei ole yhtä perehtynyt versiohallintaan ja erityisesti sivukonttoreihin, milloin sitoumus tapahtuu isäntähaaraan tai uuteen haaraan. Threadissa pääkonttorimme on jatkuvasti käytössä ilman manuaalista väliintuloa, mikä johti useiden sitoumusten lähtemiseen, jotka rikkoivat sivuston ja aiheuttivat seisokkeja.

Kuten kaikista seisokkiasioista, meillä oli virheetön 5 Whys ja tajusimme, että vaikka jälkikäteen olisimme voineet tarttua näihin ongelmiin yksikkötesteillä, jotka suoritettiin ennen käyttöönottoa, emme todennäköisesti saalis kaikkea, joten suojattujen oksien käyttöönotto koodin tarkistamisen kannustamiseksi oli kevyt. tapa ratkaista ongelma.

Toiseksi, jonkin verran vastauksena tähän ongelmaan, olemme alkaneet kirjoittaa joitain yksikkötestejä, jotka vain tarkistavat datatiedostojen tietojen rakenteen tai tarkistaa, että kaikki Djangon mallitiedostot jäsentävät onnistuneesti kelvollisina malleina. Erityisesti datatiedostojen tapauksessa nämä eivät yleensä olisi jotain, mitä odottaisimme testaavan, mutta koska haluamme nyt tiedostojen muokattavan ihmisille, jotka eivät tiedä koodia, ne voivat olla käteviä tarttua yksinkertaisiin virheisiin .

Viimeiseksi, koska käytämme tyypillisesti Python-tiedostoja tiedostoihin, olemme havainneet, että syntaksi ei ole erityisen intuitiivinen ja että siihen voi tutustua. Tämän ratkaisemiseksi olemme laatineet kirjalliset asiakirjat, joissa on hiukan yksityiskohtaisempi kuvaus kuin jos ne olisi kirjoitettu insinöörille. Tämä dokumentaatio on myös repo-tilassa ja kaikkien muokattavissa, joten rohkaisemme muita kuin insinöörejä päivittämään ja selkeyttämään opastuksiaan opiessaan ja opettamaan toisiamme kuinka muokata tiettyjä sivuston osia.

Siirtyä eteenpäin

Katsomme, että tämä kokeilu on menestys ja jatkamme sitä lähitulevaisuudessa. Suunnittelemme datatiedostojen muokattavuuden, kun yritämme sisällyttää itse tiedostoihin yksityiskohtaiset ohjeet, mahdollisesti myös kopioitavat / liitettävät esimerkit.

Yritämme jo tehdä testivirheistämme informatiivisia virheviestejä, joissa on yksityiskohtaisia ​​tietoja siitä, kuinka voimme korjata, missä voimme, mutta testitulosten tulkinnan monimutkaisuuden vuoksi emme tällä hetkellä altista Jenkinsiä ei-teknisille ryhmän jäsenille, vaikka he teknisesti kirjaudu sisään sisäänkirjautumisen yhteydessä. Tämä on kenties seuraava tilaisuus parantaa osallistumiskokemusta ja jotain, jota voimme kokeilla seuraavassa erässä uusia aloittelijoita, jotka käyvät läpi oppaan.

Lopuksi kehotan kaikkia kehittäjiä selvittämään, onko yrityksissäsi mahdollisuuksia saada muita kuin teknisiä tiimin jäseniä osallistumaan koodipohjaisiisi. Tuottavuudella on etuja molemmilla osapuolilla, enemmän empaattisuutta joukkueiden välillä ja vahvempi omistautumisen tunne työstä niille, jotka eivät enää ole riippuvaisia ​​kehittäjistä tehdä muutoksia heidän puolestaan. Vähentynyt kitka tarkoittaa myös lyhyempiä palautussyklejä, jotka voivat olla muuttumattomia siihen, mitä muut voivat saavuttaa työssään, kaikki ilman korkeita kustannuksia kehitysrajoille rajapintojen muokkaamisessa.