Arendusmeeskonna suurendamine väliste inseneride abil koodi kvaliteeti kaotamata

Sissejuhatus

Olulisemad järeldused

1. Kasutage väliseid insenere, kui teie tegevuskava on põhitöötajate jaoks liiga tihe.
2. Kehtestage enne nende liitumist lihtsad kvaliteedijuhised ja põhiline tarnimisprotsess.
3. Võtke välised arendajad tööle selge kontrollnimekirja ja ühe abimehega.
4. Rakendage ühtset reeglistikku, ülevaateid ja mõõdikuid kõigi inseneride jaoks.
5. Kasutage lühikesi kirjalikke uuendusi, et hoida kasvav segatiim ühtsena.

Miks peaksite oma arendusmeeskonda üldse väliste inseneridega laiendama?

Arendusmeeskonda tuleks laiendada väliste inseneridega, kui teie tegevuskava on täis ja teie enda töötajad ei suuda tervislikul viisil sammu pidada. Peamine mõte on lihtne: välised insenerid peaksid lisama kiirust ja oskusi, ilma et see mõjutaks kvaliteeti. Kui nad aitavad teil teha stabiilset tööd, mis tundub turvaline hooldada, on selline korraldus mõistlik. Kui nad lisavad ainult stressi ja juhuslikke muudatusi, on aeg vale.

Paljud tootevaldkonna ettevõtete juhid tunnevad sama survet. Tööde kuhjumine kasvab, tähtajad nihkuvad ja tugevate inseneride palkamine teie linnas võtab kaua aega. Sel hetkel hakkate mõtlema arendusmeeskonna laiendamisele välise abi abil. Võite vaadata väljastpoolt tellitud arendusmeeskonda teises piirkonnas või väiksemat rühma, mis asub teie ajavööndile lähemal. Tegelik küsimus ei ole selles, kas saate välist abi kasutada, vaid selles, millal see toetab teie tegevuskava, mitte ei varja sügavamaid probleeme.

Üks põhjus väliste inseneride kaasamiseks on juurdepääs oskustele, mida teie ettevõttes praegu pole. Võib-olla vajate lühiajalist tuge sellistes valdkondades nagu andmed, mobiilirakendused või uued pilveseadistused. Võib-olla ei soovi te iga uue teema jaoks täiesti uut meeskonda luua. Sel juhul võib tarkvaraarendustiimi suurendamine anda teile paindliku toetuse teie tuumikmeeskonna ümber. Te hoiate põhiteadmised ja suuna oma ettevõttes ning kasutate välist abi selgete ja fokuseeritud tööülesannete jaoks. Igapäevaelus tundub see pigem ühe rahuliku eksperdi lisamisena hõivatud meeskonda kui teise ettevõtte loomisena.

On ka väga põhiline aja ja kulude aspekt. Tugevate inimeste palkamine võib võtta mitu nädalat või isegi kuud, ja selle aja jooksul teie töökogum ei kao kuhugi. Siin võite näha selgeid IT-personali suurendamise eeliseid. Võite tuua sisse lisatööjõudu kindlaksmääratud ajaks ja ulatuseks, samal ajal kui mõtlete pikaajalise töölevõtmise üle. Mõnede meeskondade jaoks tasandab see võimalus nõudluse tipphetki, selle asemel et sundida tegema suurt hüpet püsiva töötajate arvu osas. Selline ülesehitus võimaldab teil testida, mida lisavõimsus teie tootele annab, enne kui muudate kogu oma struktuuri lõplikult.

Võite valida ka erinevaid mudeleid, kuidas need inimesed teie meeskonda liituvad. Töötajate arvu suurendamise mudelis lisate oma meeskonda välisinsenerid ja teie juhid juhendavad nende tööd iga päev. Nearshore-arendusmeeskonna korral töötavad inimesed lähedalasuvas ajavööndis ja saavad tavapärastel tööaegadel osaleda teie kõnedel ja vestlustel. Paljud ettevõtted teevad koostööd kogenud tarkvaraarenduspartneriga, kes juba teab, kuidas teha nearshore-tarkvaraarendust ja sulanduda sisemeeskondadega. Mida lähedasemad on kultuur, ajavöönd ja tööriistad, seda lihtsam on paljudel inimestel tunda end ühe meeskonnana, isegi kui lepingud on erinevad. See ühine alus muudab välistöö loomulikuks, mitte ebakindlaks.

Kuidas valmistada ette koodibaas ja protsessid enne välise arendusmeeskonna lisamist?

Välise arendusmeeskonna lisamiseks valmistute ette, kehtestades selge ja lihtsa aluse oma toote loomiseks ja tarnimiseks. Enne uute inimeste saabumist on vaja ühiseid reegleid, põhilisi tööriistu ja nähtavat töömeetodit. Ilma selle aluseta sõltub iga muudatus isiklikust stiilist ja mälust ning uutel inimestel pole võimalik õiget teed leida. Selle alusega saavad isegi uued inimesed liikuda turvalises ja stabiilses rütmis.

Võite mõelda sellele alusele kui koodi kvaliteedi kaitseraua. Need kaitserauad on lihtsad kontrollid, mille iga muudatus peab läbima, olenemata sellest, kes selle kirjutas. Need võivad hõlmata asjade nimetamist, failide vormingut ja seda, mida tähendab „valmis” iga väikese töö puhul. Kui kaitserauad on kõigile ühesugused, tundub teie toode stabiilne isegi siis, kui meeskond kasvab ja muutub. See muudab lihtsamaks usaldada kogu protsessi, mitte ainult inimesi, keda te juba tunnete.

Samuti on vaja põhilist pideva integratsiooni ja tarnimise torujuhet. See pikk fraas kirjeldab lihtsat ideed. Iga kord, kui keegi muudab koodi, teostab süsteem kontrolli ja aitab viia muudatuse kasutajateni väikeste, ohutute sammudega. See protsess võib toimida ühistel platvormidel ja käivituda iga kord, kui teete muudatuse oma peamises koodivarast. Töötav protsess muudab paljud väikesed muudatused selgeks arenguks, mitte suureks ja hirmutavaks kogumiks. Uued inimesed saavad selle protsessi ühe korra ära õppida ja seejärel seda järgida ilma lisamõtlemiseta.

Testid on selle protsessi oluline osa. Automatiseeritud testimine CI/CD-s tähendab, et teie testid käivituvad ise iga kord, kui keegi jagab uut koodi. Võite alustada lihtsate kontrollidega, mis hõlmavad teie tootes enim kasutatavaid teid. Aja jooksul võite lisada rohkem teste, kui näete, kus vead tavaliselt esinevad. Isegi väike hulk stabiilseid teste annab teile rohkem turvalisust kui suur nimekiri käsitsi tehtavatest kontrollidest, mida keegi õigel ajal ei tee. See lähenemine hoiab asjad reaalsena ja toetab nii sisemisi kui ka väliseid insenere.

See aitab ka vaadata süsteemi vanemaid osi enne, kui palute teistel neid puudutada. Siin tuleb mängu põhiline tehnilise võla haldamine. Tehniline võlg on viis kirjeldada koodi, mis töötab, kuid mida on raske riskivabalt muuta. Võite märkida alad, mis on uute töötajate jaoks ohutud, ja alad, mis vajavad endiselt kogenud töötajate hoolt. Kui teate, kus asuvad riskantsed osad, saate suunata välise arendusmeeskonna esmalt ohutumatesse valdkondadesse. See kaitseb teie toodet ja hoiab uued töötajad eemal varjatud lõksudest.

Aluse viimane osa on lihtne turvalisus ja juurdepääs. Turvaline tarkvaraarenduse elutsükkel kõlab raskepäraselt, kuid see põhineb selgetel sammudel. Annad inimestele ainult vajaliku juurdepääsu, hoiad reaalseid kasutajaandmeid turvaliselt ja käsitled salajasi võtmeid ettevaatlikult. Kirjutad üles ka, mida teha, kui midagi läheb valesti, isegi väikeses mahus. Kui turvalisus on osa tavalisest tööst, saavad välised insenerid sinu protsessiga liituda ilma uute hirmudeta. Sinu juriidiline ja turvalisuse meeskond näevad ka, et see kasv järgib plaani, mitte kiiret lahendust.

Kuidas näeb välja turvaline sisseelamisplaan välistele arendajatele?

Turvaline sisseelamisplaan välistele arendajatele annab neile konteksti, tööriistad ja selged esimesed sammud, ilma et neid kiirustataks sügavasse vette. See peaks tunduma juhendatud teekonnana, kus igal päeval on lihtne ja reaalne eesmärk. Kui plaan on selge, saavad uued inimesed lisada väärtust nädalate, mitte kuude jooksul, ja teie enda meeskond ei tunne end pidevate küsimustega kurnatuna.

Väliste arendajate sisseelamine algab ühisest arusaamast sellest, mida nad esmalt õppima peavad. See hõlmab teie toodet, teie kasutajaid ja teie tavapärast tööviisi. Arendajate sisseelamise kontrollnimekiri võib kõik need punktid ühes kohas kokku koondada. See võib olla lihtne dokument, mida mõlemad pooled saavad avada ja kohandada. Nähtav kontrollnimekiri muudab „Ma arvan, et me oleme neile seda juba öelnud” „Me teame täpselt, mis on tehtud ja mis on järgmine samm”. See väike muudatus vähendab kõigi jaoks palju vaikset stressi.

Siin on üks lihtne nimekiri, mis sobib sageli hästi sellise kontrollnimekirja aluseks:

1. Juurdepääs koodile, tööjälgijale ja peamistele jututubadele.
2. Toote käivitamise sammud sülearvutil või testserveris.
3. Lühike juhend kasutajatele, peamised vood ja olulised ärireeglid.
4. Inimeste nimed, kellelt küsida toote, koodi ja tööriistade kohta.
5. Kaks või kolm väikest, selget ülesannet, mis on valmis esimeseks reaalseteks muudatusteks.

Aitab ka selge kontaktisiku nimetamine. Tehniline juht või vaneminsener võib esimestel nädalatel olla uue töötaja juhendaja. See isik saab vaadata läbi kõik varased muudatused, vastata küsimustele ja selgitada, miks varasemad valikud on sellised, nagu nad on. Lühikesed igapäevased kontrollid, isegi viis minutit vestlusaknas, aitavad asjad õigel kursil hoida. Rahulik mentor ja stabiilsed kontaktpunktid aitavad uue töötaja sisseelamisel rohkem kui suur kõne esimesel päeval. Aja jooksul võite arendusmeeskondade jaoks rohkem uuendusi asünkroonsesse suhtlusse viia, näiteks lühikeste kirjalike märkuste vormis.

Minu kogemuste põhjal on sisseelamise suurim risk vaikne segadus. Uued inimesed kardavad, et küsivad liiga palju, ja vanad meeskonnaliikmed loodavad, et asjad „klapivad” iseenesest. Selge plaan väliste arendajate sisseelamiseks ja üksainus selle plaani omanik muudavad selle pildi. Kui üks inimene vastutab kogu protsessi eest, on võimalik märgata mustreid, parandada nõrku kohti ja muuta iga järgmine sisseelamisvoor sujuvamaks. Mõne kuu pärast muutub plaan korratavaks varaks, mitte uueks väljakutseks iga kord, kui keegi uus lisandub.

Kuidas säilitada koodi kvaliteet segatud arendusmeeskonnas, kui juhite väliseid arendajaid?

Koodi kvaliteeti segatud arendusmeeskonnas säilitate, kasutades kõigi jaoks samu lihtsaid reegleid, kontrolle ja numbreid. Teie standardid peavad kehtima kõigile inseneridele, kui soovite, et toode oleks ühtne ja turvaline süsteem. Kui jagate reeglid lepingutüübi järgi, jagate ka usalduse ja selguse oma meeskonnas.

Segatud arendusmeeskond on rühm, kus sise- ja välisinsenerid töötavad sama toote kallal. Nad võivad asuda erinevates kohtades, kuid neil on ühine töökogum ja koodivaramu. Selline kombinatsioon võib olla väga tugev, kuna ühendab sügava valdkonnaalase teadmise uute vaadetega. Samas võib see olla ka habras, kui iga rühm järgib oma harjumusi. Ilma selgete juhisteta muutub selline kombinatsioon koodiklastriteks, mis tunduvad erinevad ja mille vahel on raske liikuda. See on hetk, mil kvaliteet ja kiirus hakkavad langema.

Siin aitavad lihtsad koodi läbivaatamise parimad tavad. Iga muudatus peaks läbima vähemalt ühe teise isiku läbivaatuse, olenemata sellest, kes selle tegi. Läbivaatamisel tuleks vaadata selgust, turvalisust ja sobivust ülejäänud süsteemiga, mitte ainult stiili. Seda saab toetada kergete tööriistadega, mis skannivad koodi levinud probleemide leidmiseks. Need rutiinid hoiavad väliste arendajate koodi kvaliteedi ülejäänud meeskonnaga samal tasemel rahulikul ja korrataval viisil. Inimesed õpivad üksteiselt ja loovad ühise arusaama sellest, mis on „hea”.

Võite jälgida ka väikest hulka tarkvaraarendustiimi mõõdikuid. Need võivad näidata, kui kaua võtab aega ühe töö lõpetamine, kui palju probleeme jõuab kasutajateni ja kui tihti te tooteid tarnite. Te ei vaja kümneid numbreid. Teil on vaja vaid mõnda, mida saate hõlpsasti lugeda ja arutada. Kui need näitajad püsivad stabiilsena või paranevad, kui te juhite välisarendajaid ja suurendate meeskonda, teate, et teie ülesehitus toetab kvaliteeti. Kui need langevad, on teil varajane signaal oma reeglite, ulatuse või ülesannete kombinatsiooni ülevaatamiseks.

Suhtlusmustrid on sama olulised kui reeglid ja numbrid. Paljud segatud arendusmeeskonnad loetakse ka hajutatud agiilseteks meeskondadeks, kuna inimesed töötavad mitmes kohas või ajavööndis. Nad vajavad arendusmeeskondade jaoks asünkroonset suhtlust, et edusammud ei sõltuks pikkadest kõnedest. Lühikesed kirjalikud uuendused, selged ülesannete märkmed ja lihtsad staatuse märgistused on väga abiks. Head kirjalikud uuendused muudavad kõikidele inseneridele lihtsamaks tootega liitumise, selle jälgimise ja aja jooksul parandamise. Otseülekanded on endiselt olulised, kuid need ei ole enam ainus koht, kus otsuseid tehakse.

Ka väljastpoolt kaasatud inimeste kaasamise viis mõjutab kvaliteeti. Kui neid kohelda eraldi rühmana, mille eesmärgid on ebaselged, ei tunne nad end toote täieliku omanikena. Kui nad lisada olemasolevatesse rühmadesse ühe reeglistiku alusel, saavad nad tegutseda nagu kõik teised meeskonnaliikmed. Mõned ettevõtted kasutavad selleks meeskonna suurendamise mudelit, kus ühendatakse sisemised ja välised inimesed ühe juhi all. Ühised eesmärgid, ühised tööriistad ja ühised ülevaated mõjutavad tarkvaraarenduses koodi kvaliteeti rohkem kui ükski range kontrollidokument. Aja jooksul saate inimeste ja töö kombinatsiooni kohandada, kuid ühine raamistik jääb samaks.