Kiedy Agile przestaje być zwinny

O tym, jak w gamedevie sami sabotujemy swoją zwinność

Agile jest najlepszym, co branża gamedevowa była w stanie zaadaptować z klasycznego software developmentu. To nie jest tekst przeciwko Agile’owi. Wręcz przeciwnie — to tekst o tym, dlaczego Agile działa i dlaczego czasem przestaje działać dokładnie w momencie, w którym najbardziej chcemy, żeby działał.

Problem nie polega na tym, że Agile jest zły.
Problem polega na tym, że zbyt często traktujemy go jak uniwersalne rozwiązanie na każdy etap produkcji gry.

A game dev jest bardzo odporny na jakiekolwiek standaryzacje.

Agile został stworzony do „funkcjonalnego software’u”.

My tworzymy emocje.

Agile powstał w świecie, w którym „działa” jest wystarczającym kryterium sukcesu.
Funkcja działa. System działa. Feature jest dostępny.

W gamedevie to za mało.

Gra może działać perfekcyjnie — i jednocześnie:

• nie być fun,

• nie budzić emocji,

• nie wspierać fantazji gracza,

• nie pasować do reszty doświadczenia.

I tu pojawia się pierwsze fundamentalne pęknięcie:
Agile bardzo dobrze radzi sobie z funkcjonalnością, ale zupełnie nie rozumie jakości emocjonalnej.

Acceptance Criteria świetnie odpowiadają na pytanie:

„Czy mogę to zrobić?”

Ale w gamedevie kluczowe pytanie brzmi:

„Czy to jest fajne?”

A na to Agile — w swojej klasycznej formie — odpowiedzi nie ma.

Agile działa świetnie… na początku

W preprodukcji, Agile jest niemal idealnym narzędziem.

Nie wiemy jeszcze:

• czym dokładnie będzie gra,

• jak złożony okaże się gameplay,

• które pomysły przetrwają kontakt z rzeczywistością.

Eksplorujemy. Prototypujemy. Odkrywamy pracę, której jeszcze nie umiemy nazwać.

Krótkie sprinty, szybkie iteracje, ciągły feedback — to wszystko:

• obniża koszt błędów,

• pozwala szybko porzucać złe pomysły,

• wspiera empiryczne podejmowanie decyzji.

Na tym etapie Agile robi dokładnie to, co powinien.

Pierwszy sabotaż: „wydłużmy sprinty, bo nie dowozimy”

I tu zaczyna się problem, który widziałem wielokrotnie – w małych zespołach, w dużych studiach, przy różnych gatunkach gier.

Na początku produkcji wszystko trwa długo.
Budowanie nowych feature’ów jest ciężkie, kosztowne, nieprzewidywalne.

Dwutygodniowe sprinty wydają się za krótkie.
Czterotygodniowe milestone’y – zbyt ciasne.

Pojawia się więc logiczna, rozsądna prośba:

„Wydłużmy sprinty. Dajmy sobie więcej czasu, żeby dowieźć realną wartość.”

I faktycznie – krótkoterminowo to działa.

Ale długoterminowo uczymy się bardzo złych nawyków:

• gorszej granulacji zadań,

• mniej precyzyjnych priorytetów,

• rozmytego rozumienia zakresu pracy,

• trudniejszych commitmentów.

Zwinność zaczyna się rozciągać. Dosłownie.

Drugi sabotaż: długa pętla feedbacku

Najgorsze skutki długich sprintów i milestone’ów pojawiają się później — kiedy gra już „jest”.

Mamy feature’y.
Mamy content.
Zaczynamy iterować na istniejącej bazie.

I nagle okazuje się, że:

• jeden zespół dostarcza feature dopiero na koniec milestone’a,

• drugi zespół zaczyna na nim pracować… też dopiero wtedy,

• feedback pojawia się po tygodniach, a nie dniach.

Jeśli coś nie działa tak, jak trzeba – poprawka musi poczekać.
Bo zespół, który dostarczył feature już:

• zaplanował kolejny sprint,

• zaplanował kolejny milestone,

• jest „zacommitowany”.

W praktyce oznacza to, że na prostą poprawkę czekamy nie raz 6–9 tygodni.

To jest dokładne zaprzeczenie idei Agile’a!

Co robimy wtedy?

• Przeplanowujemy.

• Łamiemy commitmenty.

• Przepalamy czas spędzony na planingach.

Proces, który miał nas chronić przed chaosem, sam staje się jego źródłem.

Moment, w którym Agile zaczyna przeszkadzać

Jest taki punkt w produkcji gry — często okolice feature complete / alfy — w którym:

• wiemy już, jakie feature’y mamy,

• znamy skalę contentu,

• nie odkrywamy już „czym jest gra”,

• tylko produkujemy ją wszerz.

I to jest moment, w którym Agile bardzo często przestaje pasować do rzeczywistości.

Ten etap produkcji:

• przypomina fabrykę,

• wymaga przewidywalności,

• wymaga stabilnych zależności,

• wymaga minimalizowania zmienności.

Paradoksalnie – powrót do Waterfalla może być wtedy najbardziej zwinną decyzją, jaką możemy podjąć.

Nie dlatego, że Waterfall jest lepszy.
Tylko dlatego, że jest bardziej adekwatny do fazy projektu.

Prawdziwa zwinność to zmiana metody

Największym błędem, jaki popełniamy w gamedevie, nie jest używanie Agile’a.

Największym błędem jest trzymanie się jednej metodologii niezależnie od kontekstu.

Zwinność nie polega na tym, że:

• mamy sprinty,

• mamy daily,

• mamy retrospekcje.

Zwinność polega na tym, że:

• potrafimy zakwestionować własny proces,

• potrafimy zmienić narzędzie, gdy przestaje działać,

• potrafimy przyznać, że to, co było dobre wczoraj, dziś już szkodzi.

Agile nie jest religią. Jest narzędziem.

Agile w gamedevie jest:

• świetny w preprodukcji,

• niezbędny w odkrywaniu problemów,

• bardzo niebezpieczny, gdy stosowany bezrefleksyjnie.

Prawdziwa dojrzałość produkcyjna zaczyna się wtedy, gdy zadajemy sobie pytanie:

„Czy metoda, z której korzystamy, wciąż służy temu, co aktualnie robimy?”

Bo w gamedevie:

• nie zawsze chodzi o szybkość,

• nie zawsze chodzi o iterację,

• bardzo często chodzi o jakość doświadczenia.

A ta nie mieści się w Acceptance Criteria.