Planuje wykonanie zadania

Dlaczego tak

Daily stand-up trwa kilkanaście minut i służy synchronizacji zespołu: każdy mówi, co zrobił, co zamierza zrobić i jakie przeszkody napotyka, aby inni mogli pomóc. Przegląd kodu to osobna czynność wykonywana np. w pull requestach, bo na spotkaniu zajęłaby zbyt dużo czasu. Ocena kolegów nie jest celem tego spotkania, a planowanie długoterminowe odbywa się na planowaniu sprintu lub wydania.

Dlaczego tak

Oczekiwany czas w metodzie PERT oblicza się ze wzoru (O + 4·M + P) / 6, czyli (2 + 4 · 4 + 12) / 6 = 30 / 6 = 5 dni. Wartość najbardziej prawdopodobna ma wagę 4, ale wariant pesymistyczny przesuwa wynik w górę. Zwykła średnia trzech wartości, (2 + 4 + 12) / 3, daje 6 dni, a przyjęcie samego wariantu najbardziej prawdopodobnego pomija ryzyko opóźnień.

Dlaczego tak

Macierz Eisenhowera dzieli zadania według pilności i ważności, a zadania pilne i ważne wykonuje się od razu. Błąd blokujący płatności na produkcji spełnia oba warunki, bo każda minuta oznacza utracone zamówienia. Refaktoryzacja jest ważna, ale nie pilna, więc się ją planuje, newsletter nie jest ważny, a przeglądanie nowości nie jest ani pilne, ani ważne dla bieżącej pracy.

Dlaczego tak

Przy równomiernym tempie zespół powinien wykonywać 40 / 10 = 4 punkty dziennie, więc po 6 dniach powinno zostać 40 − 6 · 4 = 16 punktów. Pozostało 28, czyli o 12 więcej niż na linii idealnej wykresu spalania (burndown) – zespół jest opóźniony. Wartość 28 to cała pozostała praca, a nie opóźnienie, a wyprzedzenie planu oznaczałoby mniej niż 16 pozostałych punktów.

Dlaczego tak

Przy nieprzewidzianym, pilnym zadaniu plan zmienia się jawnie: zespół wykonuje to, co najważniejsze, a o rezygnacji z części zakresu decyduje razem z osobą odpowiedzialną za priorytety. Ukryte nadgodziny maskują problem i prowadzą do przemęczenia. Odkładanie krytycznego błędu naraża klienta na straty, a pomijanie testów przenosi ryzyko na kolejne wydanie.

Dlaczego tak

Rzetelna samoocena opiera się na mierzalnych kryteriach jakości: spełnieniu wymagań, liczbie wykrytych błędów i dotrzymaniu terminu. Porównywanie się z gorszymi nie mówi nic o jakości własnej pracy. Liczba wierszy kodu jest złą miarą – krótszy kod często jest lepszy – a uprzejmość klienta nie zależy od jakości wykonanego zadania.