Rozrost procesu

Od 4 lat pracuję nad tą samą aplikacją. Zaczynaliśmy w trzy osoby (nie licząc projektantów i ekspertów dziedzinowych): nasz kierownik projektu, a zarazem product owner i tester, jeden backendowiec i jeden frontendowiec. Tempo prac było niesamowite – codziennie rozmawialiśmy, a specyfikację, zmiany i zadania spisywaliśmy w OneNote. Ach, te dobre czasy, kiedy mogliśmy po prostu skupić się na programowaniu.

Potem pojawił się Redmine, a później JIRA. Na początku każda większa funkcja była opisana w jednym zadaniu, potem w story, a teraz zakładamy dla niej epic. Dlaczego? To nie kwestia złożoności – jest tak samo wysoka jak kiedyś. Może chodzi o złożoność kodu? To mógłby być powód, bo w dużym kodzie dodanie czegoś nowego wymaga czasem dodatkowej pracy. Ale to mamy opanowane, nowe rzeczy dodaje się dość łatwo. Więc o co chodzi? O liczbę osób w zespole. Kiedyś we trójkę mogliśmy wszystko omówić, spisać najważniejsze rzeczy, a szczegóły pominąć. Dziś mamy 2 backendowców, 5 frontendowców (łącznie ze mną, poniekąd scrum masterem), 2–3 testerów, product ownera i mnóstwo innych zespołów, których projekty od nas zależą. Pozostawienie czegoś niespisanego po prostu się nie sprawdzi. Każdy szczegół musi być zapisany, inaczej wywoła lawinę pytań i nieporozumień, przez które dostarczenie funkcji potrwa dwa, trzy razy dłużej.

A to tylko zadania… Do tego dochodzą kickoffy, retrospektywy, planowania, standupy, spotkania, na których gasimy konflikty w zespole… Tęsknię za małymi zespołami.