Planuje i organizuje pracę zespołu w celu wykonania przydzielonych zadań

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.