Test INF.03 — zestaw 8

Dlaczego tak

Kompetencje społeczne to m.in. komunikacja, współpraca, rozwiązywanie konfliktów i udzielanie informacji zwrotnej; rozwija się je najlepiej w ćwiczeniach z innymi ludźmi, np. na warsztatach. Kurs frameworka, certyfikat z MySQL i nauka języka programowania podnoszą kompetencje zawodowe techniczne. Są wartościowe, ale nie odpowiadają na wskazaną potrzebę.

Dlaczego tak

Skrzyżowane ręce i odchylenie ciała często oznaczają dystans lub rezerwę, a zerkanie na zegarek — zniecierpliwienie. Sygnały niewerbalne nie są jednoznaczne, dlatego zamiast mówić dalej, warto sprawdzić ich znaczenie pytaniem, np. o wątpliwości klienta, i skrócić omawianą część. Odczytanie ich jako zachwytu lub zrozumienia jest sprzeczne z typowym znaczeniem tych gestów.

Dlaczego tak

Parafraza („Czyli…”, „Jeśli dobrze rozumiem…”) to powtórzenie własnymi słowami tego, co powiedział rozmówca, by sprawdzić, czy dobrze go zrozumieliśmy — klient czuje się wysłuchany, a programista upewnia się co do objawów błędu. Pozostałe odpowiedzi przerywają słuchanie: oceniają, zaprzeczają problemowi albo narzucają obejście, zanim przyczyna zostanie ustalona.

Dlaczego tak

Prowadzący odpowiada za to, by w dyskusji wybrzmiały różne punkty widzenia i by mieściła się ona w czasie. Uprzejme podsumowanie wypowiedzi dominującej osoby i zaproszenie innych do głosu (np. kolejną rundą wypowiedzi) zachowuje szacunek i równowagę. Oddanie całego czasu jednej osobie lub decyzja bez dyskusji pomijają wiedzę reszty zespołu.

Dlaczego tak

Konstruktywna informacja zwrotna jest konkretna, opisuje zachowanie lub efekt, a nie osobę, wskazuje mocne strony i proponuje, co i dlaczego poprawić — tu zmianę nazw zmiennych z uzasadnieniem. Ogólna krytyka bez wskazówek zniechęca i nie uczy. Same pochwały mimo realnych problemów pozbawiają autora szansy na poprawę, a „ja bym to zrobił inaczej” nie mówi, co jest nie tak.

Dlaczego tak

Trwałe porozumienie daje podejście „wygrana–wygrana”: negocjator zna swoje minimum i potrzeby klienta, słucha, jest uczciwy i szuka rozwiązań korzystnych dla obu stron. Ustępowanie we wszystkim prowadzi do nierentownego projektu i frustracji wykonawcy, a twarda postawa bez ustępstw — do zerwania rozmów. Ukrywanie ograniczeń wychodzi na jaw przy realizacji i niszczy zaufanie.

Dlaczego tak

Negocjacje zaczyna się od przygotowania: ustalenia celów, granic ustępstw i najlepszej alternatywy. Następnie strony poznają swoje stanowiska i potrzeby, wymieniają propozycje i ustępstwa, a na końcu spisują ustalenia, aby uniknąć późniejszych sporów o to, co uzgodniono. Spisywanie porozumienia przed wymianą propozycji nie ma sensu, bo nie byłoby jeszcze czego zapisać.

Dlaczego tak

System kontroli wersji przechowuje historię zmian, pozwala każdemu pracować na osobnej gałęzi i łączy zmiany, sygnalizując konflikty do świadomego rozwiązania, zamiast cicho nadpisywać pracę innych. Przegląd kodu przed scaleniem dodatkowo wyłapuje błędy. Wysyłanie plików mailem i kopie z datą w nazwie mnożą wersje bez kontroli, a praca po kolei czterokrotnie wydłuża projekt.

Dlaczego tak

Metoda 5 Why polega na wielokrotnym pytaniu „dlaczego?” o kolejne przyczyny, aż do przyczyny źródłowej — tu braku rotacji logów, którą usuwa się konfiguracją, np. logrotate. Usunięcie samego objawu, czyli zwolnienie miejsca, nie zapobiegłoby powtórce. Burza mózgów służy do zbierania wielu pomysłów naraz, SWOT do analizy sytuacji, a diagram Gantta do planowania harmonogramu.

Dlaczego tak

Każdy test dzieli zbiór podejrzanych commitów na pół: 64 → 32 → 16 → 8 → 4 → 2 → 1, czyli wystarczy 6 testów, bo 2^6 = 64. Odpowiedź 64 odpowiada sprawdzaniu commitów po kolei, a 32 — pomyleniu liczby testów z liczbą commitów, które zostają do sprawdzenia po pierwszym teście. Metoda połowienia jest tym korzystniejsza, im dłuższa jest historia.

Dlaczego tak

Za wynik zespołu odpowiadają wszyscy jego członkowie: wobec klienta zespół występuje jako całość, a wewnątrz wspólnie szuka przyczyny (np. niedoszacowania lub braku informacji o trudnościach) i dzieli się pracą, aby dokończyć moduł. Obwinianie jednej osoby przed klientem podważa zaufanie do całej firmy, a stwierdzenie „moja część była gotowa” ignoruje zależność zadań.

Dlaczego tak

W Scrumie Product Owner odpowiada za wartość produktu, dlatego zarządza Product Backlogiem i ustala kolejność jego elementów, uwzględniając potrzeby klienta. Scrum Master dba o przestrzeganie zasad Scruma i usuwa przeszkody, ale nie ustala priorytetów. Programiści decydują, jak wykonać pracę wybraną do sprintu, a nie o kolejności całego rejestru.

Dlaczego tak

Zaangażowanie oznacza aktywny udział: dzielenie się obserwacjami, zgłaszanie propozycji i branie odpowiedzialności za ich wprowadzenie, bo retrospektywa ma kończyć się konkretnymi działaniami. Milczenie i praca nad własnym zadaniem odbierają zespołowi czyjąś perspektywę. Krytyka bez propozycji nie prowadzi do usprawnień, a często zniechęca innych do mówienia.

Dlaczego tak

Decyzja wypracowana wspólnie obowiązuje wszystkich, także tych, którzy mieli inne zdanie — jednolity styl ułatwia czytanie kodu i przeglądy zmian. Własne argumenty można zgłosić na retrospektywie, a zespół może zmienić ustalenie. Formatowanie po swojemu, nawet tylko we własnych plikach, wprowadza niespójność, a przeformatowanie całego projektu zaśmieca historię zmian.

Dlaczego tak

W strukturze zespołu projektowego kierownik projektu odpowiada za planowanie, podział pracy, monitorowanie postępu i komunikację z klientem — pozostali członkowie odpowiadają za swoje specjalizacje. Tester rzeczywiście zna całą aplikację, ale jego rolą jest weryfikacja jakości, a nie zarządzanie. Projektant UX bada potrzeby użytkowników, lecz nie przydziela zadań zespołowi.

Dlaczego tak

Kryterium akceptacji opisuje obserwowalny wynik, który da się jednoznacznie sprawdzić testem: albo potwierdzenie się wyświetla i wiadomość dociera, albo nie. Określenia „ładnie”, „nowocześnie” czy „możliwie dobrze” każdy rozumie inaczej, więc nie pozwalają rozstrzygnąć, czy zadanie zostało wykonane. Tempo pracy programisty w ogóle nie opisuje wyniku zadania.

Dlaczego tak

Ciężkie urządzenia przenosi się zespołowo lub sprzętem pomocniczym, aby ograniczyć ryzyko urazów kręgosłupa, a najcięższe elementy montuje się w dolnej części szafy — obniża to środek ciężkości i ryzyko przewrócenia szafy. Montaż wysoko wymaga podnoszenia ciężaru nad poziom barków. Praca przy włączonym zasilaniu zwiększa ryzyko porażenia i zwarcia.

Dlaczego tak

Podstawiając do wzoru: (2 + 4 · 4 + 12) / 6 = (2 + 16 + 12) / 6 = 30 / 6 = 5 dni. Wynik 6 dni to zwykła średnia trzech oszacowań (18 / 3), która przecenia wpływ wartości skrajnych. Wynik 4 to samo oszacowanie najbardziej prawdopodobne — metoda PERT koryguje je o ryzyko, dlatego oczekiwany czas jest dłuższy.

Dlaczego tak

Skuteczna komunikacja w zespole jest konkretna i kierowana do właściwych osób: co blokuje pracę, kto może pomóc i jaki jest termin, a kanał projektu pozostawia ślad widoczny dla kierownika. Czekanie do cotygodniowego spotkania marnuje kilka dni pracy. Ogólna skarga do całej firmy nie wskazuje adresata ani konkretnej potrzeby.

Dlaczego tak

Prawidłowa współpraca przy przeglądzie kodu polega na rzeczowej, konkretnej uwadze skierowanej do autora — w miejscu, gdzie zespół ją widzi — z propozycją rozwiązania; autor poprawia kod i przy okazji się uczy. Przepisanie kodu po cichu odbiera mu tę możliwość i wprowadza zmiany bez jego wiedzy. Zatwierdzenie zmian z błędem przenosi go do produkcji, a angażowanie kierownika w zwykłą uwagę techniczną psuje zaufanie w zespole.

Dlaczego tak

Najdłuższy ciąg zależnych zadań (ścieżka krytyczna) to A → B → D: 2 + 3 + 3 = 8 dni. Makietę C można przydzielić innej osobie i wykonać równolegle z A i B, więc gotowa będzie przed startem D i nie wydłuży projektu. Wynik 10 dni to suma wszystkich zadań wykonywanych po kolei przez jedną osobę.

Dlaczego tak

O przydatności do zadania decydują kompetencje związane z jego treścią: optymalizacja zapytań wymaga znajomości SQL, indeksów i analizy planu zapytania (EXPLAIN), czyli doświadczenia Bartka. Staż Anny dotyczy innej części aplikacji. Celina może pomóc zmierzyć efekt, a stażysta może uczestniczyć w zadaniu, ale nie powinien prowadzić go samodzielnie.

Dlaczego tak

Migracja bazy wymaga wiedzy administratorki baz (Ewa), animacje interfejsu realizuje się w CSS i JavaScript (Filip), a testy dostępności prowadzi osoba znająca wytyczne WCAG (Gosia). W pierwszym wariancie tylko Gosia ma właściwe zadanie, a Filip dostaje migrację bazy, której nie zna. Pozostałe podziały również przypisują co najmniej dwa zadania osobom bez potrzebnych kompetencji.

Dlaczego tak

W kolejności A, C, B, D każde zadanie zaczyna się po swoich poprzednikach: B po A, a D po B i C. Wariant B, A, C, D zaczyna od B, zanim wykonano A, a wariant A, D, C, B wykonuje D przed B i C. Kolejność D, C, B, A jest dokładnie odwrócona. Zadanie C, jako niezależne, mogłoby stać w dowolnym miejscu przed D.

Dlaczego tak

Dobra zasada określa, kiedy i jak prosić o pomoc: próg czasu chroni przed wielogodzinnym utknięciem, a jednocześnie zachęca do samodzielnej próby, zaś kanał projektu sprawia, że pomóc może ktokolwiek wolny. Samotne rozwiązywanie problemów bez limitu czasu marnuje dni pracy. Kierownik nie zawsze ma wiedzę techniczną, a pomoc dopiero po własnych zadaniach przychodzi zwykle za późno.

Dlaczego tak

Koordynator dba, by prace prowadzone równocześnie nie stwarzały wzajemnych zagrożeń: wymiana zasilacza wymaga odłączenia zasilania, a otwarta podłoga techniczna — oznakowania i wygrodzenia, bo grozi wpadnięciem lub potknięciem. Pozostawianie otwartych płyt i przewodów luzem w przejściu tworzy ryzyko upadku. Pośpiech zwiększa liczbę błędów i wypadków.

Dlaczego tak

Prawidłowa dyspozycja wskazuje wykonawcę, zakres pracy, odniesienie (makietę v2) i termin, dzięki czemu nie ma wątpliwości, kto, co i do kiedy ma zrobić, a wynik można sprawdzić. „Jak będziesz mieć chwilę” nie ustala ani zakresu, ani terminu. Polecenie skierowane do „kogoś” nie ma adresata, więc zwykle nikt go nie wykonuje.

Dlaczego tak

Linia idealna wykresu spalania zakłada równomierne tempo: po połowie sprintu powinno zostać około 50% pracy. Pozostałe 80% oznacza, że wykonano tylko 20% — w dotychczasowym tempie do końca sprintu zespół zrobi ok. 40%. Trzeba ustalić przyczynę (przeszkody, złe oszacowania) i ewentualnie zmniejszyć zakres. Mylące bywa to, że wysoki słupek „zostało” wygląda jak dużo wykonanej pracy.

Dlaczego tak

W SemVer numer ma postać MAJOR.MINOR.PATCH: nowa funkcja zgodna wstecz zwiększa MINOR i zeruje PATCH, więc 2.3.5 → 2.4.0. Wersja 3.0.0 oznaczałaby zmiany niezgodne wstecz, a 2.3.6 — same poprawki błędów. Zapis 2.4.5 jest błędny, bo po zwiększeniu MINOR licznik poprawek zaczyna się od zera.

Dlaczego tak

Kontrola efektów pracy polega na porównaniu wyniku z ustalonymi kryteriami ukończenia (Definition of Done). Kryterium mówi o wszystkich testach, więc 2 nieprzechodzące testy oznaczają, że zadanie nie jest ukończone, niezależnie od wysokiego odsetka. „Ukończenie warunkowe” i ocena autora rozmywają wspólny standard i przenoszą błędy dalej.

Dlaczego tak

Odbiór wymaga spełnienia wszystkich warunków technicznych, więc każde kryterium sprawdza się osobno. Czas 2,1 s jest poniżej 3 s, a poziom AA został osiągnięty, ale 3 błędy walidatora naruszają trzeci warunek — praca wraca do poprawy w tym zakresie. Dobry wynik w jednym kryterium nie rekompensuje niespełnienia innego, a czas ładowania nie wymaga żadnej poprawy.

Dlaczego tak

Doklejanie danych z formularza do treści zapytania umożliwia atak SQL injection — spreparowany tekst zmienia sens zapytania. Zapytania przygotowane (np. PDO::prepare i execute z parametrami) przesyłają dane oddzielnie od kodu SQL, więc nie mogą go zmienić. Komentarze, przeniesienie kodu do innego pliku czy skracanie zapytań nie usuwają podatności.

Dlaczego tak

Automatyzacja oszczędza 2 h dziennie, więc 16 h nakładu zwraca się po 16 h : 2 h = 8 dniach roboczych, a później daje czysty zysk czasu i mniej błędów ręcznego wgrywania plików. Wynik 16 dni wynikałby z przyjęcia oszczędności 1 h dziennie. Liczba osób w zespole nie wpływa na wynik, bo 2 godziny to już łączna strata całego zespołu.

Dlaczego tak

Ból karku wynika z pochylania głowy nad nisko położonym ekranem; ergonomiczne stanowisko wymaga, aby górna krawędź ekranu znajdowała się na wysokości oczu lub nieco poniżej. Podstawka z osobną klawiaturą albo zewnętrzny monitor usuwa przyczynę. Większa czcionka poprawia czytelność, ale nie podnosi ekranu, a ustawienie biurek przodem do okna powoduje olśnienie.