Řízení technického dluhu s DX a AI

Každá společnost, velká i malá, se obává technického dluhu. Gartner odhaduje, že asi 40 % infrastrukturálních systémů má tento problém. V průzkumu CIO podle McKinseyho se téměř třetina cítila, že více než 20 % jejich rozpočtu na nové produkty šlo na řešení problémů souvisejících s technickým dluhem. Ale na rozdíl od toho, co si mnoho lidí myslí, není to pouze problém kódování; je to také problém zkušeností vývojářů (DX). Protože když vývojáři musí pracovat s nevyhovující architekturou, zastaralými nástroji a podprůměrnými vývojovými postupy, snižuje se produktivita, výkon a morálka.

Prioritizace technického dluhu s ohledem na vývojáře, zaměřená na to, jak přistupují k práci, jaké nástroje používají a jaké kariérní pokroky mohou dosáhnout, pomáhá týmům soustředit se a dodávat rychleji. To je důvod, proč se způsob, jakým společnosti spravují technický dluh, mění, poháněný DX a zvýšeným zaměřením na nástroje s umělou inteligencí.

Hájení DX

Způsob, jakým jsou vývojáři často zařazeni, zanechává mnoho prostoru pro zlepšení. Může to trvat několik týdnů, než někdo začne přispívat do projektu. Jakmile konečně mohou přidat malé funkce nebo opravy, není neobvyklé, že vidíte, že služba pro kontinuální integraci (CI) selže kvůli něčemu zcela nesouvisejícímu s změnami, na kterých pracovali. To je vlastně selhání testovací sady kvůli problémům s kvalitou, a vývojář neodeslal žádné změny, které by mohly způsobit selhání testovací sady. Je to nestabilní, špatně napsaný test, který funguje pouze 90 % času. Stávající tým je probably v pořádku s tím – pouze zpomaluje procesy – ale nástroje mohou být zastaralé a demoralizující pro kohokoli mimo organizaci.

To je jeden z mnoha příkladů, které brání správnému DX. Jedním ze způsobů, jak tomu předcházet, je mít na softwarovém inženýrském a vývojovém týmu určeného šampiona. Mnoho malých organizací nemá DX lídra, ale velké, úspěšné ano. Tito profesionálové sledují věci, jako je délka času, kterou potřebuje nový vývojář k nastavení prostředí. A pokud je dva týdny příliš dlouho, snaží se najít způsob, jak tuto dobu zkrátit na polovinu.

Existuje nástroj, který může pomoci, jako je CircleCI, s nativními funkcemi, které sledují nestabilitu testovací sady. Co je potřeba, je někdo, kdo vezme vedení a zastaví se po každém sprintu, aby řešil některé změny, které učiní kód snazší na údržbu a práci v budoucnu. To se sníží na to, mít lídra, který se zajímá o zlepšení DX. Aby se to stalo, hledají senior vývojáře, doprovázeného relativně novým zaměstnancem, který může poskytnout zpětnou vazbu o možných mezích.

Také IDC očekává, že trh s umělou inteligencí pro automatizaci softwarových testů bude pokračovat růst tempem 31,2 % do roku 2027, takže se ujistěte, že využijete tuto technologii naplno.

Metriky a varovné signály

Existuje mnoho metrik, které můžete sledovat, když vyhodnocujete, jak technický dluh ovlivňuje váš tým. Některé základní metriky jsou „čas na opravu“ nebo „čas na funkci“. Řekněme, že si všimnete chyby a víte, jak ji opravit. Některé nástroje mohou sledovat čas strávený od psaní kódu až po produkci. Například byste mohli vidět, že velmi malá oprava trvala dva pracovní dny, zatímco váš tým potřebuje být schopen to udělat za hodiny. Můžete také sledovat poměry, jako je počet oprav chyb versus dokončených funkcí.

Existují také způsoby, jak identifikovat, kdy problémy s morálkou ovlivňují výkon vašeho týmu. Lídrové DX mohou provádět průzkumy čtvrtletně, aby určili, jak spokojený je vývojář s prací na projektu nebo jeho části. Mohou se zaměřit na konkrétní oblasti, jako je proces CI. A můžete vždy sledovat fluktuaci nebo odchod ze týmu. Pokud si všimnete, že lidé neustále odcházejí, mohli by cítit, že jejich obavy nejsou slyšet.

Herní nástroje s AI

Růst nástrojů s umělou inteligencí má pomoci vývojářům a inženýrům být produktivnější a dodávat produkty rychleji, ale technický dluh zpomaluje tento proces. Řekněme, že používáte nástroj, jako je GitHub nebo Copilot, aby vám pomohl s úpravami kódu, a poté odesíláte žádost o stažení, a CI trvá několik hodin, než se vrátí. Mezitím, co dělá vývojář? Kontroluje e-maily? Je to změna kontextu a zabiják produktivity.

Vývojáři chtějí pracovat na produktech, kde se mohou soustředit pouze na kód. Nástroje jsou tam, aby jim pomohly dostat kód do produkce, ne aby byly neustálou překážkou. Umělá inteligence může ušetřit čas, ale je na inženýrských týmech, aby definovaly své vlastní standardy pro přijatelnou složitost. Aby se to stalo, musíte se ujistit, že jakýkoli kód, který je přidán do vaší hlavní větve, má přijatelnou úroveň technického dluhu. Předtím musíte mít otevřenou diskusi a získat souhlas od inženýrského týmu o přijatelném prahu technického dluhu a kvality kódu. Ujistěte se, že všichni vědí, že překročení této značky vyžaduje okamžitou nápravu. Jakmile jste definovali tyto standardy, umělá inteligence vstupuje do hry.

Existuje případ pro agenta AI s inženýry, kteří jednají jako orchestrátoři. Průzkum Capgemini mezi 1 100 výkonnými manažery velkých podniků odhalil, že 82 % plánuje integrovat agenta AI v příštích třech letech, a již nyní ovlivňují budoucnost práce. Můžete se podívat na chybovou zprávu a vidět, že je dostatečně malá, aby ji mohl zpracovat agent AI, od začátku až po kontrolu kódu, a ušetřit tak váš tým čas a uvolnit ho pro složitější práci. Někdy, když slepě následujeme tyto nástroje, existují kompromisy, se kterými se AI potýká.

To je okamžik, kdy se lidský názor stává rozhodujícím faktorem.

Sladění technického dluhu s cíli

Jak sladíte snížení technického dluhu s cíli, kterých se snažíte dosáhnout, nebo měřitelnými výsledky? To se vrací k přijatelnému technickému dluhu, a někdy v podnikání musíte dodávat rychle. Můžete tak učinit, aniž byste věděli, zda produkt škáluje, a zda existují problémy s výkonem, které se projeví časem. Často vývojář udělá poznámku, aby se k tomu později vrátil, až bude čas řešit tyto problémy, ale to se zřídka stane. A když tento špatný postup převládá, ve kterém jste neustále nuceni dodávat zítra, dopad dluhu se stává zřetelným.

To je pochopitelné pro startup, ale ne pro podnik, který běží již deset let. Musíte začít měnit svou kulturu brzy a aktivně, abyste spravovali technický dluh; jinak budete trávit spoustu peněz na opravu chyb v produkci nebo se bát problémů se zabezpečením a dodržováním předpisů.

Nakonec existují metriky, které vám pomohou komunikovat hodnotu refaktoringu nebo splácení technického dluhu stakeholderům. Časem to může být od začátku do produkce, nebo od otevření žádosti o stažení až po sloučení a dodání do produkce. Další je průměrný čas na opravu (MTTR). V tomto případě můžete najít chybu nebo rozbitou build, a měříte, jak dlouho trvá vámu týmu ji opravit. Můžete také sledovat počet chyb, které máte v produkci. Pokud vidíte, že se toto číslo zvyšuje, může to být problém související s technickým dluhem.

Technický dluh s úrokem

Každá organizace může věnovat několik hodin každý týden na zlepšení DX, aby pomohla snížit technický dluh. Pokud ne, můžete za to později zaplatit, pravděpodobně pomalým výkonem, značným zpomalením vývoje nebo problémy se zabezpečením. Například váš tým inženýrů a vývojářů mohl odkládat aktualizace Ruby on Rails po dobu deseti let. Najednou je projektová cena zvýšena o půl milionu dolarů, protože verze Ruby je čtyři generace pozadu, což vám zanechává hromadu kódu a zastaralých závislostí.

Jestliže jste aktualizovali postupně, nebyli byste v této situaci. Proto podporujte svůj softwarový vývojový tým a platte, jak postupujete. Jinak se technický dluh vrátí, s úroky.