| Zajęcia stacjonarne | Lekcja 1x45min |
| Opis jednozdaniowy | Wykład uczy kryteriów i narzędzi decyzyjnych, które pomagają zespołom gamedevowym jednoznacznie stwierdzić, kiedy gra osiągnęła „stan skończony” – zbalansowany pod kątem jakości, priorytetów, zakresu i ryzyka – oraz jak formalizować decyzję o zamknięciu produkcji. |
| Materiały źródłowe | Podstawowe (warto poprosić uczestników, by zapoznali się z nimi przed zajęciami): What is the Definition of Done?: https://www.atlassian.com/agile/project-management/definition-of-done Kryteria akceptacji i definicja ukończenia: https://agile247.pl/kryteria-akceptacji-i-definicja-ukonczenia Definition of Done vs. Definition of Ready: https://resources.scrumalliance.org/Article/definition-vs-ready Dodatkowe: Definition of Done vs. Definition of Ready: The Checklists You’re Probably Not Using: https://medium.com/agile-true-north/definition-of-done-vs-definition-of-ready-the-checklists-youre-probably-not-using-f75c41ee4d96 Agile and Scrum Course – Definition of Done (DoD): https://agilemania.com/tutorial/definition-of-done-in-agile |
| Czemu służy ta lekcja | W produkcji gier bardzo łatwo przekroczyć moment, w którym można realistycznie i odpowiedzialnie zamknąć projekt. Zajęcia mają na celu zdefiniować klarowne kryteria ukończenia gry, odróżnić stan „feature complete” od „done”, pokazać narzędzia i metody weryfikacji ukończenia (np. DoD, MVP, playtesty, metryki jakości), omówić pułapki „chrome polish” i błędów percepcyjnych przy ocenie gotowości oraz wypracować procesy wspierające decyzje o endgame. |
Jak się przygotować
Prowadzący powinien
- przygotować przykłady kryteriów „done” z różnych projektów (AAA/indie),
- przygotować diagram pokazujący różne poziomy gotowości (feature complete → beta → release candidate → done),
- mieć narzędzia do wizualizacji (tablica/Miro).
Uczestnicy
- powinni znać swój scope projektu oraz aktualny backlog,
- być gotowi podać swoje propozycje kryteriów „done” (lista minimum 3),
Jaką wiedzę należy przekazać
Czym jest „skończona” gra?
- produkt, który realizuje swoją obietnicę wartości dla gracza,
- produkt, który spełnia definicję Done uzgodnioną z zespołem,
- produkt, który został zweryfikowany metrykami, feedbackiem i testami.
- „Feature complete” ≠ „Done”
Definition of Done (DoD)
- jasne kryteria jakościowe i ilościowe, np.:
- wszystkie planowane funkcje zrealizowane i zweryfikowane,
- krytyczne bugi zostały naprawione,
- akceptowalne metryki stabilności i UX,
- QA potwierdziło zgodność ze standardami.
- różnica między Definition of Ready vs. Definition of Done
Minimum Viable Product (MVP) i „wartość vs. funkcje”
- MVP jako punkt odniesienia dla definicji „Done”
- MVP ≠ finalna gra (ale może być produktową definicją ukończenia w danym kontekście)
Metryki decyzyjne
- playtest analytics (retencja, CR, czas sesji)
- stabilność buildów
- liczba krytycznych błędów
- feedback od beta testerów
- koszty utrzymania (czas, zasoby) vs. wartość dodana przez kolejne zmiany
Pułapki i biasy
- „chrome polish” – dopracowywanie detali zamiast wartości
- overfitting testów → testowanie pod własne założenia
- paraliż decyzyjny „jeszcze tylko 1 feedback”
Ćwiczenia praktyczne
Ćwiczenie A: Definicja Done dla projektu
Uczestnicy powinni:
- wypisać 5 kryteriów „Done” dla swojej gry,
- ustalić priorytet (obowiązkowe vs. nice-to-have),
- sprawdzić, które już spełniacie, a które zostają do zrobienia.
Cel: precyzyjna definicja „skończenia” gry, którą uczestnicy mogą przedstawić zespołowi.
Ćwiczenie B: Metryki i decyzje
Grupa dostaje prosty „release snapshot” (status builda, bug count, wyniki playtestów, feedback).
Zadanie:
- przeanalizować dane,
- ocenić, czy gra jest gotowa do przejścia do endgame,
- przedstawić krótkie uzasadnienie.
Cel: praktyczne zastosowanie kryteriów i metryk.
Warto zapamiętać
- Gra jest skończona wtedy, kiedy spełnia obietnicę wartości zgodnie z definicją zespołu.
- Definition of Done musi być jednoznaczna i mierzalna.
- Feature complete ≠ Done.
- Metryki, dane i feedback są ważniejsze niż subiektywne odczucie: „wygląda dobrze”.
- Decyzja o zakończeniu produkcji powinna być formalna i udokumentowana.
- Utrzymanie zbalansowanego balansu między jakością, zakresem i czasem to klucz do zdrowego procesu.