Povečanje razvojne ekipe z zunanjimi inženirji brez izgube kakovosti kode

Uvod

Ključne ugotovitve

1. Zunanje inženirje uporabite, ko je vaš načrt preveč poln za vašo osnovno ekipo.
2. Preden se pridružijo, določite preprosta merila kakovosti in osnovni postopek dostave.
3. Zunanje razvijalce vključite z jasnim seznamom za preverjanje in enim pomočnikom.
4. Uporabljajte enoten niz pravil, pregledov in meril za vse inženirje.
5. Zanašajte se na kratke pisne posodobitve, da bo rastoča mešana ekipa ostala usklajena.

Zakaj bi sploh razširili svojo razvojno ekipo z zunanjimi inženirji?

Razširite svojo razvojno ekipo z zunanjimi inženirji, ko je vaš načrt poln in vaši zaposleni ne morejo več zdravo slediti. Glavna točka je preprosta: zunanji inženirji morajo povečati hitrost in znanje, ne da bi znižali kakovost. Če vam pomagajo pri stalnem delu, ki se zdi varno za vzdrževanje, je takšna ureditev smiselna. Če pa le povečajo stres in naključne spremembe, je časovni okvir napačen.

Mnogi vodje v proizvodnih podjetjih čutijo enak pritisk. Zaostanki se kopičijo, roki se zamikajo, zaposlovanje dobrih inženirjev v vašem mestu pa traja dolgo. V tem trenutku začnete razmišljati o povečanju inženirske ekipe s pomočjo zunanjih sodelavcev. Morda razmišljate o zunanji razvojni ekipi v drugi regiji ali manjši skupini, ki je bližje vašemu časovnemu pasu. Pravo vprašanje ni, ali lahko pritegnete zunanjo pomoč, ampak kdaj bo ta podprla vaš načrt, namesto da bi prikrivala globlje probleme.

Eden od razlogov za povabilo zunanjih inženirjev je dostop do znanj, ki jih trenutno nimate v podjetju. Morda potrebujete kratkoročno podporo na področjih, kot so podatki, mobilne aplikacije ali nove nastavitve v oblaku. Morda ne želite oblikovati popolnoma nove ekipe za vsako novo temo. V tem primeru vam lahko povečanje ekipe za razvoj programske opreme zagotovi prilagodljivo podporo za vašo osnovno skupino. Osnovno znanje in usmeritev ohranite znotraj podjetja, zunanjo pomoč pa uporabite za jasne in osredotočene dele dela. V vsakdanjem življenju je to bolj podobno dodajanju enega mirnega strokovnjaka v zaposleno ekipo kot ustanavljanju drugega podjetja.

Obstaja tudi zelo osnovni vidik časa in stroškov. Zaposlovanje močnih ljudi lahko traja več tednov ali celo mesecev, medtem pa se vaša zaostala dela ne ustavijo. Tukaj lahko jasno vidite prednosti povečanja števila IT-osebja. Lahko pridobite dodatno pomoč za določen čas in obseg, medtem ko razmišljate o dolgoročnem zaposlovanju. Za nekatere ekipe ta možnost izravnava vrhunce povpraševanja, namesto da bi prisilila k velikemu povečanju fiksnega števila zaposlenih. Takšna ureditev vam omogoča, da preizkusite, kaj dodatna zmogljivost pomeni za vaš izdelek, preden za vedno spremenite celotno strukturo.

Izbirate lahko tudi med različnimi modeli, kako se ti ljudje vključijo v vaš svet. V modelu povečanja števila zaposlenih dodate zunanje inženirje v svojo ekipo, njihovo delo pa vsak dan vodijo vaši vodje. V okviru razvojne ekipe v bližini se ljudje nahajajo v podobnem časovnem pasu in se lahko v normalnih urah pridružijo vašim klicem in klepetom. Mnoga podjetja sodelujejo z izkušenim partnerjem za razvoj programske opreme, ki že ve, kako izvajati razvoj programske opreme v bližini in se vključiti v notranje ekipe. Čim bolj so si kultura, časovni pas in orodja podobni, tem lažje je doseči, da se veliko ljudi počuti kot ena ekipa, tudi če se pogodbe razlikujejo. Ta skupna osnova je tista, ki zunanje delo naredi naravno in ne krhko.

Kako pripravite svojo kodno bazo in procese, preden dodate zunanjo razvojno ekipo?

Na zunanjo razvojno ekipo se pripravite tako, da določite jasno in preprosto osnovo za to, kako izdelujete in dostavljate svoj izdelek. Preden pridejo novi ljudje, potrebujete skupna pravila, osnovna orodja in pregleden način dela. Brez te osnove je vsaka sprememba odvisna od osebnega sloga in spomina, novi ljudje pa ne morejo uganiti prave poti. S to osnovo se lahko tudi novi ljudje gibljejo v varnem in enakomernem ritmu.

To osnovo si lahko predstavljate kot varnostne ograje za kodo. Te ograje so preproste kontrole, ki jih mora prestati vsaka sprememba, ne glede na to, kdo jo je napisal. Lahko zajemajo način poimenovanja stvari, način oblikovanja datotek in pomen besede »končano« za vsak majhen del dela. Ko so ograje enake za vse, se vaš izdelek zdi stabilen, tudi če se ekipa širi in spreminja. Tako je lažje zaupati celotnemu toku, ne le ljudem, ki jih že poznate.

Potrebujete tudi osnovni proces neprekinjene integracije in dostave. Ta dolga fraza opisuje preprosto idejo. Vsakič, ko nekdo spremeni kodo, sistem izvede preverjanja in pomaga, da se ta sprememba v majhnih, varnih korakih prenese k uporabnikom. Ta potek lahko deluje na običajnih platformah in se izvaja ob vsakem potiskanju v glavno shrambo kode. Delujoč potek spremeni številne majhne spremembe v jasno linijo napredka namesto v kup velikih, zastrašujočih izdaj. Novi ljudje se lahko enkrat naučijo te poti in jo nato sledijo brez dodatnega ugibanja.

Testi so ključni del te poti. Avtomatizirano testiranje v CI/CD pomeni, da se vaši testi izvajajo samodejno vsakič, ko nekdo deli novo kodo. Začnete lahko s preprostimi preverjanji, ki pokrivajo najpogosteje uporabljane poti v vašem izdelku. Sčasoma lahko dodate več testov, ko ugotovite, kje se pogosto pojavljajo napake. Celo majhen niz stabilnih testov vam daje več varnosti kot ogromen seznam ročnih preverjanj, ki jih nihče ne izvede pravočasno. Ta pristop ohranja stvari realne in podpira tako interne kot zunanje inženirje.

Pomaga tudi pri pregledu starejših delov vašega sistema, preden prosite druge, da se jih dotaknejo. Tu pride v poštev osnovno upravljanje tehničnega dolga. Tehnični dolg je način za opis kode, ki deluje, vendar jo je težko spremeniti brez tveganja. Označite lahko območja, ki so varna za nove ljudi, in območja, ki še vedno potrebujejo skrb vašega najbolj izkušenega osebja. Ko veste, kje so tvegani deli, lahko zunanjo razvojno ekipo najprej usmerite v varnejša območja. To ščiti vaš izdelek in nove ljudi varuje pred skritimi pastmi.

Zadnji del osnove je preprosta varnost in dostop. Varen življenjski cikel razvoja programske opreme zveni težko, vendar temelji na jasnih korakih. Ljudem dodelite le dostop, ki ga potrebujejo, varujete prave uporabniške podatke in skrbno ravnate s skrivnimi ključi. Zapisujete tudi, kaj storiti, ko pride do težav, tudi če so te majhne. Ko je varnost del običajnega dela, se lahko zunanji inženirji pridružijo vašemu procesu, ne da bi vzbudili nove strahove. Vaše pravne in varnostne ekipe tudi vidijo, da ta rast sledi načrtu, ne pa hitri rešitvi.

Kako izgleda varen načrt za vključevanje zunanjih razvijalcev?

Varen načrt za vključevanje zunanjih razvijalcev jim daje kontekst, orodja in jasne prve korake, ne da bi jih prehitro potisnil v globoko vodo. Moral bi biti kot vodeni pot, kjer ima vsak dan preprost in resničen namen. Ko je načrt jasen, lahko novi ljudje dodajo vrednost v nekaj tednih, ne mesecih, vaša ekipa pa se ne počuti izčrpana zaradi nenehnih vprašanj.

Vključevanje zunanjih razvijalcev se začne s skupnim pogledom na to, kaj morajo najprej naučiti. To vključuje vaš izdelek, vaše uporabnike in vaš običajen način dela. Seznam za vključevanje razvijalcev lahko vse te točke združi na enem mestu. Lahko je v obliki preprostega dokumenta, ki ga lahko obe strani odpreta in prilagodita. Vidni seznam spremeni »Mislim, da smo jim to že povedali« v »Točno vemo, kaj je narejeno in kaj sledi«. Ta majhna sprememba vsem prihrani veliko tihega stresa.

Tukaj je en preprost seznam, ki pogosto dobro deluje kot osnova za takšen seznam:

1. Dostop do kode, sledilnika dela in glavnih klepetalnic.
2. Koraki za zagon izdelka na prenosnem računalniku ali testnem strežniku.
3. Kratek vodnik za uporabnike, glavni tokovi in ključna poslovna pravila.
4. Imena oseb, ki jih lahko vprašate o izdelku, kodi in orodjih.
5. Dve ali tri majhne, jasne naloge, pripravljene za prvo pravo spremembo.

Pomaga tudi imenovanje jasne kontaktne osebe. Tehnični vodja ali višji inženir lahko v prvih tednih deluje kot mentor za uvajanje. Ta oseba lahko pregleda vse zgodnje spremembe, odgovarja na vprašanja in pojasni, zakaj so pretekle odločitve takšne, kot so. Kratka dnevna srečanja, tudi petminutna v klepetu, lahko pomagajo, da stvari potekajo po načrtu. Mirni mentor in redni stiki prispevajo več k varnemu uvajanju kot veliki pogovori na prvi dan. Sčasoma lahko več posodobitev prenesete v asinhrono komunikacijo za razvojne ekipe, na primer kratke pisne opombe.

Po mojih izkušnjah je največje tveganje med uvajanjem tiho zmedo. Novi zaposleni se bojijo, da bodo postavljali preveč vprašanj, stari člani ekipe pa upajo, da se bodo stvari same uredile. Jasen načrt za vključevanje zunanjih razvijalcev in en sam odgovorni za ta načrt spremenita to sliko. Ko je ena oseba odgovorna za potek, lahko opazite vzorce, odpravite šibke točke in poskrbite, da bo vsako naslednje vključevanje potekalo gladko. V nekaj mesecih načrt postane ponovljiva prednost, namesto da bi bil vsakič, ko dodate nekoga, nov izziv.

Kako ohranite kakovost kode v mešanem razvojnem timu, ko upravljate zunanje razvijalce?

Kakovost kode v mešanem razvojnem timu ohranjate z uporabo enakih preprostih pravil, pregledov in številk za vse. Vaši standardi morajo veljati za vse inženirje, če želite, da se produkt zdi kot en čist in varen sistem. Ko razdelite pravila po vrsti pogodbe, razdelite tudi zaupanje in jasnost v svojem timu.

Mešana razvojna ekipa je skupina, v kateri notranji in zunanji inženirji delajo na istem izdelku. Morda sedijo na različnih mestih, vendar imajo en skupni backlog in eno shrambo kode. Ta mešanica je lahko zelo močna, ker združuje poglobljeno znanje področja s svežimi pogledi. Lahko pa je tudi krhka, če vsaka skupina sledi svojim navadam. Brez jasnih smernic se ta mešanica spremeni v skupke kode, ki se med seboj razlikujejo in med katerimi je težko prehajati. To je trenutek, ko se kakovost in hitrost začneta odmikati.

Tu pomagajo preproste najboljše prakse pregledovanja kode. Vsaka sprememba mora biti pregledana vsaj še ena oseba, ne glede na to, kdo jo je naredil. Pregledi morajo upoštevati jasnost, varnost in skladnost s preostalim sistemom, ne le slog. To lahko podprete z enostavnimi orodji, ki skenirajo kodo za pogoste probleme. Te rutine ohranjajo kakovost kode zunanjih razvijalcev v skladu s preostalim delom vašega tima na miren, ponovljiv način. Ljudje se učijo drug od drugega in gradijo skupno razumevanje tega, kaj je »dobro«.

Lahko tudi spremljate majhen nabor meril razvojne ekipe programske opreme. Ta lahko pokažejo, koliko časa traja dokončanje dela, koliko težav pride do uporabnikov in kako pogosto izdajate nove različice. Ne potrebujete na desetine številk. Potrebujete le nekaj, ki jih lahko zlahka preberete in o njih razpravljate. Ko te metrike ostanejo stabilne ali se izboljšajo, medtem ko upravljate zunanje razvijalce in širite ekipo, veste, da vaša ureditev podpira kakovost. Če se poslabšajo, imate zgodnji signal, da pregledate svoja pravila, obseg ali kombinacijo nalog.

Komunikacijski vzorci so prav tako pomembni kot pravila in številke. Mnoge mešane razvojne ekipe se štejejo tudi za razpršene agilne ekipe, ker ljudje delajo z več lokacij ali iz različnih časovnih pasov. Potrebujejo asinhrono komunikacijo za razvojne ekipe, da napredek ni odvisen od dolgih telefonskih pogovorov. Kratke pisne posodobitve, jasne opombe o nalogah in preproste oznake za status so v veliko pomoč. Dobre pisne posodobitve vsem inženirjem olajšajo pridružitev, spremljanje in izboljševanje izdelka skozi čas. Pogovori v živo so še vedno pomembni, vendar niso več edini kraj, kjer se sprejemajo odločitve.

Način, kako vključite zunanje ljudi, prav tako vpliva na kakovost. Če jih obravnavate kot ločen tok z nejasnimi cilji, ne bodo čutili polne odgovornosti za izdelek. Če jih dodate v obstoječe ekipe pod enim sklopom pravil, lahko delujejo kot kateri koli drugi član ekipe. Nekatera podjetja za to uporabljajo sistem povečanja ekipe, kjer združujejo notranje in zunanje ljudi pod enim vodjem. Skupni cilji, skupna orodja in skupne ocene prispevajo k kakovosti kode v razvoju programske opreme več kot kateri koli obsežen kontrolni dokument. Sčasoma lahko prilagodite sestavo ljudi in dela, vendar skupni okvir ostane enak.