Test INF.03 — zestaw 16

Dlaczego tak

Zasada „coś za coś” chroni interesy obu stron: zespół zgadza się na rozszerzenie zakresu, ale w zamian za dłuższy termin lub wyższą cenę, co pozwala wykonać pracę rzetelnie. Natychmiastowa zgoda bez rekompensaty prowadzi do strat i przeciążenia zespołu. Odmowa bez uzasadnienia zamyka negocjacje, a ukryte cięcie testów to nieuczciwość wobec klienta.

Dlaczego tak

Wspólna tablica zadań, np. Kanban, pokazuje, kto nad czym pracuje, a przypisanie wykonawcy do zadania sprawia, że nikt nie podejmie go drugi raz i widać zadania bez właściciela. Dłuższe spotkania zabierają czas, a nie rozwiązują braku przejrzystości. Osobne kopie projektu jeszcze bardziej utrudniają koordynację, a zakaz rozmów pogarsza komunikację w zespole.

Dlaczego tak

Diagram Ishikawy, nazywany też diagramem rybiej ości, porządkuje możliwe przyczyny problemu w kategoriach odchodzących od głównej osi prowadzącej do skutku. Metoda 5 Why polega na wielokrotnym zadawaniu pytania „dlaczego” wzdłuż jednego łańcucha przyczyn, bez podziału na kategorie. Burza mózgów służy do swobodnego zbierania pomysłów, a SWOT ocenia mocne i słabe strony oraz szanse i zagrożenia.

Dlaczego tak

W burzy mózgów oddziela się generowanie pomysłów od ich oceny: w pierwszej fazie zakazana jest krytyka, a celem jest jak największa liczba propozycji, także nietypowych, bo mogą zainspirować innych. Ocena kosztów i wybór najlepszych następują dopiero w drugiej fazie. Ograniczenie wypowiedzi do najbardziej doświadczonych lub zapisywanie tylko zaakceptowanych pomysłów niszczy sens metody.

Dlaczego tak

Gdy zespół odpowiada za wspólny cel, członek zespołu, który skończył swoją część, pomaga w zadaniach zagrażających realizacji sprintu. Rozpoczynanie kolejnych zadań nie pomoże ukończyć bieżących, a szukanie winnego zamiast pomocy niszczy zaufanie w zespole. Nauka nowej biblioteki jest wartościowa, ale nie w chwili, gdy wspólny cel jest zagrożony.

Dlaczego tak

Scrum Master dba o skuteczność zespołu i usuwanie przeszkód (impediments), które ograniczają jego pracę, m.in. chroni go przed zakłóceniami z zewnątrz. Product Owner zarządza rejestrem produktu i ustala priorytety, ale nie odpowiada za usuwanie przeszkód. Programiści zgłaszają problemy, jednak rozwiązywanie konfliktów z innymi działami należy do Scrum Mastera, a klient nie jest rolą w Scrumie.

Dlaczego tak

Zaangażowanie przejawia się w podejmowaniu odpowiedzialności za wspólny rezultat także poza przydzielonymi zadaniami — a zapisanie zadania na tablicy informuje zespół, że ktoś się nim zajął. Bierne czekanie na przydział sprawia, że braki pozostają nieuzupełnione. Lekceważenie dokumentacji utrudni pracę innym, a publiczne wytykanie autora nie rozwiązuje problemu.

Dlaczego tak

Wspólnie wypracowanego ustalenia przestrzega się także wtedy, gdy wydaje się ono niewygodne — przy pilnej zmianie wystarczy poprosić o szybki przegląd. Wyjątek „bo poprawka jest drobna” podważa zasadę, a jednowierszowe zmiany też potrafią zepsuć aplikację. Czekanie na spotkanie opóźnia naprawę błędu, a jeśli zasada wydaje się zbyt sztywna, omawia się ją z zespołem, zamiast ją łamać.

Dlaczego tak

Struktura macierzowa łączy podział funkcjonalny (działy według specjalności) z podziałem projektowym, więc pracownik ma dwóch przełożonych: liniowego i projektowego. W strukturze liniowej obowiązuje zasada jednoosobowego kierownictwa — każdy ma dokładnie jednego przełożonego. W strukturze funkcjonalnej polecenia wydają specjaliści z różnych dziedzin, ale bez osobnych zespołów projektowych, a struktura płaska oznacza małą liczbę szczebli kierowania.

Dlaczego tak

Duże zadanie dekomponuje się na mniejsze części (struktura podziału prac, WBS), np. katalog produktów, koszyk, płatności, panel administracyjny. Małe zadania łatwiej oszacować, przydzielić konkretnym osobom i sprawdzić, czy zostały ukończone. Przekazanie całości jednej osobie nie rozwiązuje problemu szacowania, a praca bez planu lub termin przyjęty w ciemno grożą przekroczeniem budżetu i czasu.

Dlaczego tak

Przewody w przejściu grożą potknięciem i uszkodzeniem izolacji, dlatego prowadzi się je w osłonach lub listwach poza ciągami komunikacyjnymi. Łączenie przedłużaczy jeden za drugim (kaskadowo) i podłączanie wielu urządzeń do jednego gniazdka grozi przeciążeniem i przegrzaniem obwodu, a w efekcie pożarem. Przykrycie przewodów dywanem ukrywa ewentualne uszkodzenie i nie rozwiązuje problemu przeciążenia.

Dlaczego tak

Prędkość zespołu (velocity) to średnia liczba punktów ukończonych w sprincie: (18 + 22 + 20) / 3 = 20 punktów. Na 100 pozostałych punktów potrzeba więc 100 / 20 = 5 sprintów. Odpowiedź 6 wynika z przyjęcia najgorszego wyniku (100 / 18 ≈ 5,6, w zaokrągleniu w górę), a 4 — z przyjęcia najlepszego (100 / 22 ≈ 4,5, zaokrąglonego w dół).

Dlaczego tak

Ustalenia ważne dla całego zespołu i potrzebne później przekazuje się pisemnie, w miejscu dostępnym dla wszystkich, np. w zadaniu w systemie do zarządzania pracą, i informuje o nich zespół. Rozmowa w kuchni i SMS do jednej osoby nie docierają do wszystkich, a przekaz ustny bez zapisu zniekształca się i ginie. Pisemny ślad chroni też zespół w razie sporu z klientem o zakres.

Dlaczego tak

Programowanie w parach (pair programming) polega na wspólnej pracy przy jednym kodzie w rolach kierowcy, który pisze, i nawigatora, który na bieżąco analizuje i podpowiada, z regularną zamianą ról. Przegląd kodu odbywa się po napisaniu zmian, a nie równolegle z pisaniem. Programowanie ekstremalne to cała metodyka, w której pary są tylko jedną z praktyk, a w mentoringu role się nie zamieniają.

Dlaczego tak

Ola zna bazy i PHP, więc wykonuje X w dniach 1–3, a od dnia 4 kontynuuje Z — zadania nie nachodzą na siebie i zachowana jest zależność Z po X. Piotr w dniach 1–2 przygotowuje szablon HTML zgodny z jego umiejętnościami. Pozostałe przydziały albo każą jednej osobie robić dwie rzeczy naraz w dniach 1–2, albo powierzają bazę i API osobie znającej tylko HTML i CSS.

Dlaczego tak

Ocena przydatności uwzględnia nie tylko kompetencje, ale i dostępność w czasie realizacji zadania. Anna ma największe doświadczenie, ale przez cały okres zadania jest nieobecna, więc nie może go wykonać — to najbardziej kusząca odpowiedź. Bartek łączy dobrą znajomość PHP z dostępnością. Celina może pomóc w testach po migracji, a Darek nie ma potrzebnych umiejętności.

Dlaczego tak

Zadanie dla stażysty powinno odpowiadać jego umiejętnościom i lekko je rozwijać, a przegląd przez doświadczoną osobę zapewnia jakość i naukę. Szablon podstrony w HTML i CSS spełnia te warunki. Migracja bazy produkcyjnej i konfiguracja zapory wymagają doświadczenia, a pomyłka stażysty mogłaby spowodować utratę danych lub awarię, natomiast negocjacje z klientem należą do kierownika projektu.

Dlaczego tak

Zadanie A zajmuje dni 1–2. B i C zaczynają się równolegle w dniu 3: C kończy się w dniu 5, a B — w dniu 6. D wymaga ukończenia obu, więc najwcześniej rusza w dniu 7. Odpowiedź 6 bierze pod uwagę tylko krótsze zadanie C, a 10 sumuje czasy A, B i C, jakby wszystkie wykonywano po kolei.

Dlaczego tak

Zasada z limitem czasu równoważy dwie potrzeby: najpierw samodzielna próba, która często wystarcza i nie odrywa innych od pracy, a potem prośba o pomoc, zanim problem zabierze godziny. Kanał zespołu sprawia, że odpowiedzieć może ktokolwiek wolny, a rozwiązanie widzą też inni. Zasada nie służy ocenianiu ludzi, nie zastępuje dokumentacji i wprost zakłada samodzielne próby.

Dlaczego tak

Przed pracą przy urządzeniach elektrycznych obwód nie tylko się wyłącza, ale też zabezpiecza przed przypadkowym ponownym załączeniem (blokada, tablica ostrzegawcza), a następnie sprawdza brak napięcia. Koordynator musi zadbać o tę kolejność, bo pracują przy tym różne osoby. Rękawice nie zastąpią odłączenia zasilania, a załączanie obwodu w trakcie prac lub przed ich przygotowaniem grozi porażeniem.

Dlaczego tak

W sytuacji awaryjnej dyspozycje muszą być jednoznaczne: kto, co i do kiedy ma zrobić, a potwierdzenie przyjęcia daje pewność, że polecenie dotarło. Ogólny apel powoduje rozmycie odpowiedzialności — każdy liczy, że zajmie się tym ktoś inny. Długa narada opóźnia działania w czasie awarii, a cotygodniowy raport jest zbyt wolnym kanałem.

Dlaczego tak

Przekroczony limit WIP i rosnąca kolejka przed kolumną „Testy” pokazują, że etap testów nie nadąża — jest wąskim gardłem całego procesu. Zgodnie z zasadą „skończ, zanim zaczniesz nowe” programiści powinni pomóc w testach, zamiast zwiększać kolejkę. Zniesienie limitu jedynie ukryje problem, bo zadania i tak będą czekać na przetestowanie.

Dlaczego tak

Konwencja Keep a Changelog grupuje zmiany w sekcjach: Added (nowe funkcje), Changed (zmiany istniejących), Deprecated (funkcje przeznaczone do usunięcia), Removed (usunięte), Fixed (naprawione błędy) i Security (poprawki bezpieczeństwa). Naprawa błędu podwójnych zamówień trafia więc do sekcji Fixed. Sekcja Added byłaby właściwa, gdyby dodano nową funkcję, np. zabezpieczenie jako zupełnie nową opcję.

Dlaczego tak

Pokrycie kodu to stosunek wierszy wykonanych przez testy do wszystkich wierszy: 1200 / 1600 = 0,75, czyli 75%, a więc mniej niż wymagane 80%. Wynik 133% powstaje przy odwróceniu ułamka (1600 / 1200), a 25% to część kodu niepokryta testami. Moduł należy uzupełnić o testy dla co najmniej 80 dodatkowych wierszy, aby osiągnąć 1280 z 1600.

Dlaczego tak

Warunek dotyczy każdej podstrony osobno, więc wystarczy jeden wynik poniżej progu — 88 punktów — aby praca nie została odebrana. Średnia (94 + 91 + 88 + 97) / 4 = 92,5 jest wyższa niż 90, ale warunek nie mówi o średniej, dlatego jej użycie to typowy błąd oceny. Próg 95 punktów nie wynika z warunków odbioru.

Dlaczego tak

Wypisanie danych od użytkownika bez zmiany pozwala wstrzyknąć do strony kod, np. <script>, który wykona się w przeglądarkach innych osób — to atak XSS. Funkcja htmlspecialchars() zamienia znaki specjalne HTML na encje (np. < na &lt;), więc wstawiony kod wyświetli się jako tekst. echo i print działają tak samo, metoda GET niczego nie zabezpiecza, a strtoupper() zmienia tylko wielkość liter.

Dlaczego tak

Każde spotkanie skraca się o 45 − 15 = 30 minut, a oszczędność dotyczy wszystkich sześciu uczestników: 6 · 30 = 180 minut dziennie. W ciągu 5 dni daje to 900 minut, czyli 15 godzin pracy zespołu. Wynik 2,5 godziny pomija liczbę uczestników (30 minut · 5 dni), a 22,5 godziny to łączny czas obecnych, 45-minutowych spotkań.

Dlaczego tak

Praca koncepcyjna wymaga dłuższych okresów skupienia, dlatego wprowadza się bloki czasu wolne od spotkań, a pytania niepilne kieruje na wspólny kanał, na który odpowiada się w wybranych porach. Więcej spotkań i obowiązek natychmiastowych odpowiedzi zwiększają liczbę przerw. Większy open space nie ogranicza ani hałasu, ani rozpraszających powiadomień.