Odwracanie długu technicznego za pomocą Chmury

Poniższy artykuł obejmuje najlepsze praktyki zarządzania długiem technicznym i odwracania go przez rozważne wykorzystywanie i obsługę usług w chmurze.

Dług techniczny to metafora wymyślona przez Warda Cunninghama, aby poradzić sobie z kosztami decydowania się na kompromisy w rozwoju oprogramowania w celu zaspokojenia krótkoterminowych potrzeb biznesowych. Przykład? W przypadku zadłużenia finansowego bierzesz pożyczkę, aby od razu nabyć coś, czego chcesz lub potrzebujesz, z obietnicą późniejszej spłaty. Jeśli nie spłacisz, poniesiesz konsekwencje. Podobnie, jeśli braki w oprogramowaniu nie zostaną usunięte w odpowiednim czasie („spłata”), utrzymywanie i dodawanie nowych funkcji do oprogramowania staje się wykładniczo trudniejsze („odsetki od zadłużenia”). Dotyczy to wszystkich firm, niezależnie od tego, czy działają lokalnie, czy w chmurze. Ale tak jak długiem finansowym należy zarządzać w sposób odpowiedzialny, tak też istnieje potrzeba skrupulatnego zarządzania długiem technicznym. W rzeczywistości kluczową zaletą chmury jest możliwość efektywnego zarządzania długiem technicznym.

Co jest przyczyną powstawania długu technicznego?

Istnieje wiele czynników, które przyczyniają się do powstania długu technicznego. Zaczynając od rzeczy oczywistych, złe praktyki i decyzje technologiczne powodują dług techniczny. Przykłady obejmują źle napisane oprogramowanie, nieodpowiednie przeglądy i testy kodu, brak dokumentacji i standardów, nieelastyczne projektowanie oprogramowania i niewłaściwe wybory technologiczne. Dług techniczny wynika również z braku umiejętności informatycznych, zdolności i częstej rotacji pracowników.

Zespoły biznesowe i technologiczne różnie interpretują wymagania dotyczące produktów, co skutkuje długiem technicznym. Wymagania biznesowe koncentrują się na funkcjonalnych doświadczeniach użytkowników końcowych. Wymagania technologiczne koncentrują się z kolei na atrybutach niefunkcjonalnych, takich jak odporność, wydajność, łatwość konserwacji i bezpieczeństwo. Często nie są one traktowane priorytetowo przez firmy. Aby dotrzymać terminów, zespoły IT często idą na skróty (wprowadzając dług techniczny), aby uwzględnić te niesprawne funkcje. Zmiany w preferencjach klientów, środowisku, konkurencji, geopolityce, gospodarce i przepisach utrudniają przewidywanie przyszłych modeli biznesowych. Dlatego tworzenie przyszłościowego oprogramowania jest wyzwaniem. Co więcej, sama technologia ewoluuje w szybkim tempie, sprawiając, że dzisiejsze wybory technologiczne jutro staną się przestarzałe. Ponieważ hakerzy nieustannie znajdują nowe sposoby wykorzystywania luk w oprogramowaniu, powoduje to, że jesteśmy w ciągłym stanie długu technicznego.

Najlepsze praktyki do zarządzania długiem technicznym

Niestety, dług techniczny jest nieunikniony. Jak sobie z tym poradzić? Pozostawiony sam sobie sprawi, że wprowadzanie zmian w oprogramowaniu byłoby trudniejsze, co z kolei paraliżuje szybkość i zawyża koszty dostawy. Z drugiej strony, jeśli firmy spędzają zbyt dużo czasu w pogoni za perfekcją, wpłynie to na dostarczanie produktów. Warto wziąć pod uwagę, że dług techniczny niekoniecznie jest zły. Tak długo, jak zadłużenie technologiczne jest celowe, ale rozważne, z dobrze zdefiniowaną ścieżką realizacji w celu usunięcia braków („spłacenia”) w przyszłości, jest to korzystne dla obu stron, zarówno dla zespołów biznesowych, jak i technologicznych. Poniżej znajdziesz kilka najlepszych praktyk zarządzania długiem technologicznym poprzez wykorzystanie usług w chmurze.

Rozpoznaj „prawdziwy” dług technologiczny i uwidocznij go. Dług techniczny może być niewłaściwie wykorzystany do usprawiedliwienia inwestycji. Zwykle jest używany do uzasadnienia ulepszania wewnętrznych elementów systemów IT zamiast dodawania nowych funkcji dostępnych dla użytkownika. Inwestycje w dług techniczny powinny więc być powiązane z wynikami biznesowymi. Zadłużenie powinno być oceniane ilościowo na podstawie wpływu na biznes, takiego jak złe doświadczenia klientów, utracone przychody, opóźnione wydawanie produktów, dłuższy czas rozwiązywania problemów i zmniejszona produktywność pracowników. Okresowe działania konserwacyjne, takie jak tworzenie kopii zapasowych, aktualizacje stron trzecich i poprawki bezpieczeństwa nie wchodzą w zakres długu technicznego. To są po prostu dobre praktyki operacyjne.

Dług techniczny to nie tylko kwestia technologii. Decyzja o zaciągnięciu i spłacie długu technicznego powinna dotyczyć zarówno zespołów biznesowych, jak i technologicznych. Wycofanie się z potrzeb klienta i nadanie priorytetu najbardziej wpływowym funkcjom produktu o minimalnej opłacalności (MVP) może pomóc zespołom biznesowym zmniejszyć dług techniczny. Dzięki wyraźnemu określeniu, kiedy funkcja oprogramowania jest „ukończona i gotowa” oraz nieobiecywaniu zainteresowanym stronom zbyt wysokich wyników, zespoły biznesowe mogą ograniczyć rotację wymagań. Podobnie zespoły IT powinny być otwarte i realistyczne, jeśli chodzi o czas i zasoby potrzebne do tworzenia nowych funkcji lub spłacania długów.

Wykorzystaj usługi w chmurze. Chociaż “lifting and shifting” obciążeń lokalnych do chmury jest świetną opcją szybkiego przejścia do chmury, nie rozwiązuje problemu długu technicznego. W takim przypadku dług lokalny po prostu przenosi się do chmury. Aby zmaksymalizować korzyści z wdrażania chmury i zarządzać długiem technicznym, firmy muszą dobrze przemyśleć i dostosować swoje procesy lokalne do chmury. Wdrażanie aplikacji wymaga tego, co AWS nazywa „niezróżnicowanym ciężkim podnoszeniem”, takim jak zarządzanie hostingiem, przepustowością, umowami, pojemnością, operacjami i koordynacją między dużymi zespołami. Niewłaściwe zarządzanie którymkolwiek z tych obszarów może mieć negatywne konsekwencje i tym samym generować dług techniczny. Platformy chmurowe zapewniają gotowe elementy składowe potrzebne do tworzenia i utrzymywania oprogramowania. Pozwala to zespołom skupić czas na wartości biznesowej i innowacjach, a nie na wewnętrznych elementach IT. Udostępnianie infrastruktury, wdrażanie kodu, testowanie, wykrywanie zagrożeń, monitorowanie i ostrzeganie oraz odzyskiwanie po awarii można w pełni zautomatyzować w chmurze. Funkcje samonaprawy automatycznie zamykają niewykorzystaną infrastrukturę lub zwiększają skalę w odpowiedzi na zapotrzebowanie. Wiele usług w chmurze, takich jak przetwarzanie bezserwerowe i specjalnie zbudowane bazy danych, jest dostępnych jako w pełni zarządzane usługi z wbudowanymi funkcjami zapewniającymi wysoką dostępność i odporność. Oznacza to, że zespoły IT nie muszą przydzielać zasobów do zarządzania rutynowymi zadaniami.

Zastosuj sprawne praktyki i podejście natywne w chmurze. Przetwarzanie w chmurze dobrze nadaje się do sprawnego programowania i opiera się na zasadach eksperymentowania, elastyczności i dostarczania przyrostowego. Technologie natywne dla chmury obsługują szybkie i częste zmiany w aplikacjach bez wpływu na świadczenie usług. Sprawne podejście programistyczne przedkłada szybkość nad perfekcję i usprawnia współpracę biznes-technologia. Zarówno nowe funkcje, jak i dług techniczny są widoczne w ujednoliconym „rejestrze produktów”. Następnie zespoły nadają priorytet zaległościom i dostarczają przyrostową wartość w krótkich sprintach.

Dojrzałe praktyki rozwojowe. Przeglądy kodu, ustanowienie jasnych standardów projektowania i rozwoju, właściwa dokumentacja i automatyczne testowanie to techniki zmniejszania długu technicznego. Poza praktykami kodowania nowoczesne aplikacje wykorzystują luźno powiązane technologie i koncentrują się na komponentach sterowanych zdarzeniami i bezserwerowych. Nowoczesne aplikacje wykorzystują również zautomatyzowaną infrastrukturę, narzędzia operacyjne i zabezpieczające, aby poprawić niezawodność i spójność wdrażania oprogramowania. Wielokrotnego użytku i sprawdzone komponenty oprogramowania to doskonały sposób na przyspieszenie dostaw i zmniejszenie długu technicznego.

Trening/rozwój umiejętności. Wdrażanie nowych technologii wymaga wyposażenia pracowników w odpowiednie umiejętności, aby mogli podejmować świadome decyzje i skutecznie wdrażać te technologie. Rozważ przypadek technologii chmurowej: niedawne badanie AWS Global Digital Skills wykazało, że 87% pracodawców twierdzi, że inwestycje w szkolenie pracowników w zakresie umiejętności cyfrowych pozwoliły ich organizacjom szybciej osiągnąć cele transformacji cyfrowej. Z punktu widzenia pracowników ponad 80% respondentów zgłosiło poprawę wydajności pracy i wyższą satysfakcję z pracy. Czynniki te pomagają firmom w szybszym uzyskaniu zwrotu z inwestycji i zmniejszeniu długu technicznego.

Pomiar długu technicznego. Zaproponowano wiele podejść do pomiaru długu technicznego, takich jak złożoność cykliczna, pokrycie kodu, ocena squale, naruszenia zasad kodu, a nawet liczenie błędów oprogramowania. Chociaż zapewniają one pewne ilościowe miary jakości kodu, nie mierzą innych wymiarów, takich jak częstotliwość zmian wprowadzanych w kodzie. Kod, który ma niską jakość, ale jest rzadko zmieniany, powinien mieć niską pozycję przy ustalaniu priorytetu rozwiązania. Dług techniczny nie zawsze jest oczywisty, dopóki dobrze mu się nie przyjrzymy. Rok 2000 to klasyczny przykład tego, kiedy w oprogramowaniu „rok” był zapisywany za pomocą dwóch cyfr („75” zamiast „1975”) w latach 60. i 70. XX wieku. Na przełomie wieków stał się głównym długiem wszystkich firm. Dług techniczny ma znaczenie, gdy jest wyrażony w kategoriach wpływu na biznes, takiego jak złe doświadczenia klientów, utracone przychody, dłuższe cykle wydania i produktywność pracowników. Upraszcza to podejmowanie decyzji dotyczących inwestycji i ustalania priorytetów.

Końcowe przemyślenia

Dług techniczny jest realny i nie można go uniknąć. Dzieje się tak z powodu zarówno kontrolowanych, jak i niekontrolowanych czynników. Ryzyko zignorowania tego jest wysokie, ponieważ może to skutkować dłuższym czasem wprowadzania produktów na rynek, utratą przychodów i negatywnym wpływem na morale zespołu. Zespoły biznesowe i technologiczne muszą wspólnie zająć się długiem technicznym. Powinno to być widoczne i nadać temu priorytet. Technologie chmurowe oferują bowiem skuteczne sposoby przekształcania długu technicznego w dobrobyt techniczny.

Literatura uzupełniająca

Agile Alliance, D. W. (n.d.). Project Management and Technical Debt. Retrieved from https://www.agilealliance.org/project-management-and-technical-debt/

Fowler, M. (2009, October 14). TechnicalDebtQuadrant. Retrieved from https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Fowler, M. (2019, May 21). TechnicalDebt. Retrieved from https://martinfowler.com/bliki/TechnicalDebt.html

Schwartz, M. (2020, December 16). The CIO-CFO Conversation: Technical Debt—An Apt Term? Retrieved from https://aws.amazon.com/blogs/enterprise-strategy/the-cio-cfo-conversation-technical-debt-an-apt-term/

Whelan, J.-L. L. (n.d.). Introduction to the Technical Debt Concept. Retrieved from https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf

Źródło: AWS