Kieruje wykonaniem przydzielonych zadań

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.