Izstrādātāju komandas paplašināšana ar ārējiem inženieriem, nezaudējot koda kvalitāti

Ievads

Galvenie secinājumi

1. Izmantojiet ārējos inženierus, ja jūsu ceļvedis ir pārāk pilns jūsu galvenajai komandai.
2. Pirms viņi pievienojas, izveidojiet vienkāršas kvalitātes vadlīnijas un pamata piegādes procesu.
3. Iekļaujiet ārējos izstrādātājus ar skaidru pārbaudes sarakstu un vienu galveno kolēģi.
4. Izmantojiet vienotu noteikumu, pārskatu un rādītāju kopumu visiem inženieriem.
5. Lai nodrošinātu saskaņotību augošajā jauktajā komandā, izmantojiet īsus rakstiskus atjauninājumus.

Kāpēc vispār vajadzētu paplašināt attīstības komandu ar ārējiem inženieriem?

Jums vajadzētu paplašināt savu attīstības komandu ar ārējiem inženieriem, ja jūsu darba plāns ir pilns un jūsu pašu darbinieki nespēj tikt galā ar darbu veselīgā veidā. Galvenais punkts ir vienkāršs: ārējiem inženieriem vajadzētu palielināt ātrumu un prasmes, nesamazinot kvalitātes līmeni. Ja viņi palīdz jums veikt stabilu darbu, kas šķiet drošs uzturēšanai, šāda konfigurācija ir loģiska. Ja viņi tikai rada stresu un nejaušas izmaiņas, laiks nav piemērots.

Daudzi produktu uzņēmumu vadītāji izjūt šo pašu spiedienu. Darbu uzkrājums pieaug, termiņi tiek nokavēti, un spēcīgu inženieru pieņemšana darbā jūsu pilsētā prasa ilgu laiku. Šajā brīdī jūs sākat domāt par inženieru komandas paplašināšanu ar ārējo palīdzību. Jūs varat meklēt ārpakalpojumu attīstības komandu citā reģionā vai mazāku grupu, kas atrodas tuvāk jūsu laika zonai. Patiesais jautājums nav par to, vai jūs varat piesaistīt ārējo palīdzību, bet gan par to, kad tā atbalstīs jūsu darba plānu, nevis slēps dziļākas problēmas.

Viens no iemesliem, kāpēc uzaicināt ārējos inženierus, ir piekļuve prasmēm, kas jums pašlaik nav pieejamas uzņēmumā. Jums var būt nepieciešams īstermiņa atbalsts tādās jomās kā dati, mobilās lietotnes vai jaunas mākoņpakalpojumu konfigurācijas. Jūs varbūt nevēlaties veidot pilnīgi jaunu komandu katrai jaunai tēmai. Šādā gadījumā programmatūras izstrādes komandas paplašināšana var sniegt jums elastīgu atbalsta slāni ap jūsu galveno grupu. Jūs saglabājat galvenās zināšanas un virzienu savā uzņēmumā un izmantojat ārējo palīdzību skaidriem un mērķtiecīgiem darba posmiem. Ikdienā tas vairāk līdzinās viena mierīga eksperta pievienošanai aizņemtai komandai, nevis otrā uzņēmuma izveidei.

Ir arī ļoti būtisks laika un izmaksu aspekts. Spēcīgu darbinieku pieņemšana darbā var aizņemt daudzas nedēļas vai pat mēnešus, un šajā laikā jūsu darba uzkrājums neapstājas. Šeit jūs varat redzēt skaidras IT personāla paplašināšanas priekšrocības. Jūs varat piesaistīt papildu darbiniekus uz noteiktu laiku un apjomu, vienlaikus turpinot domāt par ilgtermiņa pieņemšanu darbā. Dažām komandām šī iespēja izlīdzina pieprasījuma pīķus, nevis liek strauji palielināt fiksēto darbinieku skaitu. Šāda konfigurācija ļauj jums pārbaudīt, kā papildu kapacitāte ietekmē jūsu produktu, pirms jūs maināt visu savu struktūru uz visiem laikiem.

Jūs varat arī izvēlēties dažādus modeļus, kā šie cilvēki pievienojas jūsu komandai. Personāla papildināšanas modelī jūs pievienojat ārējos inženierus savai komandai, un jūsu vadītāji katru dienu vada viņu darbu. Nearshore attīstības komandas modelī cilvēki atrodas tuvu laika zonā un var pievienoties jūsu zvaniem un tērzēšanai normālajā darba laikā. Daudzi uzņēmumi sadarbojas ar pieredzējušu programmatūras attīstības partneri, kas jau zina, kā veikt nearshore programmatūras attīstību un sadarboties ar iekšējām komandām. Jo tuvāka ir kultūra, laika zona un rīki, jo vieglāk ir panākt, ka daudzi cilvēki jūtas kā viena komanda, pat ja līgumi atšķiras. Šī kopīgā bāze ir tas, kas padara ārējo darbu dabisku, nevis trauslu.

Kā sagatavot kodebāzi un procesus, pirms pievienot ārējo izstrādes komandu?

Jūs sagatavojaties ārējai izstrādes komandai, izveidojot skaidru un vienkāršu bāzi tam, kā jūs veidojat un piegādājat savu produktu. Pirms jauno darbinieku ierašanās jums ir nepieciešami kopīgi noteikumi, pamata rīki un redzams darba veids. Bez šīs bāzes katra izmaiņa ir atkarīga no personīgā stila un atmiņas, un jaunajiem darbiniekiem nav iespējas uzminēt pareizo ceļu. Ar šo bāzi pat jauni darbinieki var strādāt drošā un stabilā ritmā.

Šo pamatu var uzskatīt par kvalitātes aizsargbarjeru kodam. Šīs aizsargbarjeras ir vienkāršas pārbaudes, kuras jāiziet katrai izmaiņai, neatkarīgi no tā, kas to ir veicis. Tās var attiekties uz to, kā nosaucat lietas, kā formatējat failus un ko nozīmē "pabeigts" jebkuram mazam darba gabalam. Ja aizsargbarjeras ir vienādas visiem, jūsu produkts šķiet stabils, pat ja komanda aug un mainās. Tas atvieglo uzticēšanos visam procesam, ne tikai cilvēkiem, kurus jau pazīstat.

Jums ir nepieciešama arī pamata nepārtrauktas integrācijas un piegādes sistēma. Šis garš teikums apraksta vienkāršu ideju. Katru reizi, kad kāds maina kodu, sistēma veic pārbaudes un palīdz šo izmaiņu pārnesi uz lietotājiem mazos, drošos solīšos. Šī sistēma var darboties uz kopējām platformām un var darboties katru reizi, kad tiek veikta izmaiņa jūsu galvenajā kodu krātuves. Darbojoša sistēma pārvērš daudzas nelielas izmaiņas tīrā progresā, nevis lielā, biedējošā izlaidumu kaudzē. Jauni darbinieki var vienreiz apgūt šo ceļu un pēc tam to izmantot bez liekas minēšanas.

Testi ir šī ceļa galvenā daļa. Automatizēta testēšana CI/CD nozīmē, ka jūsu testi darbojas patstāvīgi katru reizi, kad kāds dalās ar jaunu kodu. Jūs varat sākt ar vienkāršām pārbaudēm, kas aptver visbiežāk izmantotos ceļus jūsu produktā. Laika gaitā jūs varat pievienot vairāk testu, redzot, kur parasti parādās kļūdas. Pat neliels stabilu testu kopums sniedz jums lielāku drošību nekā milzīgs manuālo pārbaužu saraksts, ko neviens neveic laicīgi. Šī pieeja nodrošina reālistiskumu un atbalsta gan iekšējos, gan ārējos inženierus.

Tā arī palīdz apskatīt vecākas jūsu sistēmas daļas, pirms lūdzat citiem tās mainīt. Šeit nāk talkā pamata tehniskā parāda pārvaldība. Tehniskā parāda ir veids, kā aprakstīt kodu, kas darbojas, bet ir grūti maināms bez riska. Jūs varat atzīmēt zonas, kas ir drošas jauniem darbiniekiem, un zonas, kurām joprojām nepieciešama jūsu pieredzējušāko darbinieku uzmanība. Kad jūs zināt, kur atrodas riskantās daļas, jūs varat vispirms virzīt ārējo izstrādes komandu uz drošākām jomām. Tas aizsargā jūsu produktu un pasargā jaunus darbiniekus no slēptām lamatām.

Pēdējā pamatelementa daļa ir vienkārša drošība un piekļuve. Droša programmatūras izstrādes dzīves cikla izveide var šķist sarežģīta, bet tā balstās uz skaidriem soļiem. Jūs piešķirat cilvēkiem tikai nepieciešamo piekļuvi, nodrošināt reālo lietotāju datu drošību un rūpīgi izturaties pret slepenajiem atslēgām. Jūs arī pierakstāt, ko darīt, ja kaut kas noiet greizi, pat nelielā mērogā. Kad drošība ir daļa no ikdienas darba, ārējie inženieri var pievienoties jūsu procesam, neradot jaunas bažas. Jūsu juridiskā un drošības komanda arī redz, ka šī izaugsme notiek saskaņā ar plānu, nevis kā ātrs risinājums.

Kā izskatās drošs ārējo izstrādātāju integrācijas plāns?

Drošs ārējo izstrādātāju integrācijas plāns sniedz viņiem kontekstu, rīkus un skaidrus pirmos soļus, neuzspiežot viņus dziļā ūdenī. Tam jābūt kā vadītam ceļam, kur katrai dienai ir vienkāršs un reāls mērķis. Ja plāns ir skaidrs, jaunie darbinieki var pievienot vērtību nedēļu, nevis mēnešu laikā, un jūsu komanda nejūtas izsmelta no pastāvīgiem jautājumiem.

Ārējo izstrādātāju integrācija sākas ar kopīgu viedokli par to, ko viņiem vispirms ir jāiemācās. Tas ietver jūsu produktu, lietotājus un jūsu parasto darba veidu. Ievadīšanas pārbaudes saraksts izstrādātājiem var apkopot visus šos punktus vienā vietā. Tas var būt vienkāršs dokuments, ko abas puses var atvērt un pielāgot. Redzams pārbaudes saraksts pārvērš frāzi „Es domāju, ka mēs viņiem to jau teicām” par „mēs precīzi zinām, kas ir izdarīts un kas ir nākamais solis”. Šī nelielā izmaiņa atbrīvo visus no daudzām klusām raizēm.

Šeit ir viens vienkāršs saraksts, kas bieži vien labi darbojas kā pamats šādai pārbaudes saraksta veidošanai:

1. Piekļuve kodam, darba uzraudzības sistēmai un galvenajām tērzēšanas telpām.
2. Soļi, lai palaistu produktu uz klēpjdatora vai testa servera.
3. Īss ceļvedis lietotājiem, galvenajām plūsmām un galvenajiem biznesa noteikumiem.
4. Personu vārdi, kurām jautāt par produktu, kodu un rīkiem.
5. Divi vai trīs nelieli, skaidri uzdevumi, kas ir gatavi pirmajai reālajai izmaiņai.

Palīdz arī norādīt konkrētu kontaktpersonu. Pirmās nedēļas laikā par ievadīšanas palīgu var darboties tehnoloģiju vadītājs vai vecākais inženieris. Šī persona var pārskatīt visas sākotnējās izmaiņas, atbildēt uz jautājumiem un izskaidrot, kāpēc iepriekšējās izvēles izskatās tā, kā izskatās. Īsi ikdienas pārskati, pat piecu minūšu garumā čatā, var palīdzēt notikumiem virzīties pareizajā virzienā. Ramus kolēģis un stabili kontakti nodrošina drošāku ievadīšanu darbā nekā lielas sarunas pirmajā dienā. Laika gaitā jūs varat pārcelt vairāk atjauninājumu uz asinhrono komunikāciju attīstības komandām, piemēram, īsas rakstiskas piezīmes.

Pēc manas pieredzes, lielākais risks ievadīšanas laikā ir klusa neskaidrība. Jaunie darbinieki baidās uzdot pārāk daudz jautājumu, bet vecie komandas locekļi cer, ka viss izveidosies pats no sevis. Skaidrs ārējo izstrādātāju ievadīšanas plāns un viens atbildīgais par šo plānu maina šo situāciju. Kad viena persona ir atbildīga par šo procesu, jūs varat pamanīt modeļus, novērst vājos punktus un padarīt katru nākamo ievadīšanas kārtu vienmērīgāku. Pēc dažiem mēnešiem plāns kļūst par atkārtojamu resursu, nevis par jaunu cīņu katru reizi, kad pievienojat kādu jaunu darbinieku.

Kā uzturēt koda kvalitāti jauktajā izstrādes komandā, ja vadāt ārējos izstrādātājus?

Kodu kvalitāti jauktajā izstrādes komandā uztur, izmantojot vienādus vienkāršus noteikumus, pārbaudes un skaitļus visiem. Jūsu standarti jāpiemēro visiem inženieriem, ja vēlaties, lai produkts būtu kā viena tīra, droša sistēma. Kad sadalāt noteikumus pēc līguma veida, jūs sadalāt arī uzticēšanos un skaidrību komandā.

Jauktā attīstības komanda ir grupa, kurā iekšējie un ārējie inženieri strādā pie viena un tā paša produkta. Viņi var atrasties dažādās vietās, bet viņiem ir viens kopīgs uzkrājums un viena koda krātuve. Šāds maisījums var būt ļoti spēcīgs, jo apvieno padziļinātas zināšanas par jomu ar svaigiem skatījumiem. Tas var būt arī trausls, ja katra grupa seko saviem ieradumiem. Bez skaidras vadības šis maisījums pārvēršas par koda kopām, kas izskatās atšķirīgas un starp kurām ir grūti pārvietoties. Tas ir brīdis, kad kvalitāte un ātrums sāk pazemināties.

Šeit palīdz vienkāršas labākās prakses kodeksa pārskatīšanā. Katra izmaiņa ir jāpārskata vismaz vienai citai personai, neatkarīgi no tā, kas to veicis. Pārskatīšanā ir jāpievērš uzmanība skaidrībai, drošībai un atbilstībai pārējai sistēmai, ne tikai stilam. To var atbalstīt ar vienkāršiem rīkiem, kas skenē kodu, meklējot izplatītākās problēmas. Šīs rutīnas ļauj ārējo izstrādātāju koda kvalitāti saglabāt atbilstošu pārējai komandai mierīgā un atkārtojamā veidā. Cilvēki mācās viens no otra un veido kopīgu izpratni par to, kas ir “labi”.

Jūs varat arī izsekot nelielam programmatūras izstrādes komandas rādītāju kopumam. Tie var parādīt, cik ilgs laiks nepieciešams, lai pabeigtu darbu, cik daudz problēmu sasniedz lietotājus un cik bieži jūs veicat piegādes. Jums nav nepieciešami desmitiem skaitļu. Jums ir nepieciešami tikai daži, kurus varat viegli izlasīt un apspriest. Ja šie rādītāji paliek stabili vai uzlabojas, kamēr jūs vadāt ārējos izstrādātājus un paplašināt komandu, jūs zināt, ka jūsu uzstādījumi atbalsta kvalitāti. Ja tie pasliktinās, jums ir agrīns signāls pārskatīt savus noteikumus, darbības jomu vai uzdevumu kombināciju.

Komunikācijas modeļi ir tikpat svarīgi kā noteikumi un skaitļi. Daudzas jauktas izstrādes komandas tiek uzskatītas par izkliedētām ātrdarbīgām komandām, jo cilvēki strādā no vairākām vietām vai laika joslām. Tām ir nepieciešama asinhronā komunikācija izstrādes komandām, lai progress nebūtu atkarīgs no garām telefonsarunām. Īsi rakstiski atjauninājumi, skaidras uzdevumu piezīmes un vienkāršas statusa atzīmes ir ļoti noderīgas. Labas rakstiskas atjauninājumu ziņas atvieglo visiem inženieriem pievienoties, sekot līdzi un uzlabot produktu laika gaitā. Tiešraides sarunas joprojām ir svarīgas, bet tās vairs nav vienīgā vieta, kur tiek pieņemti lēmumi.

Veids, kādā jūs piesaistāt ārējos cilvēkus, arī ietekmē kvalitāti. Ja jūs tos uzskatāt par atsevišķu plūsmu ar neskaidriem mērķiem, viņi nejutīsies pilnībā atbildīgi par produktu. Ja jūs tos pievienojat esošajām komandām saskaņā ar vienu noteikumu kopumu, viņi var rīkoties kā jebkurš cits komandas loceklis. Dažas uzņēmumi šim nolūkam izmanto komandas paplašināšanas sistēmu, kurā iekšējie un ārējie cilvēki tiek apvienoti zem viena vadītāja. Kopīgi mērķi, kopīgi rīki un kopīgas pārskatīšanas programmatūras izstrādē ietekmē koda kvalitāti vairāk nekā jebkurš smags kontroles dokuments. Laika gaitā jūs varat pielāgot cilvēku un darba kombināciju, bet kopīgā struktūra paliek nemainīga.