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.
Rozmawiając z nowymi podmiotami rozpoczynającymi produkcję gier komputerowych, często spotykam się ze sformułowaniami:
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:
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:
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.
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:
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:
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.
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.
Brave Lamb Studio 2020
Produkty
Kontakt
Brave Lamb Studio S.A.
ul. Krucza 16/22,
00-526 Warszawa
Kontakt w sprawie rozwoju biznesu:
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |