Dług technologiczny - jak sobie z nim radzić?
Każdy kto był związany w jakikolwiek sposób z tworzeniem aplikacji spotkał się lub spotka się prędzej czy później z terminem długu technologicznego lub jak kto woli technical debt. Termin ten spędza sen z powiek każdemu managerowi i stackholderom, w każdej większej aplikacji.
Każdy kto był związany w jakikolwiek sposób z tworzeniem aplikacji spotkał się lub spotka się prędzej czy później z terminem długu technologicznego lub jak kto woli technical debt. Termin ten spędza sen z powiek każdemu managerowi i stackholderom, w każdej większej aplikacji. Zjawisko to ma swoje pozytywne, jak i negatywne efekty. Z pozytywnych - pewne decyzje i uproszczenia pozwalają nam na szybsze wdrażanie i testowanie pomysłów. Jeśli jednak nie będziemy odpowiednio dbać o poziom tech debt, to szybko możemy dojść do sytuacji, gdzie wdrażanie nowych funkcji w systemie, może okazać się bardzo drogie i czasochłonne
Z czego wynika ten problem?
Przy tworzeniu aplikacji na początkowych etapach zawsze bardzo duży nacisk kładzie się na jak najszybszy rozwój nowych funkcji. Presja jest duża, więc każdy ciśnie, ciśnie i gniecie, aż to co miało zostać zrobione, jest skończone i pojawiają się nowe, super ważne rzeczy do zrobienia. Ta strategia przynosi wiele korzyści i pozwala szybko uruchomić produkt na rynek. W tym samym czasie jednak prowadzi do tego, że fundamenty naszego produktu mogą być nie najlepsze. Ciągła presja czasu powoduje, że zespół developerski często świadomie lub nie zgadza się na gorsze rozwiązania, celem zaspokojenia klienta. W związku z tym pewne rzeczy, mogą nie zostać zaimplementowane w najlepszy możliwy sposób, a skutki zaczynamy odczuwać po czasie.
Sytuacja tego typu jest częstą praktyką i nie rozpatrywałbym jej w kategoriach ogromnej tragedii dla projektu ale tylko i wyłącznie, jeśli odpowiednio nasz dług zaadresujemy. Jeśli jednak w pore nie zareagujemy, to możemy być bardziej niż pewni, że odbije się to na projekcie ogromną czkawką.
Zatem jak sobie z tym radzić?
Przede wszystkim trzeba mieć świadomość tego co u nas potencjalnie może wymagać poprawy. Oczywiście nie da się jasno wytypować wszystkich elementów, a w zależności od zaawansowania projektu i ilości skrótów może być tego bardzo dużo.
Zacznijmy od tego, że najprostszym sposobem jest zapisywanie wszystkich elementów, które budzą niepokój programistów. Każdy szanujący się manager powinien zachęcać do tego swój zespół żeby identyfikować i zgłaszać każdy potencjalny problem.
Natomiast każdy spisany element należy wrzucić do oprogramowania do zarządzania zadaniami. Każdy zidentyfikowany element niech zostanie wrzucony do osobnego taska/karteczki i co jakiś czas rewidujmy te elementy i dodawajmy je do scope pracy, która jest zaplanowana na najbliższy tydzień (odpowiednio priorytetyzując elementy, które są bardzo ważne dla naszej aplikacji naprawiajmy jak najszybciej, a elementy mniej ważne zostawmy na luźniejszy okres w projekcie).
Powtarzające się problemy dodawajmy do DoD. Jeśli zadbamy o to, aby eliminować najczęściej występujące rzeczy procesowo, będziemy pewni, że nasza aplikacja nagle nie zaskoczy nas ogromnymi rzeczami.
I na koniec bądźmy konsekwentni, najlepiej od samego początku życia naszego projektu. Jeśli jednak nie robiliśmy tego odpowiednio wcześnie, to nie ma lepszej chwili niż teraz. Lepiej późno niż wcale.
Podsumowanie
Podsumowując. Z długiem technologicznym musimy się zaprzyjaźnić. Odpowiednie zarządzanie potencjalnymi problemami spowoduje, rozwijanie aplikacji wcale nie musi stać się bardziej czasochłonne. Wspierajmy zbieranie i rozwiązywanie problemów technicznych na codzień. W szczególności rozwiązujmy na bierząco problemy w najbardziej kluczowych elementach aplikacji, a użytkownicy zawsze będą zadowoleni z jakości rozwiązań, a nam nie zdarzy się sytuacja, że dodanie nowej funkcji wywoła u developerów stan przedzawałowy.
Żródła: