Category: Expertise strategy
Kamil Naja, Programista Front-end emagine, 14/11/2023
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ć?
Programista zwykle dopytuje biznes lub analityków, grafików, UX designerów o szczegóły projektu. Dużo wiedzy może bowiem znajdować się w rozproszeniu. Następnie tester sprawdza rozwiązanie i może nie mieć pewności, dlaczego niektóre rzeczy działają tak, a nie inaczej. To samo działa w drugą stronę - zgłoszenia testera mogą zawierać wszystkie informacje i dotyczyć jedynie rzeczywistych bugów, częściej jednak zdarza się, że informacje trzeba uzupełniać, o zmienne dopytywać i je wyjaśniać. Nie ma w tym nic złego, o ile będziemy robić wszystko, by stale ulepszać naszą współpracę. Są sposoby na to ulepszenie. W tym artykule postarałem się je wylistować.
Z perspektywy programisty zauważam następujący wzór zachowań. Funkcjonalność jest opracowywana przez kilka dni / tygodni bez obecności testera, a następnie po jej wydaniu, tester zadaje programiście sakramentalne pytanie - Jak to ma działać. Wynika ono z braku wiedzy biznesowej na temat funkcjonalności.
Współpraca nad rozwojem aplikacji powinna przebiegać wspólnie. Testowanie nie powinno też polegać na testowaniu jedynie tych rzeczy, o których tester dowiedział się od twórcy GUI. Dobrym rozwiązaniem może być pokazanie testerowi na początku implementacji, jakie funkcjonalności będziemy robić i omówienie, z czego to wynika.
Łatwiej jest zrozumieć działanie aplikacj,i gdy widzimy już interface użytkownika, niż na podstawie suchej dokumentacji. Na wczesnym etapie łatwiej jest też wprowadzić ewentualny feedback od testera. Tester może uczestniczyć także w spotkaniach dotyczących działania aplikacji, odbywających się na początku sprintu.
Warto też umieszczać komunikację dotyczącą funkcjonalności i decyzji w Jirze.
Temat można też ująć w odwrotny sposób, ponieważ problem nie dotyczy tylko testerów. Programista spędza kilka dni nad funkcjonalnością, której do końca nie rozumie, bo nie brał udziału przy jej tworzeniu. Wartościowe byłoby wtedy spotkanie się z testerem i omówienie przypadków testowych, które obecnie już istnieją. Osoba, która ma większe doświadczenie z danym komponentem, powinna pomóc tej mniej doświadczonej w rozpoczęciu efektywnej pracy.
Wymagania, które często się powtarzają lub muszą być zaimplementowane stale, należy spisać w formie wymagań niefunkcjonalnych.
Dzięki współpracy od samego początku, łatwiej jest opracować plan testów, przygotować środowiska pod testy i wykryć błędy na wczesnym etapie ich powstawania.
Wymagania które często się powtarzają lub muszą być zaimplementowane stale, należy spisać w formie wymagań niefunkcjonalnych.Kamil Naja
Według Jima Rohna, komunikacja jest jedną z najważniejszych kompetencji miękkich, które możesz posiadać i nad którymi możesz pracować. Staje się ona jeszcze ważniejsza, gdy w zespole pojawiają się nowe osoby, często zadające wiele pytań oraz mające jeszcze trudności w odnalezieniu się w nowych projektach. Dobra komunikacja pozwala oszczędzać czas.
Przykładowo, tester może otrzymać do testowania kilka zadań, których wcześniej nigdy nie widział i nie jest pewny, gdzie one mają być zaimplementowane. To samo może dotyczyć programisty, który otrzymał poprawki do wykonania.
Teraz, jeśli zespół się komunikuje w niewłaściwy sposób, na przykład rozmawia ze sobą jedynie na spotkaniach typu daily status, pewne jest że powstaną opóźnienia w projekcie, albo funkcjonalności zostaną sprawdzone / wykonane w niewłaściwym miejscu. Nie ma nic gorszego, niż rozpoczynanie pracy z poczuciem braku pewności, czy robimy coś tam, gdzie trzeba.
W moim odczuciu, symbolem takiej niewłaściwej komunikacji jest Jira - bez opisu, z dołączonym zrzutem ekranu wielkości znaczka pocztowego, który pokazuje jedynie jakiś bug.
O ile łatwiej pracuje się, jeśli osoba zgłaszająca utworzy zadanie, w którym znajdziesz:
Pisanie tych informacji za każdym razem w zgłoszeniu może wydawać się nużące, ale z perspektywy czasu, przynosi to wartość. Wyobraź sobie, że jako osoba zgłaszająca, chcesz wrócić do buga sprzed pół roku. Jeśli błędy są opisywane dokładnie, można znacznie łatwiej wywnioskować, co poszło nie tak nawet z perspektywy czasu. Można wtedy też łatwiej wywnioskować, dlaczego została podjęta taka, a nie inna decyzja składająca się na zmianę. Najlepiej jest, jeśli błąd w systemie zgłoszeń nie wymaga dodatkowych wyjaśnień, a jeśli się one pojawią, to są podawane od ręki.
Najlepszym sposobem komunikacji jest kontakt bezpośredni lub rozmowa wideo. Gdy podczas takiego spotkania ustalimy pewne rzeczy / podejmiemy decyzje, umieśćmy je w Jirze, by potem nam nie umknęły. Dobra komunikacja prowadzi do wzrostu zaufania w zespole, co przekłada się na wydajniejszą pracę.
Ważną kwestią jest przypisywanie zadań eliminacji bugów odpowiedniej osobie. W dużym projekcie każdy programista jest zainteresowany jedynie realizacją swoich zadań (pomijając bieżącą pomoc osobom z teamu). Utworzenie zadnia w Jirze bez przypisanej osoby sprawi, że nie zostanie ona zrealizowana (oczywiście do momentu, w którym zostanie komuś przypisana).
Jeszcze większe zamieszanie wprowadza sytuacja, gdy tester zgłasza błąd, który był już wcześniej zgłoszony przez kogoś innego. Dlatego, przed utworzeniem buga, warto zapytać, czy nie istnieje już podobne zgłoszenie.
Chcesz wiedzieć więcej?Pomożemy Ci odnieść sukces w roli niezależnego konsultanta IT.
W dobrym zespole powinniśmy wspólnie podejmować decyzje dotyczące działania aplikacji. To samo tyczy się rozwiązywania błędów w możliwie najlepszy sposób. Przykładowo, team front-endowy może borykać się z błędami powstającymi na back-endzie, jednak back-end jest tworzony przez jeszcze inny zespół. W takiej sytuacji tester napotykający się na przysłowiową Pięćsetkę w konsoli (błąd zwrócony z back-endu), powinien zrewidować, czy na pewno wysyłane są dobre dane do back-endu i, jeśli tak jest, powinien zgłosić błąd w odpowiedniej warstwie. Tester bez wiedzy technicznej albo z negatywnym podejściem, będzie zgłaszał każdy błąd dla zespołu GUI (no bo tam błąd zobaczył) bez zastanowienia, której warstwy on dotyczy. Z taką osobą współpracuje się bardzo trudno, pozostałym zespołom dodaje to też dodatkowej pracy.
Trzeba się zaem zastanowić co robić, by nie dokładać pracy innym członkom zespołu. Przykładowo, jeśli widać, że jakiś ekran zawierający formularz nie jest widoczny, bo np. nie pełnimy w organizacji określonej roli biznesowej, by go zobaczyć, to nie zgłaszajmy 20 błędów typu “brak pola A” i “brak pola B”. Wystarczy informacja że nie działa cały ekran.
Wiele pod tym względem można zarzucić także programistom. Czasem funkcjonalność może działać jedynie na pewnych środowiskach, a na innych już nie (słynne “u mnie działa”), co powinno zostać oczywiście sprawdzone przez odpowiednią osobę.
Dużym ułatwieniem dla zespołu są osoby, które radzą sobie samodzielnie z podstawowymi zadaniami technicznymi. Przykładowo, tester po informacji że kod jest gotowy do wgrania na środowisko, może zalogować się do Jenkinsa i samemu wgrać odpowiednią wersję na to środowisko, na którym jest mu ona potrzebna. Jest to o wiele prostsze niż sytuacja, gdy tester prosi programistę o jakąś akcję, która odciąga tego programistę od codziennych zadań. Dodatkowo, co w sytuacji, gdy żaden z programistów nie będzie aktualnie dostępny a tester nie potrafi zalogować się do podstawowych narzędzi CI by przygotować sobie pracę?
Programiści często przywiązują się do swojej pracy, uważają, że skoro poświęcili na jakieś rozwiązanie dużo czasu, to na pewno jest ono idealne. Niestety, ale w rzeczywistości rozwiązania stale się zmieniają, są ulepszane i dostosowywane do potrzeb klienta i nie należy brać do siebie tego, że tester zgłasza nam do nich uwagi. Bądźmy otwarci na feedback.
W wielu projektach kluczowym czynnikiem jest priorytetyzacja zadań. Z mojej perspektywy warto jest najpierw zająć się rozwiązaniem błędów, które powstały wcześniej, a następnie branie się za nowe funkcjonalności. Świadomość tego, co jest ważne musi mieć cały zespół.
Konieczne jest też wypracowanie w zespole wiedzy o tym, że niektóre błędy mają bardzo wysoki priorytet i gdy się pojawią, muszą być rozwiązane jak najszybciej.
Współpraca w projekcie nie powinna przeradzać się w rywalizację. Byłem świadkiem zachowań, kiedy tester zgłaszał codziennie kilkanaście zadań, z których treści wynikało, że nie zawsze rozumie działanie aplikacji. Następnie programiści odrzucali te zgłoszenia, ale wśród zadań odrzuconych były też wartościowe uwagi. Po jakimś czasie sytuacja została rozwiązana przez osoby zarządzające projektem.
Podsumowując:Efektywna współpraca między programistami i testerami jest łatwa do wypracowania, o ile każdy z członków zespołu ma w sobie chęć pomocy i nauki. Wypracowuje się ona też w sposób naturalny w zespołach, których członkowie pracują razem przez dłuższy czas.
Najbardziej wymagająca sytuacja jest wtedy, kiedy w zespole pojawiają się nowe osoby i napotykają 'obecny porządek rzeczy'. Warto zadbać, by podczas współpracy z nowym członkiem teamu:
Powyższe wytyczne warto wprowadzać też na bieżąco (w już znanym i zgranym teamie), aby realizacja zadań przebiegała szybciej i dawałą większą wartość klientowi końcowemu. Dobrym miejscem na rozmowę o usprawnieniach może być zespołowe retro. Warto przyjąć też założenie, że nic w projekcie nie jest oczywiste i zachęcać do zadawania pytań oraz do proszenia o wsparcie.
Przeczytaj także:
Wymagania niefunkcjonalne w procesie tworzenia aplikacji
Już jest! Zapis webinaru pt. Grafowa baza danych rewolucjonizuje zarządzanie informacjami… czyli o Neo4j z perspektywy front-endowca.
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.
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ć?
„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.
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?
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.
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.
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.
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?
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.
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.
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?
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ć.
Ł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.
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?
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.
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?
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.
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.
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.
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?
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.
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.
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.
Zdalna praca w innej strefie czasowej jest możliwa, gdy w zespole panuje odpowiednia dyscyplina.
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.