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

Každá firma, velká i malá, se obává technického dluhu. odhaduje Gartner že tento problém má přibližně 40 % infrastrukturních systémů. V průzkumu mezi CIO společnosti McKinsey se téměř třetina z nich domnívala, že více než% 20 část rozpočtu na nový produkt šla na řešení problémů souvisejících s technickým dluhem. Na rozdíl od toho, co si mnozí myslí, se však nejedná jen o problém s kódováním, ale také o problém se zkušenostmi vývojářů (DX). Protože když vývojáři musí pracovat s nedostatečnou architekturou, zastaralými nástroji a podprůměrnými vývojářskými pracovními postupy, trpí produktivita, výkon a morálka.

Upřednostňování 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í postupy mohou dosáhnout, pomáhá týmům soustředit se a rychleji odevzdávat projekty. Proto se způsob, jakým společnosti spravují technický dluh, mění, a to díky DX a rostoucímu zaměření na nástroje poháněné umělou inteligencí.

Šampionský DX

Způsob, jakým jsou vývojáři často zapojováni do projektu, nechává mnoho prostoru pro zlepšení. Může trvat i několik týdnů, než se někdo začne podílet na projektu. Jakmile jsou konečně schopni přidat malé funkce nebo záplaty, není neobvyklé, že služba kontinuální integrace (CI) selže kvůli něčemu, co zcela nesouvisí se změnami, na kterých pracovali. V podstatě se jedná o selhání testovací sady kvůli problémům se špatnou kvalitou a vývojář neodeslal změny, které by testovací sadu způsobily. Je to nespolehlivý, špatně napsaný test, který funguje pouze v 90 % případů. Stávající tým s tím pravděpodobně souhlasí – jen to zpomaluje procesy – ale nástroje mohou být zastaralé a demoralizující pro kohokoli mimo organizaci.

Toto je jeden z mnoha příkladů, které brání správnému DX. Jedním ze způsobů, jak tomu předejít, je mít ve svém týmu softwarového inženýrství a vývoje určeného šampiona. Mnoho malých organizací nemá vedoucího DX, ale velké a úspěšné organizace ho mají. Tito profesionálové sledují věci, jako je doba, kterou nový vývojář potřebuje k nastavení prostředí. A pokud jsou dva týdny příliš dlouhé, vymyslí, jak tuto dobu zkrátit na polovinu.

Existují nástroje, které s tím mohou pomoci, jako například CircleCI, s nativními funkcemi, které budou sledovat nespolehlivost testovací sady. Potřebujeme někoho, kdo se ujme vedení a po každém sprintu se zastaví, aby řešil některé změny, které usnadní údržbu a práci s kódem v budoucnu. Jde o to, mít vedoucího, který má zájem na vylepšení DX. Aby se to podařilo, hledejte inženýra na vyšší úrovni, doprovázeného relativně novým členem týmu, který může poskytnout zpětnou vazbu na možné nedostatky.

IDC také očekává, že trh s automatizací testování softwaru s využitím umělé inteligence bude pokračovat. růst s průměrnou roční mírou růstu (CAGR) 31.2 % do roku 2027, takže se ujistěte, že tuto technologii využíváte naplno.

Metriky a varovné signály

Existuje mnoho metrik, které můžete sledovat při hodnocení toho, jak technický dluh ovlivňuje váš tým. Mezi základní patří „čas na opravu“ nebo „čas na přidání nové funkce“. Řekněme, že si všimnete chyby a víte, jak ji opravit. Některé nástroje dokáží sledovat čas strávený od napsání kódu až po produkci. Například byste mohli vidět, že oprava a odeslání velmi malé záplaty trvalo dva pracovní dny, zatímco váš tým to musí být schopen udělat během hodin. Můžete také sledovat poměry, jako je počet oprav chyb oproti dokončeným funkcím.

Existují také způsoby, jak zjistit, kdy problémy s morálkou ovlivňují výkon vašeho týmu. Vedoucí vývojářů mohou čtvrtletně provádět průzkumy, aby zjistili, 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 ptát se na ně. A vždy můžete sledovat fluktuaci nebo obrat ve vašem týmu. Pokud si všimnete, že lidé stále odcházejí, mohou mít pocit, že jejich obavy nejsou slyšet.

Nástroje s umělou inteligencí

Vzestup nástrojů pro umělou inteligenci (AI) má zvýšit produktivitu vývojářů a inženýrů a urychlit dodávání produktů, ale technický dluh to zpomaluje. Řekněme, že používáte nástroj jako GitHub nebo Copilot, který vám pomůže se změnami kódu, poté odešlete pull request a CI trvá několik hodin, než se vám ozve. Mezitím pracuje vývojář na něčem jiném? Kontroluje e-maily? Je to přepínání kontextu a zabíjení produktivity.

Vývojáři chtějí pracovat na produktech, u kterých se mohou soustředit pouze na kód. Nástroje jsou tu proto, aby jim pomohly dostat je do produkčního prostředí, ne aby byly neustálou překážkou. Umělá inteligence může ušetřit čas, ale je na technických týmech, aby si definovaly vlastní standardy pro přijatelnou složitost. Abyste toho dosáhli, nejprve se ujistěte, že jakýkoli kód, který je přidáván do vaší hlavní větve, má přijatelnou úroveň technického dluhu. Předtím proveďte otevřenou diskusi a získejte souhlas technického týmu s přijatelnou hranicí technického dluhu a kvality kódu. Ujistěte se, že všichni vědí, že překročení této hranice vyžaduje okamžitou nápravu. Jakmile tyto standardy definujete, vstupuje do hry umělá inteligence.

Existují argumenty pro agenty s umělou inteligencí, kde inženýři fungují jako orchestrátoři. Průzkum společnosti Capgemini mezi 1,100 manažery ve velkých podnicích ukázal, že 82 % plánuje integraci agentů s umělou inteligencí v příštích třech letech a již nyní mají dopad na budoucnost práceMožná se díváte na hlášení o chybě a vidíte, že je dostatečně malé na to, aby ho agent umělé inteligence zvládl od vzniku až po kontrolu kódu, což vašemu týmu ušetří čas a uvolní mu prostor pro složitější práci. Někdy však, když se těmito nástroji slepě řídíme, existují kompromisy, které umělá inteligence jen těžko zvažuje.

Tehdy se lidský názor stává rozhodujícím faktorem.

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

Jak sladit snižování technického dluhu s cíli, kterých se snažíte dosáhnout, nebo s měřitelnými výsledky? Vrací se to k přijatelnému technickému dluhu a někdy v podnikání musíte produkt dodávat rychle. Můžete to udělat s vědomím, že produkt se neškáluje a časem se mohou objevit problémy s výkonem. Vývojář si často poznamená, že se k tomu má vrátit později, až bude čas tyto problémy řešit, ale to se stává jen zřídka. A když se ujme tato špatná kultura, kdy musíte produkt neustále dodávat zítra, dopad dluhu se stane zcela zřejmým.

To je pochopitelné pro startup, ale ne pro firmu, která funguje už deset let. Abyste mohli řídit technický dluh, musíte začít měnit svou kulturu brzy a aktivně, jinak utratíte spoustu peněz za opravu chyb v produkci nebo za starosti o bezpečnost a dodržování předpisů.

Konečně existují metriky, které pomáhají zúčastněným stranám sdělit hodnotu refaktoringu nebo splácení technického dluhu. Jedním z nich může být čas od vzniku do produkčního prostředí nebo od otevření pull requestu až po jeho sloučení a odeslání do produkčního prostředí. Dalším metrikou je průměrná doba opravy (MTTR). V tomto případě jste možná našli chybu nebo nefunkční sestavení a měříte, jak dlouho trvá vašemu týmu, než ji opraví. Můžete také sledovat počet chyb, které máte v produkčním prostředí. Pokud vidíte, že toto číslo roste, může se jednat o problém související s technickým dluhem.

Technický dluh s úroky

Každá organizace může věnovat několik hodin týdně vylepšení svého 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 bezpečnostními problémy. Například váš tým inženýrů a vývojářů mohl odkládat upgrade na Ruby on Rails po dobu deseti let. Náklady na projekt se najednou zvýší o půl milionu dolarů, protože verze Ruby je o čtyři generace pozadu, takže vám zbývá spousta kódu a zastaralých závislostí.

Kdybyste upgradovali postupně, nebyli byste v této situaci. Proto podpořte svůj vývojový tým a plaťte postupně. Jinak se vám ten technický dluh vrátí i s úroky.