Zarządzanie długiem technicznym za pomocą DX i AI

Każda firma, duża i mała, martwi się o dług techniczny. Gartner szacuje, że około 40% systemów infrastrukturalnych ma ten problem. W badaniu przeprowadzonym przez McKinsey wśród dyrektorów IT, prawie jedna trzecia osób czuła, że ponad 20% ich budżetu na nowe produkty poszło na rozwiązanie problemów związanych z długiem technicznym. Ale wbrew temu, co wielu ludzi uważa, nie jest to tylko problem kodowania; jest to również problem doświadczenia dévelopera (DX). Ponieważ gdy dévelopery muszą pracować z nieodpowiednią architekturą, przestarzałymi narzędziami i gorszymi procesami rozwoju, produktywność, wydajność i morale cierpią.

Priorytetowanie długu technicznego z myślą o déveloprze, skupiając się na tym, jak oni podejmują pracę, jakie narzędzia używają i jakie awanse mogą osiągnąć, pomaga zespołom skupić się i wysyłać szybciej. Dlatego sposób, w jaki firmy zarządzają długiem technicznym, ulega zmianie, napędzanej przez DX i zwiększony nacisk na narzędzia oparte na AI.

Wspieranie DX

Sposób, w jaki dévelopery są często wdrażani, pozostawia wiele do życzenia. Może to potrwać kilka tygodni, zanim ktoś zacznie przyczyniać się do projektu. Gdy w końcu zaczynają dodawać małe funkcje lub łatki, nie jest rzadkością, gdy ciągłe integrowanie (CI) nie powiedzie się z powodu czegoś całkowicie niezwiązanego z ich zmianami. Jest to podstawowo nieudany test, który działa tylko 90% czasu. Istniejący zespół jest prawdopodobnie w porządku z tym – to tylko spowalnia procesy – ale narzędzia mogą być przestarzałe i demoralizujące dla kogokolwiek spoza organizacji.

To jest tylko jeden z wielu przykładów, które utrudniają odpowiednie DX. Jednym ze sposobów, aby temu zapobiec, jest posiadanie wyznaczonego championa w zespole inżynierów i déveloperów. Wiele małych organizacji nie ma lidera DX, ale duże, udane firmy tak. Ci specjaliści śledzą rzeczy takie jak czas, jaki potrzebuje nowy déveloper, aby ustawić środowisko. I jeśli dwa tygodnie to za długo, starają się to skrócić.

Istnieją narzędzia, które mogą pomóc, takie jak CircleCI, z natywnymi funkcjami, które śledzą niepewność testów. Co jest potrzebne, to ktoś, kto podejmie inicjatywę i po każdym sprincie zajmie się niektórymi zmianami, które ułatwią kod w przyszłości. To wszystko sprowadza się do posiadania lidera zainteresowanego poprawą DX. Aby to się stało, szukaj seniora, który jest towarzyszy przez młodszego członka zespołu, który może zapewnić informacje zwrotne o możliwych lukach.

Również IDC oczekuje, że rynek automatyzacji testów oprogramowania opartych na AI będzie nadal rosnąć o 31,2% do 2027 roku, więc upewnij się, że wykorzystujesz tę technologię w pełni.

Metryki i ostrzeżenia

Istnieje wiele metryk, które możesz śledzić, oceniając, jak dług techniczny wpływa na Twój zespół. Niektóre podstawowe to “czas naprawy” lub “czas realizacji”. Powiedzmy, że zauważysz błąd i wiesz, jak go naprawić. Niektóre narzędzia mogą śledzić czas spędzony od pisania kodu do produkcji. Na przykład, będziesz w stanie zobaczyć, że bardzo mała łatka zajęła dwa dni robocze do naprawy i wysłania, gdy Twój zespół musi być w stanie to zrobić w godzinach. Możesz również śledzić wskaźniki, takie jak liczba napraw błędów w stosunku do zrealizowanych funkcji.

Istnieją również sposoby, aby zidentyfikować, kiedy problemy z morale wpływają na wyniki Twojego zespołu. Liderzy DX mogą prowadzić ankiety co kwartał, aby określić, jak szczęśliwy jest déveloper pracujący nad projektem lub jego częścią. Mogą się zagłębić i zapytać o konkretnych obszarach, takich jak proces CI. I zawsze możesz śledzić rotację lub odwrót w Twoim zespole. Jeśli zauważysz, że ludzie ciągle odchodzą, mogą czuć, że ich problemy nie są słyszane.

Narzędzia oparte na AI

Wzrost narzędzi opartych na AI ma na celu zwiększenie produktywności déveloperów i inżynierów oraz szybsze wysyłanie produktów, ale dług techniczny spowalnia to. Powiedzmy, że używasz narzędzia takiego jak GitHub lub Copilot, aby pomóc w zmianach kodu, a następnie wysyłasz pull request, a CI zajmuje parę godzin, aby wrócić do Ciebie. W międzyczasie, czy déveloper pracuje nad czymś innym? Sprawdza e-maile? To jest zmiana kontekstu i zabójca produktywności.

Developpery chcą pracować nad produktami, nad którymi mogą się skoncentrować na kodzie. Narzędzia są tam, aby im pomóc w dostarczeniu go do produkcji, a nie być stałym przeszkodą. AI może zaoszczędzić czas, ale to zespoły inżynierskie muszą określić własne standardy dla akceptowalnej złożoności. Aby to zrobić, najpierw upewnij się, że każdy kod, który jest dodawany do głównego gałęzi, ma akceptowalny poziom długu technicznego. Przed tym, przeprowadź otwartą dyskusję i uzyskaj akceptację zespołu inżynierskiego co do akceptowalnego progu długu technicznego i jakości kodu. Upewnij się, że każdy wie, że przekroczenie tego progu wymaga natychmiastowej naprawy. Gdy już określisz te standardy, AI wchodzi w grę.

Istnieje przypadku dla agentów AI z inżynierami działającymi jako orchestratorami. Badanie przeprowadzone przez Capgemini na 1,100 executive’ach w dużych przedsiębiorstwach ujawniło, że 82% planuje zintegrować agenty AI w ciągu najbliższych trzech lat, i już wpływają na przyszłość pracy. Możesz patrzeć na raport błędu i zobaczyć, że jest on wystarczająco mały, aby agent AI mógł go obsłużyć od początku do przeglądu kodu, oszczędzając Twój zespół czasu i uwalniając ich, aby zajęli się bardziej złożoną pracą. Jednak czasami, gdy ślepo podążamy za tymi narzędziami, są kompromisy, które AI ma trudności z uwzględnieniem.

To jest moment, w którym ludzka opinia staje się decydującym czynnikiem.

Wyrównanie długu technicznego z celami

Jak wyrównać redukcję długu technicznego z celami, które próbujesz osiągnąć lub miernymi wynikami? To wraca do akceptowalnego długu technicznego, a czasami w biznesie musisz wysyłać szybko. Możesz to zrobić, wiedząc, że produkt nie skaluje, i może wystąpić problem z wydajnością w czasie. Często, déveloper zrobi notatkę, aby wrócić do tego później, gdy będzie czas, aby rozwiązać te problemy, ale to rzadko się zdarza. I gdy ta słaba kultura przejmuje kontrolę, w której musisz ciągle wysyłać jutro, wpływ długu staje się wyraźny.

To jest zrozumiałe dla startupu, ale nie dla firmy, która działa od dziesięciu lat. Musisz zacząć zmieniać swoją kulturę wcześnie i aktywnie, aby zarządzać długiem technicznym; w przeciwnym razie, będziesz wydawać dużo pieniędzy na naprawę błędów w produkcji lub martwić się o bezpieczeństwo i zgodność.

W końcu, istnieją metryki, które mogą pomóc w komunikowaniu wartości refaktoryzacji lub spłaty długu technicznego do stakeholderów. Czas może być jednym z nich, od początku do produkcji, lub od otwarcia pull request do scalenia i wysłania go do produkcji. Innym jest średni czas naprawy (MTTR). W tym przypadku, możesz znaleźć błąd lub złamany build, i zmierzyć, jak długo zajmuje Twojemu zespołowi, aby to naprawić. Możesz również śledzić liczbę błędów, które masz w produkcji. Jeśli zobaczysz, że ta liczba rośnie, może to być problem związany z długiem technicznym.

Dług techniczny z odsetkami

Każda organizacja może poświęcić kilka godzin każdego tygodnia, aby poprawić swoje DX, aby pomóc w redukcji długu technicznego. Jeśli nie, możesz za to zapłacić później, prawdopodobnie przez wolną wydajność, znaczne spowolnienie tempa rozwoju lub problemy z bezpieczeństwem. Na przykład, Twój zespół inżynierów i déveloperów mógł odwlekać uaktualnienia Ruby on Rails przez dziesięć lat. Nagle, koszt projektu wzrasta o pół miliona dolarów, ponieważ wersja Rubiego jest cztery generacje w tyle, pozostawiając Cię z masą kodu i przestarzałymi zależnościami.

Gdybyś uaktualnił stopniowo, nie byłbyś w tej sytuacji. Wspieraj więc swój zespół déveloperów i płac w miarę. W przeciwnym razie, ten dług techniczny wróci, aby Cię nawiedzić, z odsetkami.