| Zajęcia stacjonarne | Lekcja 1x45min |
| Opis jednozdaniowy | Warsztaty uczące zarządzania tzw. feature creepem oraz zbyt dużym scopem gry uchwyconymi na późnym etapie produkcji. |
| Materiały źródłowe | Podstawowe (warto poprosić uczestników, by zapoznali się z nimi przed zajęciami): Intro to Development Strategy, Part II: Heuristics for Backlog Management https://www.riotgames.com/en/news/intro-to-development-strategy-part-ii-heuristics-for-backlog-management Killing Feature Creep Without Ever Saying No https://www.gamedeveloper.com/production/killing-feature-creep-without-ever-saying-no How Saying 'No’ Can Help You Make a Better Game https://www.youtube.com/watch?v=r7eHlKBQVQ0 Up Sh*t Creek: Pro Tips for Managing the Unmanageable Project https://www.youtube.com/watch?v=dNlEZZlmIcw Dodatkowe: Mastering feature creep while changing the world https://www.gamesindustry.biz/mastering-feature-creep-while-changing-the-world Don’t Ship a Product, Ship Value: Start Your Minimum Viable Product With a Solution https://www.youtube.com/watch?v=w5LaYouF2p Product backlog: Tips for creation and prioritization: https://www.atlassian.com/agile/scrum/backlogs “A Playful Production Process: For Game Designers” R. Lemarchand, ss. 165, 287 |
| Czemu służy ta lekcja | Celem zajęć jest nauczenie praktycznych technik zarządzania zakresem produktu na późnym etapie produkcji. Uczestnicy poznają:jak rozpoznać feature creep i jego źródła,jak realistycznie konfrontować backlog z dostępnym czasem i zasobami,jak używać mechanizmów priorytetyzacji (np. MoSCoW) do świadomego wyboru elementów backlogu,jak podejmować decyzje o scope cut / trade / defer z uzasadnieniem opartym o filary gry, USP i analizę referencyjną. |
Jak się przygotować
- warto dać zespołom znać, że będą pracować na backlogach swoich projektów (zwłaszcza elementów, które jeszcze muszą wykonać i zaimplementować), przydatne więc będą wszelkie dokumenty produkcyjne (backlog, tablica na Trello, lista zadań, etc.) oraz informacje historyczne (czas pracy nad danym elementem, prędkość pracy, to ile godzin pracy są w stanie zmieścić w typowym tygodniu) – jeśli takich nie posiadają, nie ma sensu by produkowali je wstecznie, ale spisanie rzeczy pozostałych do wykonania bardzo się przyda;
- warto przypomnieć zespołom kwestie takich aspektów jak USP, praca na filarach gry, kluczowe mechaniki, analiza gier referencyjnych czy analiza benchmarkowa (zależnie od kontekstu zespołów);
- warto przygotować przypomnienie z zakresu priorytetyzacji metodą MoSCoW (Must Have, Should Have, Could Have, Won’t Have) i przećwiczyć ją na przykładzie jakiegoś niedużego i prostego projektu (Tetris, Snake, etc.), najlepiej poprzez wypisanie elementów takiej gry (oraz kilku, kilkunastu dodatkowych/zbędnych ulepszeń) a następnie przeprowadzenie z zespołami przypisania tych elementów do MoSCoW;
Jaką wiedzę należy przekazać
Backlog projektu
- backlog może mieć różne formy (lista zadań, board, tabela) – warto trzymać się tej odpowiadającej potrzebom projektu i zespołu,
- jego rola: skupienie pracy zespołu na rzeczach realnych i wartych zrobienia,
- backlog nie jest roadmapą ani sprint planem.
Priorytetyzacja
- wyjaśnić, w jaki sposób można oceniać priorytet konkretnego zadania w oparciu o analizę gier referencyjnych czy zdefiniowane przez zespół filary gry czy USP;
- przypomnieć MoSCoW i innych technik (RICE, Value vs Effort – w nawiązaniu do wcześniej omawianych narzędzi),
- jak priorytety wpływają na decyzje scope’owe.
Estymowanie pracy
- przypomnieć, jak działa estymowanie i po co je wykonujemy
- czym są osobogodziny, osobodni, osobomiesiące,
- jak szacować pracę i dlaczego warto uwzględniać testy i poprawki,
- jak określić, ile czasu realnie pozostało (zakładając czas na testy i poprawki oraz – idealnie – bufor 20-30%)
Decyzje scope’owe – przypomnienie:
- Scope cut: usuwamy funkcje, które nie wpływają na core experience,
- Scope trade: zamieniamy A na B, zachowując stabilność projektu,
- Defer: odkładamy elementy do późniejszej aktualizacji / wersji 2.0,
- decyzje oparte o USP, filary gry i analizę referencyjną, nie o preferencje osobiste.
Ćwiczenia praktyczne: Priorytetyzacja backlogu
Uczestnicy otrzymują:
- listę zadań/mechanik (np. z ich własnych projektów),
estymaty czasowe (osobogodziny/etykiety).
Zadanie:
- przypisać elementy do kategorii MoSCoW,
- policzyć, ile czasu pozostało (z buforem 20–30%),
- oznaczyć:
- 1 element do scope cut,
- 1 do scope trade,
- 1 do defer,
- krótko (1–2 zdania) uzasadnić wybory.
Uczestnicy prezentują wyniki → potem wspólna dyskusja.
Warto zapamiętać
- W trakcie produkcji gry pojawiają się nowe i ciekawe pomysły, jeśli nie trzyma się ich pod kontrolą, to łatwo zbyt rozbudować założenia;
- Estymowanie i zderzanie estymacji z pozostałym czasem pozwala wracać do bardziej realistycznej wersji projektu;
- Bufor jest konieczny – zwykle 20-30%;
- Zadanie nie jest skończone do momentu, gdy jest wpięte do gry, działa i zostało przetestowane (to może znacząco wpłynąć na estymaty);
- Im szybciej rzeczy jasno wytniemy na początku (zamiast trzymać je jako „może jednak”), tym sprawniej nam pójdzie zarządzanie pozostałymi zadaniami;
- Priorytetyzacją powinny sterować zewnętrzne wskaźniki (filary, USP, referencje, etc.) a nie personalne preferencje członków zespołu;
- MoSCoW to tylko jedno narzędzie – można korzystać z innych, jeśli są trafniejsze dla zespołu.