Jak wdrażać agile w Gamedev? Swoimi doświadczeniami dzieli się z Tobą Scrum Masterka Adrianna Górska. Akcja #PmGościnnie ruszyła – zapraszam do lektury 🙂
Akcja #PmGościnnie ruszyła! Zapraszam na pierwszy gościnny wpis. Adrianna Górska, scrum masterka podzieliła się swoimi doświadczeniami stosowania scruma przy wytwarzaniu gier. Cieszę się, że jej tekst i doświadczenie wzbogaci treści, które docierają do mojej społeczności. Masz ochotę podzielić się swoim doświadczeniem? Pisz tekst i wysyłaj na: biuro@annajaszczolt.com. Uwaga! Nie przyjmuję reklam i lokowania produktów. Na tym blogu publikowane są treści merytoryczne oraz inicjatywy, produkty, usługi, które uznam za wartościowe i godne polecenia. Owocnej lektury, przekazuje Cię “w pióro” Adrianny 🙂
Myślisz, że jesteś agile? To zapraszam do Gamedev’u! Branża ta stawia wiele wyzwań. W niniejszym artykule znajdują się lessons learned z moich doświadczeń ze scrumem w branży gier.
Przez rok pracowałam w studiu gier, które było również start-up’em. Oprócz gry na VR, pracowaliśmy nad rewolucyjną technologią, mającą zmienić oblicze rynku wirtualnej rzeczywistości. Spotkało mnie tam wiele wyzwań, jednym z nich było wprowadzenie agile’a do organizacji. Droga do zwinności nie była łatwa, ale dzięki agile’owemu podejściu udało nam się osiągnąć wiele sukcesów.
Na początku swojej przygody z Gamedev’em szukałam wskazówek, artykułów dotyczących stosowania i wprowadzenia zwinności w tej branży. Niestety, nie znalazłam zbyt wielu informacji na ten temat i do wszystkiego musieliśmy wraz z zespołem dojść na sami, poprzez eksperymenty, metodą prób i błędów, czyli tak jak scrum Masterzy lubią najbardziej – empirycznie 🙂
Dlatego też zdecydowałam się popełnić ten artykuł, by zebrać lessons learned, które być może, przydadzą się osobom pracującym przy tworzeniu gier.
Jestem również bardzo ciekawa Waszej opinii na temat zebranych w tym artykule spostrzeżeń. Bardzo chętnie przyjmę feedback 🙂
Wyzwania
Zaczynając pracę w studiu gier miałam pewne wyobrażenie na temat zwinności, podparte pracą przy paru komercyjnych i niekomercyjnych projektach. Wydawało mi się, że scrum jest podejściem, które da się zastosować do każdego informatycznego projektu w zmieniającym się środowisku. Nie mogłam się doczekać, aż wejdę w rolę scrum Mastera i będę mogła szerzyć zrozumienie i stosowanie scruma.
Ku mojemu zaskoczeniu, nie okazało się to takie proste i finalnie zwinność w Gamedev’ie różniła się od moich pierwotnych wyobrażeń 🙂
Wzywanie 1: Duża ilość ról
Pierwszym wyzwaniem była duża ilość ról w teamie. W zespole deweloperskim co prawda nie ma podziału na role, ale „na upartego” można by wyróżnić programistę, testera, może jeszcze kogoś od UX. W Gamedev’owym zespole podział na role jest nieunikniony, a specjalizacji jest wiele – w moim zespole było ich akurat siedem i jakbyśmy się nie starali, to osoba od fabuły nie zaprogramowałaby nam nowego ficzera 🙂
Rozwiązanie: Podziel sprint na mniejsze sprinty.
Przy takiej ilości ról nie dawało się wszystkiego spiąć w jeden sprint. W kilka mniejszych już tak, w których zespół był w stanie dowieźć coś razem, czyli w naszym przypadku powstały zespoły z takimi rolami:
– Programmer + Level Designer + 3D Animator,
– Story Writter + Concept Artist + 3D Artist + Game Designer.
Ponadto każdy członek zespołu pełnił również rolę testera, dzięki czemu nauczyliśmy się dawać i otrzymywać bezpośredni feedback.
Wyzwanie 2: Rozproszone środowisko
W dobie pandemii COVID-19 praca zdalna jest powszechnym zjawiskiem. Mimo to nadal stanowi niemałe wyzwanie. Wiele już zostało napisane, nie mniej jednak i ja wtrącę tu swoje „trzy grosze” 🙂
Rozwiązanie: Komunikacja i integracja to klucz
Praca nad wytwarzaniem gry wymaga kreatywności, gdy do tego dodamy pracę zdalną, newralgicznym momentem staje się dobry przepływ informacji w organizacji i możliwość wymiany zdań.
Dlatego też wszystkie wydarzenia scrumowe odbywały się w pełnym teamie. Zwiększało to zaangażowanie zespołu, ponieważ przy podejmowaniu decyzji, czy to dotyczącej fabuły, czy animacji postaci, każdy mógł się wypowiedzieć. Budowało to również atmosferę zaufania i zachęcało do konfliktów, a zarazem zwiększało motywację zespołu i poczucie odpowiedzialności, gdyż każdy wiedział, w którym momencie projektu jesteśmy i dokąd zmierzamy. Nasz zespól liczył do 10 osób, więc mogliśmy sobie na to pozwolić, a pilnowanie timeboxów stało się z czasem naszą misją 🙂
Fajną praktyką okazało się testowanie marketingowych materiałów na naszych wewnętrznych kanałach, przed wypuszczeniem ich w świat. Social Media’owe posty bywają często kontrowersyjne, wobec czego stale się integrowaliśmy, prowadząc burzliwe dyskusje na temat różnego rodzaju nowinek ze świata.
Wyzwanie 3: Dług technologiczny
Kolejnym wyzwaniem było to, że dołączyłam do zespołu w trakcie trwania projektu. Jak to z projektami prowadzonymi kaskadowo bywa, oznaczało to nagromadzenie długu technologicznego.
Rozwiązanie: Done is better than perfect
Moim pierwszym krokiem, po dołączeniu do zespołu, było zidentyfikowanie długu technologicznego i wyestymowanie go. Postanowiliśmy go zmniejszyć i spłacać sukcesywnie, przy tworzeniu nowych funkcjonalności. Zdecydowaliśmy się również, by powstające przyrosty, mimo, że niedoskonałe, to były dowożone, a z czasem doskonalone. Pomocne było tu sformułowanie i stałe doskonalenie definition of done.
Wyzwanie 4: To jakiego podejścia użyć?
Dzięki komunikacji zbudowałam zespół otwarty na zmiany, chętny do przeprowadzania eksperymentów.
I tak oto, ze scrumowych praktyk zdecydowaliśmy się zostawić: sprinty, wydarzenia scrumowe, definition of done.
Z Extreme Programming sprawdziło się nam wprowadzenie Dobrych Praktyk, refactoring oraz, gdy było to możliwe, programowanie parami.
Zaczerpnęliśmy również dużo z leanu, jako, że celem naszym było dostarczenie jak najlepszego produktu. Wiązało się to również z Kaizenem, poprzez ciągłą eliminację marnotrawstwa, najczęściej związaną ze zmianą wątków. Wprowadziliśmy również standaryzację. Z TDD wzięliśmy ciągłą integrację, a z BDD tworzenie testów z punktu widzenia użytkownika systemu.
Rozwiązanie: Eksperymentuj i obserwuj!
Jak widać, zadziałał tu pełen misz-masz technik, podejść i narzędzi, a praca w środowisku Gamedev’owym nie mogła być sprowadzona do czysto scrumowego podejścia, które to na początku wydawało mi się najwłaściwsze 🙂
Lessons Learned
Przytoczone wyżej rozwiązania sprawdziły się w moim zespole, ale wcale to nie oznacza, że sprawdzą się w innym. Nie oznacza to również, że były to najdoskonalsze praktyki dla nas, bo zawsze pozostaje przestrzeń do usprawnień 🙂
Podsumowując, moje lessons learned z przygody zwanej Gamedev’em to:
- Zwinność nie oznacza odhaczania punktów ze scrumowej lub innej checklisty, a stosowanie praktyk, które najlepiej pasują do organizacji, i które umożliwiają dostarczanie rozwiązań.
- Komunikacja to clue, tak samo jak integracja i budowanie otoczenia otwartego na zmiany, szczególnie w rozproszonym środowisku, jakim często jest praca w Game Devie.
- To prawda jak mawiają, że done is better than perfect 🙂
- Jeżeli musisz, podziel Sprint na mniejsze sprinty, a zespół na mniejsze części, tak aby team był w stanie coś razem dowieźć.
- Obserwuj otoczenie, wyciągaj wnioski.
- Niech żyje empiryzm!
Bardzo się cieszę, że dotarłeś do końca mojego artkułu! Wyzwań w Gamedevie było wiele, zdecydowałam się przedstawić tu jedynie kilka. Mam nadzieję, że chociaż trochę pomogłam osobom szukającym wskazówek w tym temacie.
Adrianna Górska
Jeżeli macie jakieś doświadczenia ze zwinnością podczas produkcji gier to z chęcią ich wysłucham. Bardzo proszę również o feedback dotyczący powyższych rozwiązań. Zapraszam do komentowania 🙂
O autorce tekstu
Adrianna Górska (linkedin) wprowadziła zwinność do studia gier, będącego zarazem start-upem, pracującym nad innowacyjną technologią VR. Realizowała wiele projektów non-profit, min zorganizowała największy hackathon sztucznej inteligencji w północnej Polsce. Aktualnie, chciałaby odejść od roli project managera i podjąć nowe wyzwania, by jako scrum master całkowicie oddać się szerzeniu zrozumienia i stosowania scruma oraz innych, zwinnych metod wytwarzania oprogramowania i produktów, gdyż usprawnianie procesów i praca z ludźmi sprawia jej najwięcej satysfakcji. Jest certyfikowanym Professional Scrum Masterem, inż. Informatycznych Technologii w Zarządzaniu. Dla przyjemności praktykuje jogę, startuje w Runmangeddonie i zwiedza świat z przyjaciółmi.
Pamiętaj o naszej konferencji #PmTalks: 1-2 lipca 2020 roku
Goście specjalni: Jurgen Appelo, Susanne Madsen
Debata ekspertów: Małgorzata Kusyk, Igor Mróz
Do tego 9 prelegentów-praktyków!
Szczegóły pod linkiem oraz w filmiku poniżej.
