coding Jeśli uczestniczysz w procesie wytwarzania oprogramowania na pewno choć raz słyszałeś pojęcie: “dług techniczny”.
Jeśli pełnisz rolę Analityka w projekcie IT zapewne nie zwracałeś na niego uwagi mimo, że jest nieodłącznym elementem każdego projektu. Być może to przeoczenie wynika z tego, że dług techniczny to przecież “to wina programistów”. Czy na pewno? Czy dług techniczny pojawia się wtedy, kiedy programiści idą na skróty?
A może jako Analityk masz wpływ na to, kiedy dług się pojawi w projekcie?
1. Czym jest dług techniczny?
Termin: “Dług techniczny” nazywany czasem “długiem technologicznym” został wprowadzony prawie 30 lat temu. Autorem tego terminu w 1992 roku był Ward Cunningham- pionier w dziedzinie wzorców projektowych, ale również współtwórca “Agile Manifesto”.
W. Cunningham zwrócił uwagę na to, jak bardzo ważne jest zachowanie równowagi pomiędzy: szybkim tworzeniem oprogramowania, aby tylko działało, a późniejszymi pracami związanymi z ulepszaniem kodu, bądź jego poprawianiem we fragmentach, które zostały pominięte, bądź ucierpiały w wyniku tego pośpiechu.
To odwieczny problem, z którym mierzymy się w każdym projekcie: rozwiązanie ma działać czy kod ma być ładny? Idealnym rozwiązaniem byłoby zachowanie tych dwóch elementów na najwyższym poziomie. Pytanie tylko czy w dobie szybkiego dostarczania produktów na rynek da się uzyskać taki stan?
W pośpiechu programiści nie skupiają się na architekturze czy wzorcach projektowych. Miałoby to miejsce, gdyby nie odczuwali presji ze strony kierownictwa, które bardziej skupione jest na “dowożeniu” działających fragmentów oprogramowania nie zwracając uwagi na to, z jak dużymi kosztami przyjdzie nam się zmierzyć w momencie kiedy przejdziemy do fazy utrzymania dostarczonego oprogramowania.
Definicja długu technicznego:
Technical Debt includes those internal tasks you choose not to do now, but it runs a risk of causing future problems if not done.W.Cunningham, 1992
