Test INF.04 — zestaw 8

Dlaczego tak

Prowadzący dyskusję dba o to, by wszyscy mogli się wypowiedzieć: zaprasza osoby milczące, np. pytając je wprost o zdanie, i ogranicza czas wypowiedzi, aby jedna osoba nie zdominowała rozmowy. Milczenie nie oznacza braku wiedzy ani zgody. Samodzielna decyzja pomija wiedzę zespołu, a zakazanie komuś wypowiedzi jest równie niewłaściwe jak dopuszczenie do dominacji.

Dlaczego tak

Konstruktywna informacja zwrotna wskazuje mocne strony i konkretny problem wraz ze sposobem poprawy – stażysta wie, co zrobił dobrze, czego brakuje i jak to uzupełnić. Ogólna pochwała nie pomaga się rozwijać i pomija istniejący błąd. Ocena „kod jest słaby” dotyczy osoby, a nie zachowania, a polecenie „popraw wszystko” nie mówi, co jest do poprawienia.

Dlaczego tak

Postawa rzeczowa skupia się na interesach obu stron, a nie na stanowiskach: poznanie przyczyny prośby (np. ograniczony budżet) pozwala znaleźć rozwiązanie korzystne dla obu – niższą cenę za mniejszy zakres. Natychmiastowa zgoda to postawa miękka, w której jedna strona traci, a groźby to postawa twarda, która niszczy relację. Ciche obniżenie jakości jest nieuczciwe wobec klienta.

Dlaczego tak

BATNA (Best Alternative to a Negotiated Agreement) to najlepsza alternatywa na wypadek braku porozumienia – ustala się ją na etapie przygotowania, bo wyznacza granicę, poniżej której nie warto się zgadzać. ZOPA to obszar, w którym oczekiwania stron się pokrywają i porozumienie jest możliwe. Kotwica to pierwsza propozycja wpływająca na dalsze oferty, a ustępstwo to rezygnacja z części żądań w trakcie rozmów.

Dlaczego tak

Problemom zespołu zapobiega się, usuwając ich przyczynę: wspólne zasady pracy z gałęziami, widoczny przydział zadań i częste scalanie małych zmian zmniejszają szansę, że dwie osoby długo zmieniają ten sam fragment. Scalanie raz w miesiącu przez jedną osobę gromadzi konflikty zamiast im zapobiegać. Praca wszystkich w gałęzi głównej nie usuwa konfliktów, a wymuszone wypychanie niszczy pracę kolegów.

Dlaczego tak

W technice 5 Why zespół kolejno pyta „dlaczego?” o każdą przyczynę, aż dojdzie do przyczyny źródłowej – tu jest nią brak konfiguracji rotacji dzienników, którą można trwale usunąć. Burza mózgów służy do zbierania wielu pomysłów bez oceniania, a nie do śledzenia łańcucha przyczyn. Analiza SWOT ocenia mocne i słabe strony oraz szanse i zagrożenia, a metoda delficka zbiera prognozy ekspertów w kilku rundach.

Dlaczego tak

W pierwszej fazie burzy mózgów uczestnicy zgłaszają jak najwięcej pomysłów, także nietypowych, a krytyka jest zabroniona, bo hamuje kreatywność. Ocena i selekcja pomysłów odbywa się dopiero w drugiej fazie. Ograniczenie wypowiedzi do kierownika i odrzucanie pomysłów trudnych do szybkiego wdrożenia przekreśla sens tej metody.

Dlaczego tak

Wspólna odpowiedzialność oznacza, że zespół dba o wynik całości, a nie tylko o własny fragment – programiści mogą wykonać testy według przygotowanych scenariuszy i w ten sposób zabezpieczyć wydanie. Ograniczenie się do własnych zadań i przerzucenie winy na nieobecnego kolegę zostawia problem nierozwiązany. Samo zgłoszenie problemu bez propozycji pomocy jest bierne.

Dlaczego tak

W Scrumie za zawartość i kolejność backlogu produktu odpowiada Product Owner, dlatego prośbę klienta należy do niego przekazać, zamiast samemu zmieniać priorytety. Scrum Master dba o przestrzeganie zasad Scruma i usuwa przeszkody, ale nie ustala priorytetów. Developers decydują, jak wykonać pracę i ile zadań zmieści się w sprincie, a nie o kolejności backlogu.

Dlaczego tak

Zaangażowanie w pracę zespołu oznacza troskę o wspólny cel sprintu, a nie tylko o własne zadanie – pomoc przy przeglądzie kodu lub przejęcie kolejnego zadania z tablicy przybliża zespół do celu. Bierne czekanie na polecenia marnuje czas zespołu. Praca nad własnym projektem i niedostępność oznaczają wycofanie się ze wspólnych działań.

Dlaczego tak

Ustalenie wypracowane wspólnie obowiązuje wszystkich, także tych, którzy wcześniej mieli inne zdanie – jednolita konwencja ułatwia czytanie kodu i przeglądy. Pozostanie przy własnym stylu podważa decyzję zespołu i wprowadza niespójność. Zmiana kodu kolegów bez zgody i mieszanie konwencji pogarszają jakość kodu bardziej niż którakolwiek z konwencji.

Dlaczego tak

Według Scrum Guide zespół Scrum tworzą trzy role: Product Owner, Scrum Master i Developers, przy czym Developers to wszystkie osoby, które wykonują pracę nad przyrostem produktu – niezależnie od specjalizacji. Tester i projektant UX też tworzą przyrost, więc należą do Developers. Product Owner i Scrum Master to odrębne role z innymi odpowiedzialnościami, a zawężenie Developers do programistów to częsta pomyłka.

Dlaczego tak

Historyjka użytkownika opisuje potrzebę z perspektywy odbiorcy według wzorca „Jako <rola> chcę <funkcja>, aby <korzyść>”, dzięki czemu zespół wie, dla kogo i po co tworzy funkcję. Polecenie dodania indeksu to zadanie techniczne, które może wynikać z historyjki, ale nią nie jest. Wymaganie „ma działać szybko” jest nieokreślone, a ostatni zapis to przydział pracy, a nie potrzeba użytkownika.

Dlaczego tak

Przewody leżące w przejściach grożą potknięciem i uszkodzeniem izolacji, dlatego prowadzi się je w kanałach kablowych. Monitor ustawiony tyłem do okna zmusza do patrzenia pod światło, co męczy wzrok – zalecane jest ustawienie bokiem do okna. Kaskadowo łączone przedłużacze grożą przeciążeniem i pożarem, a krzesło bez regulacji nie pozwala dostosować stanowiska do wzrostu pracownika.

Dlaczego tak

Średnia prędkość zespołu (velocity) wynosi (28 + 32 + 30) / 3 = 30 punktów na sprint, więc 150 punktów zajmie 150 / 30 = 5 sprintów. Sprint trwa dwa tygodnie, zatem wydanie potrwa 10 tygodni. Wynik 6 sprintów powstaje po przyjęciu najsłabszego sprintu (150 / 28 ≈ 5,4), a 5 tygodni – po pominięciu długości sprintu.

Dlaczego tak

Ważną informację dla całego zespołu przekazuje się kanałem, do którego wszyscy mają dostęp i który zostawia ślad – np. na kanale zespołu – oraz aktualizuje się ją w narzędziu do zarządzania projektem, gdzie każdy sprawdzi ją później. Przekazanie ustne przez pośrednika grozi zniekształceniem lub pominięciem kogoś. Rozmowy telefoniczne bez zapisu i karteczka na własnym monitorze nie są trwałe ani dostępne dla zespołu.

Dlaczego tak

Przegląd kodu przez drugą osobę wychwytuje błędy i rozpowszechnia wiedzę w zespole, a wspólna Definition of Done sprawia, że wszyscy tak samo rozumieją „zadanie ukończone”. Scalanie bez przeglądu przyspiesza pracę tylko pozornie, bo błędy wychodzą później. Ukrywanie problemów opóźnia pomoc, a komunikacja wyłącznie przez kierownika spowalnia współpracę i tworzy wąskie gardło.

Dlaczego tak

Zadania B i C zależą tylko od A, więc po jego zakończeniu mogą być wykonywane równolegle przez dwie osoby; D zaczyna się po dłuższym z nich. Czas projektu to 3 + max(2, 4) + 1 = 8 dni. Wykonanie B i C kolejno przez jedną osobę daje 3 + 2 + 4 + 1 = 10 dni, a B nie może biec równolegle z A, bo od niego zależy.

Dlaczego tak

Optymalizacja zapytań wymaga znajomości indeksów i umiejętności czytania planu wykonania zapytania – Anna ma dokładnie te kompetencje i doświadczenie w MySQL. Bartek, Celina i Darek mają podobny staż, ale w innych obszarach: frontend, testy manualne i projektowanie interfejsu. Przy doborze osoby do zadania liczy się dopasowanie kompetencji do zadania, a nie sam staż pracy.

Dlaczego tak

Każda osoba najszybciej wykonuje inne zadanie: Anna X (4 h), Bartek Y (3 h), Celina Z (4 h), więc taki przydział daje 4 + 3 + 4 = 11 h i jest najlepszy ze wszystkich sześciu możliwych. Pozostałe przydziały kosztują 15 h, 18 h i 17 h, bo co najmniej jedna osoba wykonuje zadanie, w którym jest wolniejsza. Rozdzielanie zadań według kompetencji skraca więc łączny czas pracy zespołu.

Dlaczego tak

Model bazy danych nie zależy od innych zadań, więc idzie pierwszy; potem API, które go wymaga, następnie widok korzystający z API, a dopiero na końcu testy end-to-end, które potrzebują obu. Dokumentację można wykonać w dowolnym momencie. W pozostałych kolejnościach API powstaje przed modelem, widok przed API albo testy przed widokiem, co łamie zależności.

Dlaczego tak

Dobra zasada wzajemnej pomocy jest konkretna: mówi, kiedy prosić o pomoc (po 2 h bezskutecznych prób), gdzie (kanał zespołu) i kto oraz w jakim czasie odpowie. Ogólne „pomagamy, kiedy się da” brzmi dobrze, ale nie daje żadnej wskazówki w praktyce. Wymóg pisemnej zgody zniechęca do proszenia o pomoc, a zakaz odrywania innych prowadzi do wielogodzinnego blokowania pracy.

Dlaczego tak

Koordynacja zadań BHP polega na przydzieleniu i dopilnowaniu działań zapobiegawczych: urządzenia odłącza się od zasilania przed demontażem (ryzyko porażenia i uszkodzenia sprzętu), a ciężkie serwery przenosi się zespołowo lub sprzętem pomocniczym, by nie przekraczać norm dźwigania. Przenoszenie włączonych komputerów grozi uszkodzeniem i porażeniem. Samodzielne dźwiganie serwerów i kable w korytarzu to ryzyko urazów.

Dlaczego tak

Jednoznaczna dyspozycja określa wykonawcę, zakres pracy, termin i sposób przekazania wyniku – tu: walidacja e-maila, czwartek 12:00 i pull request do przeglądu przez Olę. Polecenie „zajmij się jakoś, kiedy znajdziesz chwilę” nie określa ani zakresu, ani terminu. Dyspozycja do „kogoś” nie ma wykonawcy, a „ma działać lepiej” nie mówi, co jest celem.

Dlaczego tak

Limit WIP (work in progress) ogranicza liczbę zadań w danym etapie i sygnalizuje wąskie gardło – pełna kolumna testów oznacza, że praca utknęła właśnie tam. Zasada Kanban „przestań zaczynać, zacznij kończyć” każe pomóc w testach lub przeglądzie zamiast dokładać pracy. Przekroczenie lub usunięcie limitu ukrywa problem, a rozpoczynanie nowych zadań zwiększa liczbę niedokończonych prac.

Dlaczego tak

Conventional Commits wymaga formatu „typ(zakres): opis”, gdzie typ feat oznacza nową funkcję, fix – poprawkę błędu, a zakres w nawiasie wskazuje moduł. Opis z typem fix jest poprawny formalnie, ale błędnie klasyfikuje zmianę, co psuje np. automatyczne numerowanie wersji i listy zmian. Pozostałe zapisy nie zawierają wymaganego typu na początku wiersza.

Dlaczego tak

Definition of Done to lista warunków, które muszą być spełnione wszystkie, aby uznać zadanie za ukończone – pokrycie 74 % nie spełnia progu 80 %, więc zadanie wraca do realizacji. Przechodzące testy to tylko jeden z warunków. Spełnienie większości kryteriów nie wystarcza, a o ukończeniu nie decyduje subiektywne zdanie autora, lecz kontrola zgodności z ustaloną definicją.

Dlaczego tak

Praca jest zgodna z warunkami odbioru tylko wtedy, gdy spełnia każde z kryteriów. Ania mieści się we wszystkich trzech. Bartek ma dobry czas ładowania, ale wynik dostępności 88 jest poniżej wymaganych 90, a Celina ma bardzo dobrą dostępność, ale czas 3,4 s przekracza limit 3 s – oba wyniki trzeba poprawić przed odbiorem.

Dlaczego tak

Hasło, które trafiło do repozytorium, trzeba uznać za ujawnione: należy je zmienić, usunąć plik z historii, a przez .gitignore zapobiec ponownemu dodaniu; .env.example opisuje potrzebne zmienne bez wartości. Zmiana nazwy pliku nic nie zmienia, bo plik nadal jest w repozytorium. Repozytorium prywatne widzą wszyscy jego członkowie, a Base64 to kodowanie, które każdy odwróci jednym poleceniem.

Dlaczego tak

Każde wdrożenie skraca się o 2 h − 0,5 h = 1,5 h, a przy 4 wdrożeniach tygodniowo oszczędność wynosi 6 h na tydzień. Nakład 18 h zwróci się po 18 / 6 = 3 tygodniach, a potem zespół zyskuje 6 h tygodniowo. Wynik 2,25 tygodnia powstaje, gdy pominie się 30 min, które wdrożenie nadal trwa, a 12 tygodni – gdy liczy się oszczędność tylko z jednego wdrożenia.

Dlaczego tak

Ból karku często wynika ze złej wysokości ekranu – regulowane ramię pozwala ustawić górną krawędź monitora na wysokości oczu, zgodnie z zasadami ergonomii. Automatyczny formater, np. Prettier uruchamiany przed commitem, usuwa różnice w formatowaniu bez udziału ludzi. Obniżenie monitora i praca z laptopem na kolanach pogłębiają problem z karkiem, a ręczne poprawianie i dłuższe przeglądy zwiększają koszt zamiast go usuwać.