Scrum i Agile w studiu game dev – czy to ma sens? Jak pracujemy projektowo w Brave Lamb Studio

Podczas mojej 10-letniej pracy w sektorze game dev zauważyłem wśród producentów oraz leadów poszczególnych działów chęć poszukiwań coraz doskonalszych metod zarządzania i wspierania projektów developerskich. Modna jest także próba przenoszenia metodologii znanych z twardego IT „as it stands” bezpośrednio do projektów game developerskich. W dzisiejszym artykule opowiem o możliwych zastosowaniach Scrum i Agile w game dev oraz w jaki sposób zarządzamy projektami w Brave Lamb Studio i jak podejść do metodologii zwinnych w projektach tworzenia gier.

Cel wprowadzenia metodologii zwinnego zarządzania projektem w game dev

Rozmawiając z nowymi podmiotami rozpoczynającymi produkcję gier komputerowych, często spotykam się ze sformułowaniami:

• potrzebujemy metodologii zarządzania projektami, żeby kontrolować zespół developerski;
• musimy wiedzieć, czy dowiozą grę;
• trzeba ich popędzać, żeby zrobili grę szybciej;
• nie ufamy zespołowi, bo go nie znamy – musimy rozumieć, jak pracują.

Dlaczego powyższe sformułowania występują szczególnie w odniesieniu do początkujących zespołów developerskich? Najczęściej dzieje się tak z kilku powtarzalnych przyczyn:

• w momencie rozpoczęcia prac nad grą nie jest znany zakresu projektu, a jedynie jego ogólny zarys;
• nie są znane realne potrzeby projektu względem możliwości zespołu, którym dysponujemy. Często spotykane zjawisko to zachowanie „ślepego czołgu”, gdzie widoczne jest silne parcie w kierunku realizacji zakresu bez patrzenia na realne możliwości zespołu;
• producenci nie rozumieją złożoności poszczególnych zadań i podejmują decyzję o priorytetach intuicyjnie (bo przecież fizyka samochodu może być paczką z asset store), a nie na podstawie zakresu gry i feedbacku zespołu;
• zespół budowany jest oportunistycznie. Nikt wcześniej ze sobą nie pracował, i nawet liderzy poszczególnych obszarów technologicznych (tak, dziś grafika 3D to również technologia!) nie mają doświadczenia pozwalającego na empiryczne zrozumienie zakresu projektu.

Jak widać na powyższych przykładach, często poszukiwanie metodologii zarządzania projektem oparte jest o błędne lub wręcz negatywne pobudki opisane powyżej. Jak w takim razie zwinnie wdrożyć metodologię zarządzania projektami game dev, a jednocześnie sprawić, by służyła ona właściwym celom?

Po pierwsze: pamiętajmy, że najważniejszym celem metodologii Scrum czy Kanban jest poprawa komfortu pracy zespołu. Zespół nie jest tu rozumiany jako grupa developerów stawiana nijako w opozycji do producenta czy producentów. Producent jest częścią zespołu Scrumowego, a jego zadaniem jest uczestniczenie w bieżącej pracy zespołu. Komfort jego pracy jest więc stawiany na równi z komfortem zespołu developerskiego.

Po drugie: pamiętajmy, że metodologia służy projektowi, a nie odwrotnie. Jeżeli w toku prac dojdziemy do wniosku, że jakiś komponent metodologii nie działa, dostosujmy ją do własnych potrzeb lub porozmawiajmy o jej dostosowaniu. Oczywiście należy rozróżnić wygodę pracy od lenistwa, bo ryzyko zatracenia sensu zarządzania projektem będzie bardzo wysokie. Niewpisywanie zadań w backlog gry to lenistwo, ale zmiana konfiguracji pól kształtujących zadanie pod wolę zespołu to już wygoda.

Po trzecie: zawrzyjmy z zespołem umowę o przestrzeganiu pewnych zasad. Oczywistością naszej pracy są częste nadgodziny przy ważnych milestone’ach, silne emocje związane z procesem kreacji i własności tego, co tworzymy, a także chęć „rzucenia się w wir walki” w podbramkowych momentach. Wierzę, że potrafiąc przewidzieć nadejście takich momentów, umożliwimy zespołowi wypracowanie metodologii radzenia sobie z nimi. W Brave Lamb Studio w sytuacji dużego natężenia pracy (np. przy okazji niedawnego ukończenia vertical slice) opanowujemy takie sytuacje poprzez:

• określenie, co jest do zrobienia (definition of done);
• określenie, jak to ma być zrobione (definition of ready);
• dostosowanie zadań do realiów – grooming urealniający dany sprint;
• wprowadzenie właściwych, udoskonalonych zadań z urealnioną wyceną czasu.

Powyższe metody sprawiają, że w razie crunchu czy wzmożonej pracy sytuacja jest o wiele bardziej uporządkowana niż typowe crunchowanie nad iteracją rzeczy bez jasno określonych kryteriów akceptacji. Należy przy tym pamiętać, że Scrum i Agile w Game Dev, czy inne metodyki to jedynie sposób na osiągnięcie pewnego celu, a nie sens sam w sobie.

Jak zarządzamy projektami w Brave Lamb Studio?

Codzienność w Brave Lamb Studio wyznaczają tak zwane stand-upy. Codziennie o 9:30 odbywamy telekonferencje ze wszystkimi członkami zespołu, którzy informują pozostałych na temat stanu prac według schematu:

• Co robiłem/robiłam wczoraj?
• Co będę robił/robiła dzisiaj?
• Czy potrzebuję z kimś porozmawiać lub mam jakieś problemy?

To działanie sprawia, że jako producent jestem poinformowany po bieżącej sytuacji w projekcie i szybko identyfikuję potencjalne duże ryzyka, które powinniśmy omówić lub przeprocesować. Dzięki temu wszyscy kontrolujemy projekt i jesteśmy w stanie odpowiednio zareagować na wszystkie zmiany każdego dnia.

Dodatkowo każdy zespół – programistów, designerów oraz artystów – odbywa zazwyczaj raz w tygodniu grooming, podczas którego tworzone są zadania na kolejne jednostki projektowe (tzw. sprinty). Podczas tego spotkania analizowane są ramowa roadmapa projektu oraz cele bieżące, z których następnie tworzone są zadania do backlogu kolejnych sprintów. Przyjmujemy ogólną zasadę rozwoju każdego elementu gry według schematu:

• design funkcjonalności,
• feedback do designu,
• wdrożenie prototypu,
• feedback do prototypu,
• wdrożenie docelowe.

Powyższa struktura znajduje odzwierciedlenie w zadaniach w backlogu, które „wpadają” do określonych sprintów, czyli okresów kończących się spotkaniem zwanym sprint review. W Brave Lamb, nad War Hospital pracujemy w dwutygodniowych sprintach, a na sprint review zapraszamy zarówno wszystkich członków zespołu developerskiego, jak i interesariuszy zewnętrznych (np. inwestorów, członków zarządu czy przedstawicieli wydawcy). Podczas tego spotkania prezentujemy postępy prac zgodnie z porządkiem zadań, które zostały wykonane podczas sprintu.

Gdy prezentacja zakończy się, zespół już wewnętrznie przeprowadza proces planowania. Wspólnie umieszczamy w nowej tablicy sprintu zadania, które będą realizowane w najbliższych tygodniach, wraz ze sprawdzeniem ich kompletności (referencji, materiałów czy określonych kryteriów akceptacji). Wykonujemy także wyceny.

W Brave Lamb Studio jesteśmy w trakcie transformacji systemu wycen. Dotychczas zadania wyceniane są w osobodniach, przy czym najmniejszą jednostką rozliczeniową jest 0,5 dnia roboczego. Staramy się nie planować zadań, które przekraczają 5 dni roboczych ze względu na duże ryzyko nieukończenia ich w terminie. Staram się wspólnie z zespołem rozbijać takie zadanie na mniejsze, by móc uzyskać bardziej dokładne wyceny jednostkowe.

Przykładowy wykres spalania sprintu. Czerwona linia odzwierciedla zaplanowany zakres prac, zielona to jak zespół kończy zadania. Tutaj widoczny mistake rate (współczynnik błędu wyceny) to około 16% więc w górnych granicach normy, biorąc pod uwagę czas w jakim zespół pracuje ze sobą. Zamykanie zgłoszeń na koniec projektu to sygnał dla producenta dotyczący, albo mniejszej atencji na zamykanie zadań w systemie Jira, albo że duże zadania są kończone na ostatnią chwilę – wymaga to głębszej analizy

W ciągu najbliższych miesięcy będziemy stopniowo przechodzić na wyceny abstrakcyjne (tzw. story points), które będą pozwalały na ocenę nie tylko czasochłonności, ale także złożoności zadania, co pozwoli zwiększyć dokładność naszych estymacji.

Czy warto prowadzić projekty przy pomocy metodologii zwinnych?

Biorąc pod uwagę własne doświadczenia z pracy w statycznym i zwinnym planowaniu projektów, zdecydowanie wolę pracę w metodologiach zwinnych. Scrum i Agile w game dev pozwala na to, że dzięki takiemu podejściu rola producenta przestaje być „rozkazująca”, a staje się wspierająca dla zespołu i „udrażniająca” wobec wszelkich jego trudności. Odpowiedzialność za rezultaty staje się zespołowa, a roadmapa gry staje się realniejsza, gdyż wynika z szacunków zespołu, a nie narzutu producenta, który najczęściej nie ma pełnej wiedzy o niuansach projektowych czy trudnościach technicznych. To czyni projekt znacznie bardziej transparentnym.