Blog

laptop.jpg

Category: Expertise strategy

Crunch w IT - czy wiesz, jak mu zapobiec?

Kamil Naja, Programista Front-end emagine, 14/12/2023

Temat Crunchu pojawia się zwykle w odniesieniu do branży gier komputerowych. Przykładowo, przed wydaniem gry Cyberpunk 2077, deweloperzy pracowali przez naprawdę długi i nadprogramowy czas (mówi się nawet o tym, że spędzali na pracy po 16 godzin dziennie). Czy dało to pożądane efekty? Nie - jak wszyscy wiemy, gra w dniu premiery działała bardzo słabo i nie zawierała wszystkich funkcji, które obiecywał twórca.

Crunch dotyka też pozostałe obszary IT. W poniższym artykule opiszę główne przyczyny takiej sytuacji, skutki crunchu oraz sposoby, jak mu zapobiec.

Gdy chcemy wybudować dom, nie zaczynamy prac, dopóki nie mamy konkretnego planu, czy projektu. Osoba tworząca plan musi uwzględnić w nim wiele czynników - gdzie mają przebiegać rury, jakie są wymagania dotyczące materiałów i gdzie mają być okna. Dopiero potem można zacząć wylewać fundamenty i budować ściany. Musimy też mieć pewność, że do domu będzie można podciągnąć prąd, jeszcze przed rozpoczęciem mieszania betonu. Jaki z tego morał? Wszystko wymaga planowania.

Złe zaplanowanie projektu:

Projekty programistyczne powinny zawsze rozpoczynać się myślą, że robimy wszystko, aby końcowy odbiorca był w pełni zadowolony z rezultatów. Zarząd projektu lubi też pokazać zarys rezultatu klientowi (GUI). Front-end to jednak nie wszystko. Aplikacja do działania wymaga też warstwy back-endowej z bazą danych. Tutaj zarząd wiele nie pokaże. Trzeba zdać się na zapewnienia i dobre planowanie.

Najmniej oczekiwanym etapem działań jest analiza, ponieważ podczas niej nie powstaje nic wartego pokazania. Z tego powodu tworzy się nieoptymalne rozwiązania, które następnie zostają w projekcie i są powielane w kolejnych funkcjonalnościach.

Podejście komponentowe, w którym najpierw tworzymy małe, reużywalne elementy GUI ma sens z punktu widzenia późniejszego przyśpieszenia prac, jednak również może być niemile widziane przez managerów projektu. Taki sposób działania nie daje wrażenia, że tworzone są kolejne widoki wymagane przez klienta. Mamy tutaj rozdźwięk między najlepszymi praktykami programowania a oczekiwaniami osób nietechnicznych.

Nowe funkcjonalności zawsze wydają się dla klienta bardziej kuszące od tych, które są w trakcie tworzenia. Nie wolno jednak zapominać, że najpierw coś tworzymy, następnie dopracowujemy i poprawiamy, a dopiero potem, zaczynamy nowe rzeczy. Nie jest możliwe robienie jednocześnie nowych rzeczy i poprawianie starych.

laptop.jpg

Brak współpracy między zespołami:

Modelowym przykładem może być tworzenie dwóch warstw aplikacji bez porozumienia między zespołami, co mocno utrudnia integrację. Przykładowo, front-end może integrować się z back-endem, jednak na back-endzie ciągle trwają prace nad bazą danych i kontrakt będzie prawdopodobnie zmieniany wielokrotnie. Integracja powinna odbywać się, gdy warstwy są gotowe.

Nie może dochodzić do sytuacji, gdy jedna z warstw aplikacji zmienia kontrakt bez informowania użytkowników, ponieważ prowadzi to do powstania błędów. Aplikacja back-endowa nie powinna przesyłać zbyt dużej ilości danych, ponieważ utrudnia to pracę jej konsumentom i zwiększa ilość danych przesyłanych przez sieć. Rozwiązaniem tego problemu może być używanie GraphQL, jednak zwykle korzysta się z już istniejących rozwiązań, czyli RestApi.

Jeśli mamy sytuację, w której integrujemy się z kilkoma aplikacjami, na które mamy jakiś wpływ (są na przykład tworzone przez inne zespoły w naszej firmie), należy zwrócić szczególną uwagę na spójność API. Tworzenie podobnych odpowiedzi API, używanie tego samego formatu daty i tych samych obiektów, potrafi znacząco uprościć pracę. Niektóre zmiany są o wiele łatwiejsze do zrobienia w jednej warstwie, natomiast w innej, będą powodowały konieczność zmieniania danych w wielu miejscach. Takie kwestie powinny być ustalone na wczesnym etapie prac.

W przeciwnym razie będziemy tracić czas na żmudne przemapowywanie danych, zamiast na rozwiązywanie problemów klienta.


 

Wszystko wymaga planowania. Crunch dotyczyć może wielu obszarów projektowania w IT.

Kamil Naja

 

Brak informacji zwrotnej od klienta:

Jednym z powodów stosowania metodologii Scrum, jest otrzymywanie feedbacku od klienta. Wracając do analogii domu, klient powinien wiedzieć na wczesnym etapie prac, gdzie będą drzwi. Pokazujemy mu to nie wstawiając drzwi w kilku miejscach, tylko na planie. Największy problem powstaje wtedy, gdy dom jest już otynkowany, ale klient przypomina sobie, że chce przenieść całkowicie jedną ze ścian i wstawić w niej drzwi, bo obecne mu nie odpowiadają.

Niestety, ale w projektach programistycznych dzieje się podobnie. Zwykle aplikacja jest wydawana regularnie co jakiś czas, jednak feedback zbierany jest podczas jednego testu akceptacyjnego. W takiej sytuacji klient zwykle znajduje kilkadziesiąt rzeczy, które powinny działać w jego odczuciu inaczej. Jeśli są to drobne zmiany, można uniknąć crunchu. Jeśli dotykają one głównych elementów działania aplikacji, mogą wiązać się z koniecznością usuwania starego kodu i tworzenia rozwiązań od nowa. Powoduje to frustrację, nieufność i siedzenie po godzinach.

Rozwiązaniem jest zbieranie feedbacku od klienta jak najwcześniej i regularne reagowanie na zmiany.  Dzięki temu będziemy wiedzieli także, w jaki sposób tworzyć nowe elementy i unikniemy wielu błędów. Błędy logiczne w działaniu aplikacji odkryte na etapie analizy są wielokrotnie mniej kosztowne w naprawie niż te, które zostaną znalezione na produkcji.

Jeśli dopiero po pokazaniu gotowej aplikacji klientowi dostajemy feedback, że działa ona inaczej, niż on oczekuje, jest to oznaka błędów w zbieraniu wymagań i ogólnie, analizy aplikacji. Dodatkowe godziny spędzane przez programistów nie rozwiążą tego problemu.

Chcesz wiedzieć więcej?

Pomożemy Ci odnieść sukces w roli niezależnego konsultanta IT.

Ciągłe zmiany bez planowania:

Programistyczne przysłowie mówi że “wymagania są jak woda, łatwiej się po nich poruszać, gdy są zamrożone”. W metodologii Agile praca modelowo powinna wyglądać tak, że ustalamy zakres sprintu i następnie go realizujemy. Zmiany powinny być w jakiś sposób udokumentowane, najlepiej w formie makiet, historyjek użytkownika oraz opisów. W przypadku skomplikowanych procesów dobrze jest też mieć diagramy przedstawiające, jak one działają.

Zmiany od klienta powinny być najpierw odzwierciedlone w formie zmian dokumentacji, a następnie planowane i realizowane. Niestety, ale w wielu projektach dochodzi do sytuacji, gdy zmiany są wprowadzone chaotycznie w kodzie programu i następnie dokumentacja przestaje być aktualna. Dochodzi wtedy do sytuacji, że przestajemy wiedzieć, jak aplikacja ma działać. Jeden członek zespołu może wprowadzać zmiany, następnie tester lub członek teamu zgłasza, że są one błędne, gdyż nie były one uwzględnione w makietach i dokumentacji. O wiele lepiej jest regularnie uzupełniać dokumentację, tak by mieć jedno źródło prawdy, i następnie omawiać te zmiany ze wszystkimi członkami zespołu. Losowe zmienianie funkcjonalności (zwłaszcza 2 godziny przed wydaniem aplikacji) to prosta droga do katastrofy. Zmiany dodawane ad hoc mogą mieć też negatywny wpływ na spójność działania aplikacji, często naprawiają jeden błąd, ale prowadzą do innych.

Zmiany bez planowania prowadzą też do zaniedbania testów jednostkowych. Skoro aplikacja zmienia się kilka razy i nikt nie wie, jak ma działać, nie jest możliwe ani stosowanie Test Driven Development, ani nawet napisanie testów logiki biznesowej. W takiej sytuacji testy jednostkowe powinny być uzupełnione po tym, gdy ustalimy jak aplikacja ma działać.


 

'wymagania są jak woda, łatwiej się po nich poruszać, gdy są zamrożone'...

 

Brak odpowiedniej infrastruktury:

W mojej analogii domu wspomniałem, że zanim na budowę wjadą betoniarki, musimy mieć prąd. W projektach programistycznych także potrzebujemy prądu, ale także wydajnych narzędzi CI/CD, sprawnie działających środowisk, dostępów, licencji i odpowiedniej ilości kawy. 🙂

Nawet najlepszy zespół programistów i analityków nie da rady, jeśli każdy build aplikacji będzie trwał godzinę, aplikacja nie będzie mogła być testowana, a testerzy nie będą mieli dostępów. Rolą osób zarządzających projektem powinno być usuwanie takich przeszkód na bieżąco.

Tracenie czasu na powtarzalne zadania:

Starajmy się wyeliminować jak najwięcej nudnych, codziennych zadań, które nie wnoszą nic do projektu i zabierają czas. Można to zrobić na wiele sposobów - od generowania kodu na podstawie kontraktu, przez używanie nowoczesnych narzędzi programistnych i sztucznej inteligencji.

Powtarzalnym zadaniem jest też zaimplementowanie tych samych funkcjonalności w kilku miejscach przez różne osoby, bez używania już istniejących rozwiązań.

 

Podsumowując, jeśli crunch pojawia się regularnie, jest to prawie zawsze oznaką nieprawidłowego działania procesów w firmie, złego planowania i niewystarczającej infrastruktury.

Kamil

Kamil Naja

Programista front-end
Specjalista realizujący projekty dla klientów emagine. Programista Front-end od początków kariery w IT, którą rozpoczynał w 2016 r. Blogger i propagator wiedzy w swojej dziedzinie.

Blog

Więcej wpisów na blogu

left-arrow
right-arrow

Grafowa baza danych rewolucjonizuje zarządzanie informacjami
Expert stories
Webinar

Grafowa baza danych rewolucjonizuje zarządzanie informacjami – odpal zapis webinaru

Już jest! Zapis webinaru pt. Grafowa baza danych rewolucjonizuje zarządzanie informacjami… czyli o Neo4j z perspektywy front-endowca.

Expert stories

Crunch w IT – czy wiesz, jak mu zapobiec?

Temat crunchu pojawia się zwykle w kontekście branży, która tworzy gry komputerowe. Problem jednak nie dotyczy tylko tego sektora rynku. Crunch zdarza się wszędzie. Są jednak sposoby, aby mu zapobiec.

Expert stories

Idealna współpraca testera z programistą – czy to w ogóle możliwe?

W idealnym zespole programistycznym feedback od klienta przekłada się na świetne wymagania. Są one następnie zamieniane na dokładnie opisane zadania, w których jest wszystko ,co niezbędne do wykonania i testowania aplikacji. W rzeczywistości jednak taka sytuacja nigdy nie występuje. Jak to zmienić?

Wszystko o pracy testera oprogramowania - odpal zapis webinaru
Expert stories
Webinar

Wszystko o pracy testera oprogramowania – odpal zapis webinaru

„5 najważniejszych lekcji, które wyniosłem w ciągu 5 lat testowania oprogramowania” … czyli o ewolucji tego obszaru IT, umiejętnościach testera oraz efektywności w zawodzie opowiada konsultant emagine – Piotr Tuński.

Expert stories

Różne podejścia do generowania kodu front-end – czy znasz je wszystkie?

Jak pisałem w poprzednim artykule, kod front-endowy jest w pewnej mierze powtarzalny. Szczególnie dużo powtarzalności jest na granicy back-endu i front-endu. Ponieważ obiekty z bazy są przesyłane z back-endu, frontend odbiera je i typuje (jeśli używamy np. TS) w celu dalszego przetwarzania. Co dzieje się dalej?

Expert stories

AI zbuduje aplikację webową? To możliwe!

Od jakiegoś czasu dysponujemy narzędziem, które jest w stanie przezwyciężyć początkowe trudności w zbudowaniu prototypu aplikacji webowej. Jest nim oczywiście Sztuczna Inteligencja, która – w odpowiednich rękach – może pomóc rozwiązać wiele problemów deweloperów.

Expert stories

Nx dla Angular jako niezawodne narzędzie upraszczające pracę przy projektach IT

Nx to narzędzie, które upraszcza budowanie projektów typu monorepo. W tym artykulę skupię się na jego głównych zastosowaniach w aplikacjach używających Angulara. Narzędzie pozwala także na współpracę z wieloma innymi technologiami, jak React czy Node.

Expert stories

7 grzechów głównych w zapewnianiu jakości: błędy, których powinien unikać każdy tester!

Zagłębimy się w mroczne zakamarki branży testowania oprogramowania. Odkryjemy siedem grzechów głównych, które mogą zaszkodzić dążeniu do doskonałej jakości produktu. Poznaj, jakie pułapki czyhają na testerów i jak unikać tych błędów, prowadząc swój zespół ku ścieżce doskonałości w testowaniu.

Expert stories

Zarządzanie finansami w chmurze, czyli wszystko o FinOps

W miarę jak organizacje coraz bardziej polegają na chmurze obliczeniowej, pojawia się potrzeba skutecznego zarządzania kosztami i optymalizacji wydatków związanych z usługami chmurowymi. FinOps to obszar działalności, który w znacznym stopniu zmienia sposób tego zarządzania. Chcesz wiedzieć więcej?

Dyrektywa NIS2 dot. cyberbezpieczeństwa
Expert stories
Webinar

Już jest – zapis webinaru “Dyrektywa NIS2 dot. cyberbezpieczeństwa”

W obliczu coraz bardziej skomplikowanych zagrożeń związanych z cyberprzestrzenią, bezwzględnym priorytetem dla organizacji na całym świecie staje się zabezpieczenie danych oraz infrastruktury online. Nasz ekspert Grzegorz Powichrowski wesprze Was w ocenie przygotowania firm do spełnienia wymogów Dyrektywy NIS2 w dziedzinie cyberbezpieczeństwa.

Expert stories

Dla specjalistów IT: W jaki sposób odciążyć umysł w pracy

Od kilku lat interesuję się wydajnością pracy i w tym artykule chciałbym przedstawić najważniejsze metody, które wg mnie pozwolą pracować łatwiej i wydajniej w środowisku IT.

Expert stories

Microsoft Dev Box – nowoczesna maszyna robocza

Microsoft Dev Box to zwirtualizowane rozwiązanie, które umożliwia inżynierom IT szybkie uruchamianie samoobsługowych stacji roboczych wstępnie skonfigurowanych do ich zadań, przy jednoczesnym zachowaniu scentralizowanego zarządzania w celu maksymalizacji bezpieczeństwa i zgodności ze standardami w organizacji. Czy już je znasz?

Expert stories

Wymagania niefunkcjonalne w procesie tworzenia aplikacji

Podczas rozwijania aplikacji webowej zwykle odkrywamy szereg specyficznych funkcjonalności, wedle których ma ona działać. Niektóre z nich mogą wydawać się oczywiste dla części członków zespołu IT pracującego nad rozwiązaniem, jednak inni wolą mieć je spisane w szczegółowej formie, aby móc je wszystkie zaimplementować lub testować.

Expert stories

Najlepsze praktyki w zakresie bezpieczeństwa łańcucha dostaw oprogramowania

Łańcuch dostaw oprogramowania to „proces dostarczania produktu do klienta” w domenie IT, odnosi się do procesu projektowania, budowania, dostarczania i utrzymania. Jego bezpieczeństwo jest nie tylko ważnym, ale wręcz kluczowym aspektem współczesnego świata IT.

AI: Nowa fala przyszłości"
Expert stories
Webinar

Obejrzyj zapis webinaru “AI: Nowa fala przyszłości”

Szansa cywilizacyjna, czy też zagrożenie? Algorytmy sztucznej inteligencji od wielu lat stanowią jeden z centralnych punktów dyskusji o przyszłości technologii. Rozwiązania oparte na AI, niezależnie od poziomu organizacji na którym zostaną wykorzystane, pomogą stworzyć nowatorskie modele biznesowe. Sprawdźcie zatem, czy Wasza organizacja jest do tego dobrze przygotowana. Czego się spodziewać? Jak wykorzystać AI, aby tworzyć przewagę konkurencyjną na rynku?

Expert stories

Snapshot testing w aplikacjach front-endowych – czy wiesz już wszystko?

Jednym z największych wyzwań podczas tworzenia aplikacji front-endowych jest unikanie wprowadzania niechcianych zmian. Testowanie logiki biznesowej jest możliwe za pomocą testów jednostkowych, jednak nie sprawdzają one zwykle całej struktury HTML. Rozwiązaniem problemu regresji w plikach HTML może być snapshot testing.

Expert stories

Przyszłość sztucznej inteligencji – jakie wyzwania i możliwości stoją przed światem IT?

Przyszłość sztucznej inteligencji (SI) niesie ze sobą zarówno wyzwania, jak i ogromne możliwości rewolucji technologicznej. Zewsząd słyszymy, że SI przejmie we wszystkim kontrolę i my jako ludzie będziemy już mniej potrzebni lub wręcz zbędni – czy aby na pewno?

Expert stories

Efektywne sposoby na pracę z back-endem

Aby tworzyć rozwiązania front-endowe, zwykle pobieramy dane z aplikacji back-endowej. W tym artykule chciałbym przedstawić, w jaki sposób możemy udoskonalić i przyspieszyć tę pracę. Podstawowe czynniki, które wziąłem pod uwagę podczas analizy, to elastyczność pracy oraz to, czy programista używający API, może edytować dane zwracane przez back-end.

Expert stories

Neo4j: Grafowa baza danych rewolucjonizuje zarządzanie informacjami

Wraz z gwałtownym wzrostem ilości danych na znaczeniu zyskują nowoczesne rozwiązania bazodanowe. Jednym z najciekawszych i najbardziej innowacyjnych rozwiązań jest neo4j – grafowa baza danych, która rewolucjonizuje sposób przechowywania i analizy informacji. W tym artykule przyjrzymy się bliżej temu fascynującemu narzędziu, poznamy jego zalety, funkcje oraz praktyczne zastosowanie.

Expert stories

Jak AI wspiera pracę Front-end developerów – praktyczny poradnik

Z perspektywy front-endowca w ostatnim roku zauważyłem jak bardzo zastosowanie nowoczesnych narzędzi pomaga w szybszym tworzeniu aplikacji i sprawia, że pozbawione są one błędów. W artykule opisuję zastosowanie ChatGPT, Github Copilot oraz Github Copilot Chat, określając je skrótowo mianem AI.

Expert stories

Wypalenie zawodowe specjalistów IT – jak je przewidzieć i jak mu zapobiec?

Na pewno każdy z nas chociaż raz czuł, że w jego pracy coś idzie inaczej, niż by chciał. Dochodzi to tego zmęczenie, stres, spadek motywacji i nagle cały zawodowy świat się wali – zaczynamy myśleć, czy to, co robimy ma sens, czemu dotychczasowe działania nie przynoszą pożądanych efektów. Innymi słowy, wpadamy w rozmyślania nad tym, jak jest ciężko. Najczęściej to tylko zmęczenie, brak odpoczynku, stres, natomiast kiedy warto zadbać o siebie bardziej i przekonać się, czy to nie jest wypalenie zawodowe?

Expert stories

Jak skutecznie zbudować i utrzymać relację z kandydatem podczas procesu rekrutacyjnego w IT

Branża IT od dawna  jest  jedną z najbardziej dynamicznie rozwijających się dziedzin rynku, niezależnie od szerokości geograficznej. Tym bardziej, znalezienie odpowiedniego kandydata do realizacji projektów IT, który spełniałby wszystkie wymagania zarówno pod względem wiedzy i umiejętności technicznych, jak i kompetencji miękkich nigdy nie było czymś prostym.

Expert stories

Poznaj kompetencje miękkie przyszłości w obszarze sprzedaży

Inwestycja w kompetencje miękkie może szczególnie opłacić się w zawodach przyszłości. W przeciwieństwie do twardych, kapitałem nie jest wykształcenie czy fachowa wiedza. Soft skills pozwolą tym, którzy je wdrożą i oswoją, z lekkością adaptować się do zmian jakie czekają rynek pracy.

Paweł Pancerz
Expert stories

Rozwój Chmury – co czeka nas w najbliższej przyszłości?

W ciągu ostatnich lat rozwój technologii chmurowych zmienił się bardzo dynamicznie. Wymogi rynkowe oraz coraz większa świadomość w zakresie potencjału technologii chmurowych sprawiają, że obawy przed tą technologią IT są coraz mniejsze.

Marcin Kosiński
Expert stories

Efektywna praca zdalna w innej strefie czasowej

Zdalna praca w innej strefie czasowej  jest możliwa, gdy w zespole panuje odpowiednia dyscyplina.

ichał Mrozowski, Starszy Analityk Biznesowy, Scrum Master
Expert stories

10 cech dobrego Scrum Mastera

Czy każdy nadaje się na Scrum Mastera? Jeśli zespół poszukuje Scrum Mastera, który wniesie wartość dodaną i będzie dla niego wsparciem – a nie tylko prowadzącym ceremonie – powinien szukać osoby posiadającej konkretne cechy.