Są momenty, które zna każdy zespół inżynierów. Ktoś przypomina o procesie logowania, który jest 'tymczasowy' od ośmiu miesięcy, i zapada cisza.
Obecny globalny krajobraz gospodarczy wymaga ponownej oceny tradycyjnych modeli dostarczania. W miarę skalowania firm, tarcie między jakością, kosztem a prędkością często ujawnia strukturalne słabości w konwencjonalnych strategiach dostarczania.
Są momenty, które zna każdy zespół inżynierów. Ktoś przypomina o procesie logowania, który jest "tymczasowy" od ośmiu miesięcy, i zapada cisza. Nikt nie chce być tą osobą, która powie "naprawmy to", ponieważ oznacza to, że wdrożenie funkcji innej osoby opóźni się.
Napięcie to w zasadzie nigdy nie mija. Zbyt szybkie wdrożenie oprogramowania bez jego oczyszczenia sprawia, że sześć miesięcy później wydajność po cichu spada. Wstrzymanie wdrożenia oprogramowania w celu całkowitej refaktoryzacji natychmiast opóźnia projekt. Każdy lider IT, z którym współpracowaliśmy, znajduje się gdzieś na tej osi.
Oto najprostszy sposób myślenia o długu technicznym:
To koszt pójścia na skróty. Zespół koduje na sztywno pewną wartość, aby dotrzymać terminu premiery, zamiast zbudować odpowiedni system ustawień. Kod działa, zostaje wdrożony, a wszyscy przechodzą do następnego zadania. Później klient prosi o inne ustawienie, a zmiana, która powinna zająć dwadzieścia minut, trwa dwa dni, ponieważ najpierw ktoś musi przeanalizować pójście na skróty. Oznacza to dług z terminem spłaty.
Pozytywne jest to, że zespoły nie muszą wybierać między szybszym dostarczaniem, a dobrą kondycją projektów. W Mereb rozwiązujemy ten problem poprzez oddane zespoły inżynieryjne obsługujące europejskie firmy SaaS.
Zacznij od nadania długowi technicznemu przejrzystego, łatwo wycenianego statusu. Przypisz elementy długu obok funkcji za pomocą szacunków pracochłonności, historycznych punktów czasowych lub mierzonych w dniach wysiłków zespołu. Śledź kategorie: przestarzałe zależności, niedoskonała architektura, powolne testy. Przeprowadź weryfikację całej listy na każdej sesji planowania i priorytetyzuj elementy, które zagrażają wprowadzanym innowacjom lub mogą prowadzić do błędów. Gdy dług techniczny można wycenić liczbowo, przestaje być abstrakcyjnym pojęciem, a staje się zaległością, z którą pracownicy mogą sprawnie pracować, identycznie jak w przypadku innych zadań.
Przeznacz pewną część pojemności sprintu na redukcję zadłużenia – średnio wynosi to około 15 do 25%, zależnie od objętości kodu. Prawidłowy schemat podziału czasu zespołu powinien wyglądać w następujący sposób: 70 procent na nowe funkcjonalności, 20 na spłatę zaciągniętych długów i 10 procent przeznaczone na usuwanie nagłych i niezaplanowanych błędów. Dotrzymaj tych zasad i uświadom osobom zainteresowanym ważność takich działań.
Nie twórz z przebudowy kodu wielkiego i wyolbrzymionego procesu. Refaktoryzację staraj się robić regularnie, podczas pracy nad mniejszymi i bieżącymi elementami. Kiedy nowa funkcjonalność jest podpinana do środowiska i starszych baz danych i użytego tam kodu, przebuduj to przy tej samej pracy. Jeżeli będziesz przeprowadzał te operacje cyklicznie przez wszystkie następujące działania sprintu – nagromadzona naprawa przyniesie znaczny efekt nowoczesności systemu, oszczędzając Ci pauzy przy kolejnych procesach dostarczania.
Analiza statyczna kodu, linting, odpowiednie targetowanie zakresu i objętości środowiska, skanowanie powiązań – te wszystkie zabiegi wyłapią niekorzystny dług zanim nagromadzi się i przeistoczy w lawinę błędów. Zabezpiecz czas na szersze inspekcje utrzymaniowe kodu systemowego dla obszerniejszych działań nienależących do regularnych uaktualnień, czy napraw usterek dla konkretnych funkcji. Śledź i koreluj częstotliwość wgrywania systemu wraz ze szlifami testowymi z wdrożeniami (tzw. delivery).
Dług techniczny nie powinien być wyłącznie tematem zespołu inżynierów. Zaproś działy projektowania usług z liderami grupy i przypisz obustronną kontrolę. Upewnij się, że wszyscy są obecni na demonstracjach i testach najistotniejszych etapów budowania fundamentu systemowego i pokazach nowych funkcjonalności.
Nasze oddane grupy i specjaliści informatyczni z ponad pięcioletnim średnim zakresem kompetencyjnym wypuścili więcej niż 50 systemów dedykowanych europejskim platformom SaaS. My nie traktujemy zarządzania wdrożeniami pobłażliwie, dla nas jest to główne rzemiosło pracy w środowiskach informatycznych z naciskiem na szybkie i optymalne budowanie w krótkim okresie mierzonym w latach, a nie miesiącach.
Zwróć się do nas o pomoc jeśli widzisz stagnację spowodowaną niekontrolowanym wzrostem długu technologicznego na tle niskiej wydajności zespołu programistycznego.
Przed jakąkolwiek rozmową handlową umówimy Cię na 30-minutową rozmowę ze starszym inżynierem w Twoim stosie. Żadnych sprzedawców. Tylko sprawdzenie poprawności technicznej.
Odpowiemy w ciągu jednego dnia roboczego, podając następny krok.
