Test INF.04 — zestaw 16

Dlaczego tak

Zaangażowanie przejawia się w przyjęciu konkretnego zadania na rzecz zespołu, a autor danej części API najlepiej i najszybciej ją opisze. Przyznanie racji bez działania nie zmienia sytuacji. Przerzucenie pracy na nowe osoby jest nieefektywne, bo to one najmniej znają kod, a odrzucenie dokumentacji ignoruje problem wskazany przez zespół.

Dlaczego tak

Uzgodnione stanowisko zespołu obowiązuje także osoby, które proponowały inne rozwiązanie, a własne zastrzeżenia zgłasza się w ustalonym miejscu, np. na retrospektywie, popierając je konkretnymi przykładami. Używanie innej biblioteki we własnych modułach rozbija spójność projektu. Ciągłe wypominanie racji psuje atmosferę, a wycofanie się z uwag pozbawia zespół informacji zwrotnej.

Dlaczego tak

Gdy produkt wymaga więcej osób, dzieli się je na kilka spójnych zespołów Scrum, które pracują nad tym samym produktem: mają wspólny cel produktu, jeden backlog produktu i jednego Product Ownera. Osobne backlogi i osobni Product Ownerzy dla jednego produktu prowadzą do sprzecznych priorytetów. Zespół 18-osobowy jest zbyt duży do sprawnej komunikacji, a jednoosobowe „zespoły” nie są zespołami.

Dlaczego tak

Przygotowanie historyjki do realizacji polega na rozbiciu jej na małe, konkretne zadania techniczne, które razem dostarczają opisaną funkcję – tu: pobranie adresu e-mail, wysłanie jednorazowego linku z tokenem, ustawienie nowego hasła i testy. Jedno ogromne zadanie „cały moduł kont” jest zbyt duże, by je szacować i śledzić. Pozostałe zestawy dotyczą innych funkcji, niezwiązanych z resetem hasła.

Dlaczego tak

Rozporządzenie w sprawie BHP na stanowiskach wyposażonych w monitory ekranowe wymaga przerwy co najmniej 5-minutowej po każdej godzinie pracy przy monitorze, wliczanej do czasu pracy; można ją też zastąpić zmianą rodzaju pracy. Przerwa 15-minutowa po co najmniej 6 godzinach pracy wynika z Kodeksu pracy i dotyczy wszystkich pracowników, dlatego bywa mylona z tą regułą. Przerwy na odpoczynek oczu nie mogą być odejmowane od czasu pracy.

Dlaczego tak

Bez urlopów pojemność wynosi 4 osoby · 10 dni · 6 h = 240 h, a dwa dni urlopu jednej osoby odejmują 2 · 6 h = 12 h, co daje 228 h. Wynik 240 h pomija urlop, a 304 h powstaje przy liczeniu pełnych 8 godzin dziennie (320 h − 16 h), czyli bez czasu na spotkania i inne obowiązki. Wartość 216 h to odjęcie urlopu dwukrotnie.

Dlaczego tak

Wybór kanału komunikacji zależy od pilności: awaria produkcji wymaga natychmiastowej reakcji, więc informację przekazuje się synchronicznie, ustalonym kanałem alarmowym lub telefonicznie do osób dyżurnych. E-mail następnego dnia i protokół spotkania to kanały asynchroniczne, odpowiednie dla spraw niepilnych. Komentarz w zgłoszeniu dokumentuje sprawę, ale sam nikogo nie zaalarmuje na czas.

Dlaczego tak

Praca w gałęziach i żądania scalenia (pull requesty) pozwalają pracować równolegle, a przegląd kodu przez innego członka zespołu wychwytuje błędy i rozpowszechnia wiedzę o projekcie przed włączeniem zmian do main. Bezpośrednie wypychanie do main bez przeglądu grozi zepsuciem wspólnego kodu. Rzadkie ręczne scalanie i wysyłanie kopii pocztą prowadzi do licznych konfliktów i utraty historii zmian.

Dlaczego tak

Ścieżka A–B–D–E trwa 2 + 3 + 2 + 1 = 8 dni i jest ścieżką krytyczną, a ścieżka A–C–E trwa 2 + 4 + 1 = 7 dni. Zadanie E może się zacząć dopiero po zakończeniu D, czyli po 7. dniu, a C kończy się najwcześniej po 6. dniu, więc ma 1 dzień zapasu. Wynik 0 oznaczałby, że C leży na ścieżce krytycznej, a 2 lub 3 dni powstają przy błędnym dodawaniu czasów zadań.

Dlaczego tak

Przydatność do zadania ocenia się, porównując jego wymagania z doświadczeniem kandydatów: Darek zna zarówno narzędzie (Selenium WebDriver), jak i wymagany język (Java). Ania zna interfejs aplikacji od strony projektowej, co bywa kuszące przy testach interfejsu, ale nie programuje testów automatycznych. Bartek ma kompetencje administracyjne, a Celina programuje w innym języku i dla innej platformy.

Dlaczego tak

Najmniej elastyczna jest osoba z jedną umiejętnością, więc od niej zaczyna się przydział: Piotr zna tylko SQL, zatem dostaje bazę danych. Kasii pozostaje wtedy Node.js, czyli API, a Oli – frontend w React. Przydział z Piotrem przy API lub frontendzie wymaga technologii, których nie zna, a Kasia nie zna Reacta, więc nie może dostać frontendu.

Dlaczego tak

W metodzie MoSCoW najpierw realizuje się wymagania Must (niezbędne), potem Should (ważne), następnie Could (pożądane, jeśli starczy czasu), a Won't oznacza świadomą rezygnację w tym wydaniu. Daje to kolejność: logowanie, powiadomienia, eksport, bez trybu ciemnego. Odwrócona kolejność czyta skrót od końca, a umieszczenie trybu ciemnego „na końcu wydania” myli Won't z najniższym priorytetem do zrealizowania.

Dlaczego tak

Zasada wzajemnej pomocy działa tylko wtedy, gdy członkowie zespołu nie boją się z niej korzystać, dlatego lider przypomina ją i pokazuje, że prośba o pomoc jest oczekiwanym zachowaniem, a nie słabością. Dobranie osoby do wspólnego poszukiwania błędu rozwiązuje problem i uczy stażystę. Krytyka przy wszystkich zniechęca do proszenia o pomoc, a odebranie zadania bez rozmowy niczego go nie uczy.

Dlaczego tak

Przewody luzem w przejściach grożą potknięciem i uszkodzeniem izolacji, dlatego lider koordynujący prace dba o ich ułożenie w korytach kablowych i o wolne drogi komunikacyjne. Przewody pod wykładziną w miejscach chodzenia są narażone na zgniatanie, przegrzanie i uszkodzenia niewidoczne z zewnątrz. Łączenie listew zasilających szeregowo grozi przeciążeniem obwodu i pożarem.

Dlaczego tak

Jednoznaczna dyspozycja określa, co dokładnie zrobić (np. numer zgłoszenia lub opis objawu błędu), do kiedy i po czym poznać, że zadanie jest wykonane. Bez tego Bartek może poprawić niewłaściwy błąd albo nie wiedzieć, jak pilna jest sprawa. Uzasadnienie wyboru wykonawcy, historia pracy autora formularza i lista innych formularzy nie pomagają w wykonaniu tej konkretnej poprawki.

Dlaczego tak

Czas cyklu liczy się od rozpoczęcia pracy nad zadaniem do jego ukończenia: od poniedziałku 9:00 do czwartku 9:00 mijają 3 dni. Czas realizacji obejmuje cały okres od zgłoszenia, czyli od piątku 9:00 do czwartku 9:00, co daje 6 dni kalendarzowych. Zamiana tych wartości myli oba wskaźniki, a wynik 4 i 7 dni powstaje przy liczeniu dni włącznie z pierwszym i ostatnim.

Dlaczego tak

W wersjonowaniu semantycznym MAJOR.MINOR.PATCH nowa funkcja zgodna wstecz zwiększa numer MINOR i zeruje PATCH, więc z 2.4.1 powstaje 2.5.0. Numer PATCH (2.4.2) zwiększa się tylko przy poprawkach błędów, a MAJOR (3.0.0) – przy zmianach niezgodnych wstecz. Zapis 2.5.1 nie zeruje numeru poprawki, co jest sprzeczne ze specyfikacją SemVer.

Dlaczego tak

Oba warunki muszą być spełnione jednocześnie: co najmniej dwa zatwierdzenia i udane testy CI, co dotyczy #43 i #44. Trzy zatwierdzenia w #44 przekraczają minimum, więc nie wykluczają scalenia – odpowiedź „tylko #43” błędnie traktuje „co najmniej 2” jako „dokładnie 2”. #41 ma nieudane testy, a #42 tylko jedno zatwierdzenie, dlatego oba wymagają jeszcze pracy.

Dlaczego tak

Udział szybkich odpowiedzi wynosi 18 / 20 = 90 %, a warunek wymaga co najmniej 95 %, czyli co najwyżej jednego wolniejszego żądania na 20. Średnia czasów nie jest miarą z warunku i może ukrywać pojedyncze bardzo wolne odpowiedzi, a „zdecydowana większość” to nie 95 %. Warunek nie wymaga też, by wszystkie żądania mieściły się w 300 ms – jedno wolniejsze byłoby dopuszczalne.

Dlaczego tak

Metoda wykonująca cztery różne czynności narusza zasadę pojedynczej odpowiedzialności: jest trudna do zrozumienia, testowania i modyfikacji. Podział na metody, np. WczytajPlik, Waliduj, ObliczRabaty i Zapisz, pozwala testować i zmieniać każdy krok osobno. Komentarz tylko opisuje problem, przeniesienie do innego pliku go nie usuwa, a skracanie nazw pogarsza czytelność.

Dlaczego tak

Każde spotkanie skraca się o 30 minut dla każdej z 6 osób, czyli o 180 minut pracy zespołu dziennie; w ciągu 5 dni daje to 900 minut, czyli 15 godzin. Wynik 2,5 h pomija liczbę uczestników (30 min · 5 dni), a 3 h to oszczędność tylko z jednego dnia. Wartość 22,5 h to cały dotychczasowy czas spotkań (45 min · 6 osób · 5 dni), a nie zaoszczędzona różnica.

Dlaczego tak

Praca programisty wymaga dłuższych okresów nieprzerwanej koncentracji, a każde przerwanie wymusza ponowne wdrożenie się w problem. Bloki czasu skupienia z wyciszonymi powiadomieniami, uzupełnione o ustalone godziny na pytania, zachowują komunikację i ograniczają rozproszenie. Wymóg natychmiastowej odpowiedzi pogłębia problem, długie spotkania zabierają jeszcze więcej czasu, a zakaz pytań szkodzi współpracy.