Kūrėjų komandos didinimas pasitelkiant išorės inžinierius neprarandant kodo kokybės

Įvadas

Svarbiausi dalykai

1. Naudokite išorinius inžinierius, kai jūsų pagrindinei komandai nepakanka laiko įgyvendinti visus planus.
2. Prieš jiems prisijungiant, nustatykite paprastas kokybės apsaugos priemones ir pagrindinį pristatymo procesą.
3. Įtraukite išorinius programuotojus naudodami aiškų kontrolinį sąrašą ir vieną patikimą pagalbininką.
4. Taikykite vieną bendrą taisyklių, peržiūrų ir rodiklių rinkinį visiems inžinieriams.
5. Naudokitės trumpais rašytiniais atnaujinimais, kad auganti mišri komanda dirbtų suderintai.

Kodėl iš pradžių turėtumėte plėsti savo kūrimo komandą, įtraukdami išorinius inžinierius?

Jūs turėtumėte plėsti savo kūrimo komandą, įtraukdami išorinius inžinierius, kai jūsų planas yra pilnas, o jūsų darbuotojai negali jo įgyvendinti sveikingu būdu. Pagrindinis dalykas yra paprastas: išoriniai inžinieriai turėtų padidinti greitį ir įgūdžius, nesumažindami kokybės lygio. Jei jie padeda jums atlikti nuolatinį darbą, kurį saugu išlaikyti, tokia struktūra yra prasminga. Jei jie tik padidina stresą ir atsitiktinius pokyčius, tai nėra tinkamas laikas.

Daugelis produktų kompanijų vadovų jaučia tą patį spaudimą. Užduočių sąrašas auga, terminai vėluoja, o stiprių inžinierių įdarbinimas jūsų mieste užtrunka ilgai. Tuo metu pradedate galvoti apie inžinierių komandos plėtrą su išorės pagalba. Galite ieškoti išorės kūrimo komandos kitame regione arba mažesnės grupės, esančios arčiau jūsų laiko zonos. Tikrasis klausimas yra ne tai, ar galite pasitelkti išorinę pagalbą, bet kada ji padės jūsų planui, o ne paslėps gilesnes problemas.

Viena iš priežasčių, kodėl verta pasikviesti išorės inžinierius, yra galimybė pasinaudoti įgūdžiais, kurių šiuo metu neturite savo kompanijoje. Galbūt jums reikalinga trumpalaikė pagalba tokiose srityse kaip duomenys, mobiliosios programėlės ar naujos debesų konfigūracijos. Galbūt nenorite kurti visiškai naujos komandos kiekvienai naujai temai. Tokiu atveju programinės įrangos kūrimo komandos papildymas gali suteikti jums lanksčią pagalbą jūsų pagrindinei komandai. Pagrindines žinias ir kryptį išlaikote savo įmonėje, o išorinę pagalbą naudojate aiškiems ir konkretiems darbo etapams. Kasdieniame gyvenime tai labiau primena vieno ramaus eksperto priėmimą į užimtą komandą, o ne antros įmonės kūrimą.

Taip pat yra labai paprastas laiko ir išlaidų aspektas. Savarankiškas stiprių žmonių įdarbinimas gali užtrukti daug savaičių ar net mėnesių, o per tą laiką jūsų užduočių sąrašas nesibaigia. Čia galite aiškiai matyti IT personalo papildymo privalumus. Galite pasamdyti papildomų darbuotojų nustatytam laikui ir apimčiai, tuo tarpu toliau galvojate apie ilgalaikį įdarbinimą. Kai kurioms komandoms šis variantas išlygina paklausos pikus, užuot priverstų smarkiai padidinti fiksuotą darbuotojų skaičių. Tokia struktūra leidžia jums išbandyti, ką papildomi pajėgumai duoda jūsų produktui, prieš galutinai keičiant visą struktūrą.

Taip pat galite pasirinkti skirtingus modelius, kaip šie žmonės prisijungs prie jūsų komandos. Personalo papildymo modelyje į savo komandą įtraukiate išorės inžinierius, o jūsų vadovai kasdien vadovauja jų darbui. Artimosios pakrantės kūrimo komandos struktūroje žmonės dirba artimoje laiko juostoje ir gali prisijungti prie jūsų skambučių ir pokalbių įprastomis darbo valandomis. Daugelis įmonių dirba su patyrusiais programinės įrangos kūrimo partneriais, kurie jau žino, kaip vykdyti artimosios pakrantės programinės įrangos kūrimą ir integruotis į vidines komandas. Kuo labiau kultūra, laiko juosta ir įrankiai yra panašūs, tuo lengviau daugeliui žmonių jaustis kaip viena komanda, net jei sutartys skiriasi. Ši bendra bazė leidžia išoriniam darbui atrodyti natūraliu, o ne trapiu.

Kaip parengti kodų bazę ir procesus prieš įtraukiant išorinę kūrimo komandą?

Pasiruoškite išorinei kūrimo komandai nustatydami aiškią ir paprastą bazę, kaip kuriate ir pristatote savo produktą. Prieš atvykstant naujiems žmonėms, jums reikia bendrų taisyklių, pagrindinių įrankių ir matomo darbo būdo. Be šios bazės, kiekvienas pokytis priklauso nuo asmeninio stiliaus ir atminties, o nauji žmonės neturi galimybės atspėti teisingo kelio. Turėdami šią bazę, net ir nauji žmonės gali dirbti saugiu ir pastoviu ritmu.

Šį pagrindą galite laikyti kokybės apsauginėmis tvorelėmis kodui. Šios tvorelės yra paprasti patikrinimai, kuriuos turi išlaikyti kiekvienas pakeitimas, nesvarbu, kas jį parašė. Jos gali apimti tai, kaip pavadinate dalykus, kaip formatuojate failus ir ką reiškia „baigtas“ bet kokiam mažam darbui. Kai tvorelės visiems yra vienodos, jūsų produktas atrodo stabilus, net jei komanda auga ir keičiasi. Tai leidžia lengviau pasitikėti visu procesu, o ne tik žmonėmis, kuriuos jau pažįstate.

Jums taip pat reikalingas pagrindinis nuolatinės integracijos ir pristatymo procesas. Šis ilgas žodžių junginys apibūdina paprastą idėją. Kiekvieną kartą, kai kas nors pakeičia kodą, sistema atlieka patikrinimus ir padeda tą pakeitimą perduoti vartotojams mažais, saugiais žingsniais. Šis procesas gali vykti bendrose platformose ir gali būti vykdomas kiekvieną kartą, kai įkeliate į pagrindinę kodo saugyklą. Veikiantis procesas paverčia daugelį mažų pakeitimų aiškia pažanga, o ne dideliu, bauginančiu išleidimų krūva. Nauji žmonės gali vieną kartą išmokti šį kelią ir tada juo eiti be papildomų spėliojimų.

Testai yra svarbi šio kelio dalis. Automatiniai testai CI/CD reiškia, kad jūsų testai vykdomi automatiškai kiekvieną kartą, kai kas nors pasidalina nauju kodu. Galite pradėti nuo paprastų patikrinimų, kurie apima dažniausiai naudojamus jūsų produkto kelius. Laikui bėgant galite pridėti daugiau testų, kai pamatysite, kur dažniausiai atsiranda klaidos. Net nedidelis stabilių testų rinkinys suteikia daugiau saugumo nei didžiulis rankinių patikrinimų sąrašas, kurio niekas nespėja laiku atlikti. Šis požiūris užtikrina realistiškumą ir padeda tiek vidiniams, tiek išoriniams inžinieriams.

Jis taip pat padeda peržiūrėti senesnes jūsų sistemos dalis, prieš prašydami kitų jas keisti. Čia į pagalbą ateina pagrindinis techninio įsiskolinimo valdymas. Techninis įsiskolinimas yra būdas apibūdinti kodą, kuris veikia, bet yra sunku pakeisti be rizikos. Galite pažymėti zonas, kurios yra saugios naujiems žmonėms, ir zonas, kurioms vis dar reikia patyrusių darbuotojų priežiūros. Žinodami, kur yra rizikingos dalys, galite nukreipti išorinę kūrimo komandą pirmiausia į saugesnes sritis. Tai apsaugo jūsų produktą ir apsaugo naujus žmones nuo paslėptų spąstų.

Paskutinė bazės dalis yra paprastas saugumas ir prieiga. Saugus programinės įrangos kūrimo ciklas skamba sudėtingai, bet jis remiasi aiškiais žingsniais. Žmonėms suteikiate tik jiems reikalingą prieigą, saugote tikrus naudotojų duomenis ir atsargiai elgiatės su slaptaisiais raktais. Taip pat užrašote, ką daryti, kai kas nors nepavyksta, net ir nedidelio masto atveju. Kai saugumas yra įprasto darbo dalis, išoriniai inžinieriai gali prisijungti prie jūsų proceso nesukeldami naujų baimių. Jūsų teisinės ir saugumo komandos taip pat mato, kad šis augimas vyksta pagal planą, o ne yra greitas sprendimas.

Kaip atrodo saugus išorės kūrėjų įtraukimo planas?

Saugus išorės kūrėjų įtraukimo planas suteikia jiems kontekstą, įrankius ir aiškius pirmuosius žingsnius, neskatindamas jų skubėti į gilų vandenį. Tai turėtų būti tarsi vadovaujamas kelias, kur kiekviena diena turi paprastą ir realų tikslą. Kai planas yra aiškus, nauji žmonės gali pridėti vertės per kelias savaites, o ne mėnesius, o jūsų komanda nesijaučia išsekusi dėl nuolatinių klausimų.

Išorės kūrėjų įdarbinimas prasideda nuo bendro supratimo apie tai, ko jiems reikia išmokti pirmiausia. Tai apima jūsų produktą, vartotojus ir įprastą darbo būdą. Įdarbinimo kontrolinis sąrašas kūrėjams gali apimti visus šiuos punktus vienoje vietoje. Jis gali būti paprastas dokumentas, kurį abi pusės gali atidaryti ir koreguoti. Matomas kontrolinis sąrašas paverčia „Manau, kad mes jiems tai jau pasakėme“ į „Mes tiksliai žinome, kas jau padaryta ir kas bus toliau“. Šis nedidelis pokytis pašalina daug tylaus streso visiems.

Čia pateikiamas vienas paprastas sąrašas, kuris dažnai puikiai tinka kaip tokio sąrašo pagrindas:

1. Prieiga prie kodo, darbo sekimo sistemos ir pagrindinių pokalbių kambarių.
2. Veiksmai, kaip paleisti produktą nešiojamajame kompiuteryje arba bandomajame serveryje.
3. Trumpas vadovas vartotojams, pagrindiniai procesai ir pagrindinės verslo taisyklės.
4. Asmenų, kuriuos galima paklausti apie produktą, kodą ir įrankius, pavardės.
5. Dvi ar trys nedidelės, aiškios užduotys, parengtos pirmam realiam pokyčiui.

Taip pat padeda paskirti aiškų kontaktinį asmenį. Technologijų vadovas arba vyresnysis inžinierius gali būti įdarbinimo partneris pirmosiomis savaitėmis. Šis asmuo gali peržiūrėti visus ankstyvus pakeitimus, atsakyti į klausimus ir paaiškinti, kodėl ankstesni sprendimai atrodo taip, kaip atrodo. Trumpi kasdieniniai patikrinimai, net penkių minučių pokalbiai pokalbių programoje, gali padėti išlaikyti viską tinkama linkme. Ramus padėjėjas ir nuolatiniai kontaktiniai taškai labiau padeda saugiai įsitraukti į darbą nei didelė kalba pirmą dieną. Laikui bėgant, galite perkelti daugiau atnaujinimų į asinchroninę komunikaciją su kūrimo komandomis, pavyzdžiui, trumpas rašytines pastabas.

Iš savo patirties galiu pasakyti, kad didžiausias įdarbinimo rizikos veiksnys yra tylus sumišimas. Nauji žmonės bijo, kad klausia per daug, o senieji komandos nariai tikisi, kad viskas susiklostys savaime. Aiški įdarbinimo išorės programuotojų planas ir vienas atsakingas asmuo už tą planą pakeičia šią situaciją. Kai vienas asmuo yra atsakingas už šį procesą, galima pastebėti tendencijas, ištaisyti silpnąsias vietas ir padaryti kiekvieną kitą įdarbinimo etapą sklandesnį. Per kelis mėnesius planas tampa pakartojamu turtu, o ne nauja kova kiekvieną kartą, kai įdarbinate ką nors naujo.

Kaip išlaikyti kodo kokybę mišrioje kūrimo komandoje, kai vadovaujate išorės kūrėjams?

Kodų kokybę mišrioje kūrimo komandoje išlaikote taikydami visiems vienodus paprastus taisykles, patikrinimus ir skaičius. Jei norite, kad produktas būtų vientisa, saugi sistema, jūsų standartai turi būti taikomi visiems inžinieriams. Kai taisykles suskirstote pagal sutarties tipą, taip pat suskirstote pasitikėjimą ir aiškumą komandoje.

Mišri programavimo komanda yra grupė, kurioje vidiniai ir išoriniai inžinieriai dirba prie to paties produkto. Jie gali sėdėti skirtingose vietose, bet dalijasi vienu užduočių sąrašu ir vienu kodo saugyklos. Šis mišinys gali būti labai stiprus, nes jame derinamos gilios srities žinios ir naujos perspektyvos. Jis taip pat gali būti trapus, jei kiekviena grupė laikosi savo įpročių. Be aiškių gairių, šis mišinys virsta skirtingais kodo klasteriais, tarp kurių sunku judėti. Tai momentas, kai kokybė ir greitis pradeda nukrypti.

Čia padeda paprastos gerosios kodų peržiūros praktikos. Kiekvienas pakeitimas turėtų būti peržiūrėtas bent vieno kito asmens, nesvarbu, kas jį padarė. Peržiūros metu turėtų būti vertinamas aiškumas, saugumas ir suderinamumas su likusia sistemos dalimi, o ne tik stilius. Tai galite paremti lengvais įrankiais, kurie nuskaito kodą ieškodami dažniausiai pasitaikančių problemų. Šios procedūros leidžia išorės kūrėjų kodo kokybę išlaikyti lygią su likusios komandos kodo kokybe ramiai ir pakartotinai. Žmonės mokosi vieni iš kitų ir kuria bendrą supratimą apie tai, kas yra „gerai“.

Taip pat galite stebėti nedidelį programinės įrangos kūrimo komandos rodiklių rinkinį. Jie gali parodyti, kiek laiko užtrunka užbaigti darbą, kiek problemų pasiekia vartotojus ir kaip dažnai jūs išleidžiate produktą. Jums nereikia dešimčių skaičių. Jums reikia tik kelių, kuriuos galite lengvai perskaityti ir aptarti. Kai šie rodikliai išlieka stabilūs arba gerėja, o jūs valdote išorinius kūrėjus ir plečiate komandą, žinote, kad jūsų sistema palaiko kokybę. Jei jie pablogėja, turite ankstyvas signalas peržiūrėti savo taisykles, apimtį arba užduočių derinį.

Komunikacijos modeliai yra tokie pat svarbūs kaip taisyklės ir skaičiai. Daugelis mišrių kūrimo komandų taip pat laikomos paskirstytomis agiliomis komandomis, nes žmonės dirba iš kelių vietų ar laiko juostų. Joms reikalinga asinchroninė komunikacija, kad pažanga nepriklausytų nuo ilgų pokalbių. Trumpi rašytiniai atnaujinimai, aiškios užduočių pastabos ir paprastos būsenos žymės labai padeda. Geros rašytinės ataskaitos palengvina visiems inžinieriams prisijungti, sekti ir tobulinti produktą laikui bėgant. Gyvi pokalbiai vis dar svarbūs, bet jie nebėra vienintelė vieta, kur priimami sprendimai.

Kokybę taip pat lemia tai, kaip įtraukiate išorinius žmones. Jei juos traktuosite kaip atskirą srautą su neaiškiais tikslais, jie nesijaus visiškai atsakingi už produktą. Jei juos įtrauksite į esamas komandas pagal vieną taisyklių rinkinį, jie galės elgtis kaip bet kuris kitas komandos narys. Kai kurios įmonės tam naudoja komandos papildymo modelį, kur vidiniai ir išoriniai žmonės dirba kartu po vienu vadovu. Bendri tikslai, bendri įrankiai ir bendros peržiūros programinės įrangos kūrimo srityje labiau prisideda prie kodo kokybės nei bet koks griežtas kontrolės dokumentas. Laikui bėgant galite koreguoti žmonių ir darbo derinį, bet bendras pagrindas lieka tas pats.