Jednym z argumentów przeciwko wykorzystaniu metodyk zwinnych w procesie wytwarzania oprogramowania jest pojawiający się dług technologiczny. Czym jest i dlaczego jest jednym z ulubionych argumentów przeciwników metodyk agile?
Czym jest dług technologiczny?
Sformułowanie „dług technologiczny” pojawiło się na długo przed metodyką Scrum czy Agile Manifesto i powstało jako odpowiednik długu finansowego znanego z nam ekonomii. Nie można i nie powinno się więc utożsamiać go w prosty sposób ze zwinnym podejściem.
Termin wymyślony przez Warda Cunninghama określa ukryty koszt przyszłych prac czyli wszystkie te rzeczy, które nie wynikają bezpośrednio z realizowanych zadań, ale są konieczne do wykonania przy okazji albo zanim będziemy w stanie zabrać się za pracę właściwą.
Zdefiniowany w ten sposób, dług technologiczny będzie obejmował zarówno prozaiczne „posprzątanie biurka”, poprawne skonfigurowanie środowiska deweloperskiego czy aktualizację wykorzystywanych bibliotek. Jeżeli musimy coś zrobić, a nie przynosi nam to żadnych korzyści to będzie to właśnie dług. Szczególnie, jeśli uświadomimy sobie, że mogliśmy jemu zapobiec lepiej wykonując naszą pracę.
Jak wygląda dług technologiczny?
Każdą funkcjonalność, nad którą pracujemy, można albo zaimplementować w prosty i szybki sposób, który będzie wymagał dodatkowych prac w przyszłości lub w bardziej skomplikowany i bardziej wymagający, ale starający się przewidzieć przyszłe wymagania i zastosowania.
Podjęcie decyzji w powyższej sytuacji nie jest proste. Z jednej strony agilowe podejście podpowiada – wybierz opcję pierwszą. Z drugiej zaś, szczególnie dla początkujących adeptów technik zwinnych, podejście drugie jest kuszące. Bo przecież jeśli coś robimy, zróbmy to dobrze.
W żadnym przypadku nie dostarczamy produktu niskiej jakości. Po prostu np. zamiast tworzyć interfejs użytkownika z listami wartości używamy pól, w których wprowadzić można dowolną, niewalidowaną wartość albo zamiast optymalizować kod pod tysiące równoległych wywołań (których jeszcze nie mamy) zadowalamy się rozwiązaniem pracującym sekwencyjnie.
Wybierając opcję pierwszą zaciągamy niejako „pożyczkę” na przyszłe prace. Dlaczego? Bo wiemy, że implementując wymaganie w prostej, szybkiej formie istnieje szansa, że w przyszłości będziemy musieli dokonać kosztownych modyfikacji.
Czasami nam się uda i funkcjonalność pozostanie używana w niezmienionej formie, a czasami nasze pójście na skróty wyjdzie nam bokiem. A pamiętajmy, że przeróbki zawsze są bardziej kosztowne, niż tworzenie od zera.
Przyczyny powstawania długu
Dlaczego decydujemy się na zaciąganie długu wiedząc, że jego spłacenie w przyszłości może być bardziej kosztowne? Implementując funkcjonalność w prostej postaci dajemy sobie szanse na szybsze dostarczanie działającego oprogramowania i spełnienie większej liczby wymagań. To z kolei może spowodować większe zadowolenie klienta, co zasadniczo jest naszym celem w metodykach zwinnych.
Inną przyczyną powstania długu technologicznego może być nasze Definition of Done. Zapisy znajdujące się w DoDa mogą zezwalać na odbieranie wymagań pomimo istnienia błędów o określonej (niskiej) kategorii. Nagromadzenie tych błędów spowoduje dług technologiczny, który kiedyś w końcu będzie trzeba „spłacić”.
Kolejną możliwością powstania zobowiązania na przyszłość jest odkładanie na później wymagań niefunkcjonalnych. Do głowy przychodzi np. wydajność aplikacji lub jakość kodu. Dla użytkownika końcowego są one „niewidoczne”, a więc nie znajdują się wysoko na liście priorytetów. Szczególnie, jeśli nie dba o to także Product Owner. Oczywiście, unikanie tego typu prac wcześniej czy później spowoduje konieczność ich wykonania, co będzie spłaceniem długu zaciągniętego w przeszłości.
Czasami zdarza się też tak, że po prostu nie jesteśmy świadomi powstawania długu technologicznego. Ani kierownictwo, ani tym bardziej zarząd nie będą świadomi tego, co tkwi w sercu tworzonego systemu. Dlatego tak ważna jest pełna transparentność na poziomie Zespołu Scrumowego. Jeżeli Development Team śrubuje normy velocity, ale robi to kosztem bałaganu w kodzie, to nie powinien tego zamiatać pod dywan. Ta informacja powinna wędrować dalej.
A może nie taki dług straszny?
Oddając małe kawałki oprogramowania, nawet z długiem, możemy zweryfikować ich użyteczność w praktyce. O to też przecież chodzi w zwinnym podejściu.
Jeżeli dana funkcjonalność np. nigdy nie będzie używana masowo, możemy nawet nie dowiedzieć się, że wymaga optymalizacji. Tak samo nieergonomiczny według nas interfejs może zyskać sympatię rzeczywistych użytkowników. Poruszamy się przecież po domenie złożonej Cynefin frameworku. Nie możemy przewidzieć w szczegółach w jaki sposób będzie wykorzystywane nasze dzieło.
Nie da się ukryć, że pracując iteracyjnie poniekąd „skazani” jesteśmy na pracę z długim technologicznym. Odpowiednie nim zarządzanie spowoduje jednak, że nie będzie „wybuchał” nam w przyszłości w najmniej oczekiwanych momentach. Nie wszystkie problemy niefunkcjonalne to czarne łabędzie, wiele z nich jesteśmy w stanie przewidzieć i zaplanować.
Nie możemy ich także odkładać w nieskończoność. Świadomy Product Owner powinien odpowiednio „zainteresować” interesariuszy tego typu wymaganiami i priorytetyzować je na równi z wymaganiami funkcjonalnymi. Jak to zrobić? Odpowiednio argumentując potrzebę ich wykonania i wskazując płynące z nich korzyści.
Podobnie rzecz ma się z błędami, o których nie powinniśmy zapominać, bo odbierając wymaganie zgodnie z Definition Of Done zidentyfikowaliśmy ich istnienie.
Inwestycja w przyszłość
Dług technologiczny, to prócz niskiej jakości inkrementu, najczęściej wykorzystywany argument przeciw stosowaniu Agile. W obu przypadkach oponenci podejścia zwinnego nie mają racji. Niestety, mnogość problemów zarówno z jakością jak i długiem technologicznym sugeruje, że jest to problem związany z tym podejściem.
Nie patrzmy jednak na negatywne przykłady i „prawie” zwinne rozwiązania. Nie sugerujemy się problemami innych, ale wykorzystajmy je do wyciągnięcia lekcji, za które sami nie musimy zapłacić.
Czy powinniśmy więc bać się długu technologicznego? Nie! Podobnie jak w przypadku kredytu inwestycyjnego, zaciągając go dziś wiemy, że będziemy musieli zwrócić go w przyszłości wraz z odsetkami. Najważniejsze jest jednak to, co dziś zrobimy z dostępnymi środkami. Ich odpowiednie zainwestowanie dziś spowoduje korzyści, które mogą przewyższać koszta w przyszłości.
Podobnie rzecz ma się z długiem technologicznym. Potraktujmy go jako inwestycję w dzisiejsze korzyści, kosztem prac w przyszłości.
Dług technologiczny omawiamy między innymi na szkoleniach dotyczących zarządzania Scrumem. Jeżeli jesteś zainteresowany, jak można się go pozbyć, skontaktuj się z nami.
Zdaję mi się, że nazwa „dług TECHNICZNY” jest lepszym polski tłumaczeniem tego zjawiska. Sam często niestety się mylę i używam tego terminu ze słowem „technologiczny” – taka nazwa jednak sugeruję trochę, że problem powstał z powodu jakiegoś wyboru użytej w projekcie technologii. A termin jest jednak szerszy i dotyczy wszystkich decyzji projektowych – co opisujecie dobrze w artykule 😉 Gdy decydujemy się na pominięcie jakichś etapów, przyspieszenie prac kosztem jakości, bo nam się spieszy – zapewne generujemy dług techniczny.