Z czym kojarzy Ci się DEMO? Mnie osobiście z czasami, kiedy kupowało się CD Action tylko po to, żeby dorwać wersję demonstracyjną jakiejś gry.
Zaczynamy od definicji Sprint Review
Celem Sprint Review jest inspekcja efektów pracy wykonanej w Sprincie oraz wskazanie przyszłych zmian. Scrum Team prezentuje rezultaty swojej pracy kluczowym interesariuszom, omawiane są także postępy w dążeniu do Celu Produktu.
2020-Scrum-Guide-Polish.pdf
Jest to kolejne spotkanie, które odbywa się na sam koniec sprintu, na którym demonstrujemy wszystkie zadania, jakie udało nam się ukończyć w trakcie danej iteracji.
Komu je prezentujemy? Można tu śmiało powiedzieć, że wszystkim zainteresowanym, ale przede wszystkim Product Ownerowi, który zarządza całym procesem. Osobiście miałem czasami sytuację, w której prezentowałem zmiany wdrożone przez mój zespół nawet czterdziestu osobom na raz.
No właśnie ja prezentowałem – to jest ważna kwestia.
Sprint Review jest spotkaniem, na którym prezenterem najczęściej jest tester. Dzieje się tak, ponieważ tester zna najlepiej pełen zakres zmian, jakie mieliśmy do zrobienia w danym Sprincie. Tester jest osobą, która sprawdzała zmiany wrzucone przez wszystkich devów. Zatem może o nich najwięcej powiedzieć.
Jak przygotować się do prowadzenia Sprint Review?
No dobra skoro już się trochę przeraziłeś, bo „Ty będziesz prezentował”, to podpowiem Ci, co może pomóc w dobrym przeprowadzeniu spotkania.
Jedyną rzeczą jest… PRZYGOTOWANIE SIĘ! Ja to robię tak:
- Dzień przed spotkaniem wystawiam sobie finalną wersję aplikacji, którą będę demonstrował.
- Planuję swoją prezentację nowych funkcjonalności, dlatego przeklikuję aplikację, żeby nie było sytuacji na spotkaniu, że to, co pokazuję, z jakiegoś powodu nie działa. Jeśli coś nie działa w zaplanowanej ścieżce, to znajduję inną ścieżkę, by pokazać funkcjonalność. Jednocześnie zgłaszam błąd i uświadamiam zespół, że istnieje taki problem. Jeżeli chcemy zaryzykować i zmiana jest prosta do wprowadzenia, to zawsze możemy spróbować jeszcze dopchnąć zmianę z poprawką kolanem przed demo ;). Jednakże trzeba pamiętać, że czasami może być to niemożliwe i wtedy zwyczajnie trzeba poinformować o błędzie również Product Ownera.
- Przygotowuję sobie listę tego, co mam pokazać i na prezentacji pokazuję zgodnie z tą listą.
- Pamiętaj, że ludzie lubią zadawać pytania! Ja nie lubię, gdy jestem wybijany z toku prezentacji pytaniami. Dlatego na początku spotkania proszę o niezadawanie pytań w momencie prezentacji, tylko dopiero jak skończę pokazywać daną funkcjonalność.
Ważne! Pamiętaj o czasie na pytania pomiędzy demonstracją kolejnych funkcjonalności :).
Tak przygotowany w wyznaczonym dniu o wyznaczonej godzinie przedstawiam zebranym nowe funkcjonalności aplikacji.
Co firma, to inne podejście do Scruma
Chciałbym się odnieść do dwóch kwestii związanych z tym spotkaniem, które zgodnie z definicją, powinny mieć miejsce, a nie zawsze mają.
Po pierwsze „Omawianie postępów w dążeniu do Celu projektu”, szczerze powiedziawszy, nie spotkałem się z tym chyba nigdy podczas tego spotkania. Chociaż może to głównie wynikać ze specyfiki projektów, w jakich pracowałem lub też podejścia do samego Scruma, który jest niewdzięcznym tematem do pisania artykułów, ponieważ co firma, to inne podejście do niego.
Drugą kwestią jest „wskazanie przyszłych zmian”, faktycznie czasami się zdarza, przy czym w moim przypadku na 8 projektów, które miałem przyjemność testować, tylko w jednym faktycznie podczas Sprint Review były omawiane przyszłe zmiany, jakie będziemy robili wspólnie z zespołem. Przeważnie tego typu rzeczy robiliśmy na osobnym spotkaniu (Planning), po którym jak już mieliśmy estymaty i to, co nam się zmieści lub nie do sprintu to jedna osoba podsyłała notkę ze spotkania do PO, który potem decydował na tej podstawie o priorytetach zadań w backlogu i co chcę, żeby zespół wziął do Sprintu.
Podumowanie
Ten artykuł jest jednym z cyklu wpisów na temat spotkań w Scrumie. Kiedyś napisałem wpis o pracy testera w Scrumie, opisałem w nim, jak dzień po dniu wygląda praca testera w trakcie Sprintu dwutygodniowego. Znajdziesz w nim informacje na temat tego, jak cały sprint wygląda z punktu widzenia testera i jego obowiązków. Planing z kolei omawiałem przy okazji artykułu o estymacji czasu pracy.
