Külső mérnökökkel való bővítés a fejlesztőcsapat méretnövelése a kódminőség romlása nélkül

Bevezetés

Főbb tanulságok

1. Használjon külső mérnököket, ha az útiterv túl tele van a magcsapat számára.
2. Állítson fel egyszerű minőségbiztosítási korlátokat és egy alapvető szállítási folyamatot, mielőtt csatlakoznának.
3. A külső fejlesztőket egyértelmű ellenőrzőlistával és egy segítő társával vezesse be.
4. Alkalmazzon egy közös szabályrendszert, értékeléseket és mérőszámokat minden mérnök számára.
5. Rövid írásbeli frissítésekkel tartsa összehangban a növekvő vegyes csapatot.

Miért érdemes külső mérnökökkel bővíteni a fejlesztői csapatot?

A fejlesztői csapatot külső mérnökökkel akkor érdemes bővíteni, ha a fejlesztési terv tele van, és a saját munkatársak nem tudnak egészséges módon lépést tartani. A lényeg egyszerű: a külső mérnököknek gyorsabbá és képzettebbé kell tenniük a csapatot anélkül, hogy csökkentenék a minőségi színvonalat. Ha segítenek stabil, biztonságosan karbantartható munkát végezni, akkor a felállás értelmes. Ha csak stresszt és véletlenszerű változásokat okoznak, akkor nem ez a megfelelő időpont.

Sok termékgyártó vállalat vezetője érez hasonló nyomást. A lemaradás növekszik, a határidők csúsznak, és a városban jó mérnököket felvenni hosszú időbe telik. Ekkor kezd el gondolkodni a mérnöki csapat külső segítségével történő bővítésén. Megnézhet egy másik régióban működő kiszervezett fejlesztői csapatot, vagy egy kisebb csoportot, amely közelebb van az Ön időzónájához. A valódi kérdés nem az, hogy bevonhat-e külső segítséget, hanem az, hogy az mikor támogatja a fejlesztési tervét, és mikor rejti el a mélyebb problémákat.

Az egyik ok, amiért külső mérnököket hívunk be, az, hogy hozzáférhetünk olyan készségekhez, amelyekkel jelenleg nem rendelkezünk. Lehet, hogy rövid távú támogatásra van szükségünk olyan területeken, mint az adatok, a mobilalkalmazások vagy az új felhőalapú beállítások. Lehet, hogy nem akarunk minden új témához egy teljesen új csapatot felépíteni. Ebben az esetben a szoftverfejlesztő csapat bővítése rugalmas támogatást nyújthat a magcsoportunk számára. A vállalatnál belül tartja az alapvető tudást és irányvonalat, és külső segítséget vesz igénybe a világos és fókuszált munkákhoz. A mindennapi életben ez inkább úgy tűnik, mintha egy nyugodt szakértőt adna egy elfoglalt csapathoz, mint mintha egy második vállalatot hozna létre.

Van egy nagyon alapvető idő- és költségszempont is. Erős emberek felvétele önállóan több hetet vagy akár hónapokat is igénybe vehet, és ezalatt az idő alatt a felhalmozódott munkák nem állnak meg. Itt láthatja a személyzet bővítésének egyértelmű előnyeit. Határozott időre és hatókörre vehet fel további munkaerőt, miközben továbbra is a hosszú távú felvételeken gondolkodik. Egyes csapatok számára ez a lehetőség kiegyenlíti a kereslet csúcsait, ahelyett, hogy a fix létszámot nagy ugrással növelnék. Ez a fajta felállás lehetővé teszi, hogy kipróbálja, mit jelent a termékének a többletkapacitás, mielőtt véglegesen megváltoztatná az egész struktúrát.

Különböző modellek közül is választhat, hogy ezek az emberek hogyan csatlakozzanak a csapatához. A személyzetbővítési modellben külső mérnököket vesz fel a saját csapatába, és a vezetői irányítják a mindennapi munkájukat. A nearshore fejlesztői csapat felépítésében az emberek egy közeli időzónában ülnek, és normál munkaidőben csatlakozhatnak a hívásokhoz és csevegésekhez. Sok vállalat tapasztalt szoftverfejlesztő partnerrel dolgozik, aki már tudja, hogyan kell nearshore szoftverfejlesztést végezni, és beilleszkedni a belső csapatokba. Minél közelebb állnak egymáshoz a kultúra, az időzóna és az eszközök, annál könnyebb sok embert egy csapatnak érezni, még akkor is, ha a szerződések eltérőek. Ez a közös alap teszi a külső munkát természetessé, ahelyett, hogy törékenynek éreznék.

Hogyan készíted elő a kódbázist és a folyamatokat, mielőtt külső fejlesztői csapatot vonnál be?

A külső fejlesztői csapatra úgy készülhet fel, hogy világos és egyszerű alapot hoz létre a termék fejlesztésére és szállítására vonatkozóan. Szüksége van közös szabályokra, alapvető eszközökre és látható munkamódszerekre, mielőtt az új emberek megérkeznek. Ezen alap nélkül minden változás a személyes stílustól és a memóriától függ, és az új embereknek nincs módjuk kitalálni a helyes utat. Ezzel az alapokkal még a friss szemek is biztonságos és egyenletes ritmusban tudnak haladni.

Ezt az alapot a kód minőségének biztosítékaként lehet elképzelni. Ezek a biztosítékok egyszerű ellenőrzések, amelyeken minden változásnak át kell esnie, függetlenül attól, hogy ki írta. Kiterjedhetnek a nevek megadására, a fájlok formázására és arra, hogy mit jelent a „kész” egy-egy kisebb munkadarab esetében. Ha a biztosítékok mindenki számára azonosak, akkor a termék stabilnak tűnik, még akkor is, ha a csapat növekszik és változik. Ez megkönnyíti a teljes folyamatba vetett bizalmat, nem csak azokra az emberekre, akiket már ismer.

Szükség van egy alapvető folyamatos integrációs és szállítási folyamatra is. Ez a hosszú kifejezés egy egyszerű ötletet ír le. Valahányszor valaki megváltoztatja a kódot, a rendszer ellenőrzéseket futtat, és kis, biztonságos lépésekben segíti a változás eljutását a felhasználókhoz. Ez a folyamat közös platformokon is működhet, és minden egyes push esetén futtatható a fő kódtáradban. A működő folyamat sok apró szerkesztést alakít át tiszta, egyenes haladássá, ahelyett, hogy nagy, ijesztő kiadások halmazává válna. Az új emberek egyszer megtanulhatják ezt az utat, majd további találgatások nélkül követhetik.

A tesztek kulcsfontosságúak ebben a folyamatban. Az automatizált tesztelés a CI/CD-ben azt jelenti, hogy a tesztek önállóan futnak minden alkalommal, amikor valaki új kódot oszt meg. Kezdhet egyszerű ellenőrzésekkel, amelyek a termék leggyakrabban használt útjait fedik le. Idővel további teszteket adhat hozzá, ahogy látja, hol jelennek meg a hibák. Még egy kis, stabil tesztkészlet is nagyobb biztonságot nyújt, mint egy hatalmas lista kézi ellenőrzésekkel, amelyeket senki sem futtat le időben. Ez a megközelítés reális marad, és támogatja mind a belső, mind a külső mérnököket.

Segít abban is, hogy megvizsgálja a rendszer régebbi részeit, mielőtt másokat kérne meg azok módosítására. Itt jön be a képbe az alapvető technikai adósságkezelés. A technikai adósság olyan kódot jelöl, amely működik, de kockázat nélkül nehéz módosítani. Megjelölheted azokat a területeket, amelyek új emberek számára biztonságosak, és azokat, amelyek még mindig a legtapasztaltabb munkatársak gondoskodását igénylik. Ha tudod, hol vannak a kockázatos részek, akkor először a külső fejlesztőcsapatot irányíthatod a biztonságosabb területek felé. Ez védi a termékedet, és távol tartja az új embereket a rejtett csapdáktól.

Az alap utolsó része az egyszerű biztonság és hozzáférés. A biztonságos szoftverfejlesztési életciklus nehéznek tűnik, de egyértelmű lépéseken alapul. Csak a szükséges hozzáférést adja meg az embereknek, a valódi felhasználói adatokat biztonságban tartja, és a titkos kulcsokat óvatosan kezeli. Leírja azt is, hogy mit kell tenni, ha valami baj történik, még akkor is, ha az csak kis mértékű. Ha a biztonság a normális munka része, a külső mérnökök új félelmek nélkül csatlakozhatnak a folyamatához. A jogi és biztonsági csapatai is látják, hogy ez a növekedés egy tervet követ, nem pedig egy gyors megoldást.

Hogyan néz ki egy biztonságos beilleszkedési terv külső fejlesztők számára?

A külső fejlesztők számára kidolgozott biztonságos beilleszkedési terv kontextust, eszközöket és egyértelmű első lépéseket ad nekik anélkül, hogy mély vízbe dobná őket. Olyan útmutatásnak kell lennie, amelynek minden napja egyszerű és valós céllal rendelkezik. Ha a terv egyértelmű, az új emberek hetek alatt, nem hónapok alatt tudnak hozzáadott értéket teremteni, és a saját csapata nem érzi magát kimerültnek a folyamatos kérdésektől.

A külső fejlesztők beillesztése azzal kezdődik, hogy megegyeznek abban, mit kell először megtanulniuk. Ez magában foglalja a termékét, a felhasználóit és a szokásos munkamódszerét. A fejlesztők beilleszkedési ellenőrzőlistája ezeket az elemeket egy helyen tartalmazhatja. Ez egy egyszerű dokumentumban lehet, amelyet mindkét fél megnyithat és módosíthat. A látható ellenőrzőlista a „Azt hiszem, ezt már elmondtuk nekik” érzést „Pontosan tudjuk, mi történt és mi a következő lépés” érzéssé változtatja. Ez a kis változás mindenki számára megszünteti a csendes stresszt.

Íme egy egyszerű lista, amely gyakran jól működik egy ilyen ellenőrzőlista alapjaként:

1. Hozzáférés a kódhoz, a munkakövetőhöz és a fő csevegőszobákhoz.
2. Lépések a termék laptopon vagy tesztkiszolgálón való futtatásához.
3. Rövid útmutató a felhasználóknak, a főbb folyamatokról és a legfontosabb üzleti szabályokról.
4. A termékkel, kóddal és eszközökkel kapcsolatos kérdésekkel fordulható személyek nevei.
5. Két vagy három kicsi, egyértelmű feladat, amelyek készen állnak az első valódi változásra.

Segít az is, ha egyértelműen megnevezünk egy kapcsolattartót. Az első hetekben egy technikai vezető vagy vezető mérnök töltheti be az onboarding-társ szerepét. Ez a személy áttekintheti az összes korai változtatást, válaszolhat a kérdésekre, és elmagyarázhatja, miért alakultak úgy a korábbi döntések, ahogy. A rövid napi bejelentkezések, akár öt perc chatben, segítenek a dolgok nyomon követésében. Egy nyugodt mentor és állandó kapcsolattartási pontok többet segítenek a biztonságos beilleszkedésben, mint egy nagy beszélgetés az első napon. Idővel több frissítést is áthelyezhetünk aszinkron kommunikációra a fejlesztői csapatok számára, például rövid írásos megjegyzések formájában.

Tapasztalatom szerint a beilleszkedés során a legnagyobb kockázat a csendes zavarodottság. Az új emberek attól tartanak, hogy túl sokat kérdeznek, a régi csapattagok pedig remélik, hogy a dolgok maguktól „összeállnak”. A külső fejlesztők beilleszkedésének egyértelmű terve és egy egyetlen felelős személy megváltoztatja ezt a képet. Ha egy személy felelős a folyamatért, akkor felismerhetők a minták, kijavíthatók a gyenge pontok, és minden következő beilleszkedési kör zökkenőmentesebbé válik. Néhány hónap alatt a terv ismétlődő eszközzé válik, ahelyett, hogy minden új ember felvételekor új kihívásként kellene kezelni.

Hogyan lehet fenntartani a kód minőségét egy vegyes fejlesztői csapatban, ha külső fejlesztőket irányítunk?

A vegyes fejlesztői csapatban a kód minőségét úgy lehet fenntartani, hogy mindenki számára ugyanazokat az egyszerű szabályokat, ellenőrzéseket és számokat alkalmazzuk. Ha azt szeretnénk, hogy a termék egy tiszta, biztonságos rendszernek tűnjön, akkor a szabványoknak minden mérnökre vonatkoznia kell. Ha a szabályokat szerződés típus szerint osztjuk fel, akkor a csapatban a bizalom és az egyértelműség is megoszlik.

A vegyes fejlesztői csapat olyan csoport, amelyben belső és külső mérnökök dolgoznak ugyanazon a terméken. Lehet, hogy különböző helyeken ülnek, de egy backlogot és egy kódtárat osztanak meg egymással. Ez a keverék nagyon erős lehet, mert ötvözi a mélyreható szakterületi ismereteket és a friss nézőpontokat. Ugyanakkor törékeny is lehet, ha minden csoport a saját szokásait követi. Világos iránymutatás nélkül ez a keverék különbözőnek tűnő kódcsoportokká alakul, amelyek között nehéz mozogni. Ez az a pillanat, amikor a minőség és a sebesség elkezdenek romlani.

Itt segíthetnek az egyszerű kódfelülvizsgálati bevált gyakorlatok. Minden változtatást legalább egy másik személynek is át kell nézni, függetlenül attól, hogy ki hajtotta végre. A felülvizsgálatnak nemcsak a stílust, hanem a világosságot, a biztonságot és a rendszer többi részéhez való illeszkedést is figyelembe kell vennie. Ezt könnyű eszközökkel támogathatja, amelyek a kódot általános problémákra vizsgálják. Ezek a rutinok nyugodt, megismételhető módon biztosítják, hogy a külső fejlesztők kódjának minősége összhangban legyen a csapat többi tagjáéval. Az emberek tanulnak egymástól, és kialakítják a „jó” közös fogalmát.

Nyomon követhet egy kis szoftverfejlesztő csapat mutatókészletet is. Ezekből kiderül, mennyi időbe telik egy feladat elvégzése, hány probléma éri el a felhasználókat, és milyen gyakran szállítanak. Nincs szükség tucatnyi számra. Csak néhányra, amelyet könnyen elolvashat és megbeszélhet. Ha ezek a mutatók stabilak maradnak vagy javulnak, miközben külső fejlesztőket irányít és bővíti a csapatot, akkor tudja, hogy a felállás támogatja a minőséget. Ha romlanak, akkor korai jelzést kap, hogy felülvizsgálja a szabályokat, a hatókört vagy a feladatok összetételét.

A kommunikációs minták ugyanolyan fontosak, mint a szabályok és a számok. Sok vegyes fejlesztői csapat is elosztott agilis csapatnak számít, mert az emberek több helyről vagy időzónából dolgoznak. Szükségük van aszinkron kommunikációra a fejlesztői csapatok számára, hogy a haladás ne függjön hosszú telefonhívásoktól. Rövid írásbeli frissítések, egyértelmű feladatjegyzetek és egyszerű állapotjelölők sokat segítenek. A jó írásbeli frissítések megkönnyítik az összes mérnök számára, hogy csatlakozzanak, kövessék és idővel fejlesszék a terméket. Az élő beszélgetések továbbra is fontosak, de már nem az egyetlen helyek, ahol döntések születnek.

Az is befolyásolja a minőséget, hogy hogyan vonod be a külsősöket. Ha különálló, nem egyértelmű célokkal rendelkező csoportként kezeled őket, nem fogják teljes mértékben magukénak érezni a terméket. Ha egy szabályrendszer alatt bevonod őket a meglévő csapatokba, úgy viselkedhetnek, mint bármelyik másik csapattag. Egyes cégek ehhez csapatbővítési rendszert alkalmaznak, amelyben a belső és külsősöket egy vezető alatt egyesítik. A közös célok, a közös eszközök és a közös értékelések többet tesznek a szoftverfejlesztés kódminőségéért, mint bármelyik szigorú ellenőrzési dokumentum. Idővel módosíthatod az emberek és a munka összetételét, de a közös keret változatlan marad.