Sprint review

Sprint review
Polecane artykuły
Sprint Backlog produktu Metodyka SCRUM Planowanie sprintu Backlog sprintu Inicjowanie Projektu Kamień milowy Testowanie w projekcie Zarządzanie zleceniami wg PMBOK

Przegląd Sprintu (ang. Sprint Review Meeting) – to spotkanie zespołu Scrumowego oraz interesariuszy, które jest organizowane i odbywa się po zakończeniu każdego Sprintu. Jest to takie kluczowe zdarzenie, pewny mechanizm kontroli i oceny postępów w danym projekcie (Bukłacha E., 2017, s. 6). Podczas tego zebrania zespół Scrumowy pokazuje wszystkie zadania, które zostały ukończone i w jaki sposób zostały ukończone podczas Sprintu, także jeżeli jest to niezbędnym, zostaje dopasowany Rejestr Produktowy (ang. Product Backlog) – spis wszystkich produktów wymaganych i potrzebnych przez klienta (Schwaber K., 2005, s. 11). Zazwyczaj to spotkanie ma formę demonstracji nowych funkcji istniejącego produktu lub prezentacji przyrostu. Podczas Sprint Review Meeting projekt jest oceniany w stosunku do celu Sprintu ustalonego w trakcie spotkania Planowania Sprintu (Jędrzejewski K., Dąbrowski W., 2012, s. 16).

Cel Sprint Review

Celem Sprint Review jest określenie co zostało wyprodukowane w Sprincie oraz sprawdzenie jakości wyprodukowanego produktu, zidentyfikowanie ulepszeń, które są dodawane do Backlogu Produktu w trakcie Sprintu i priorytetowo ustalane przez Właściciela Produktu, a także uznanie czy zespół spełnił swoje zobowiązania dotyczące danego Sprintu. Bardzo istotnym jest to, że przegląd powinien odbywać się w zintegrowanym środowisku. Na podstawie współpracy uczestników spotkania mogą być wprowadzone pewne zmiany w Backlogu Produktu, także znaczącym i niezbędnym jest uzyskanie potrzebnej informacji zwrotnej między członkami zebrania w stosunku do przedstawionego przyrostu. (Kuchta D., Skowron D., 2011, s. 313)

Częstotliwość i czas trwania

{{#ev:youtube|JhzJKMTCq04|480|right|Przegląd sprintu (Sławomir Wawak)|frame}} Sprint Review Meeting odbywa się zawsze w końcu Sprintu i powinno wynosić maksymalnie cztery godziny dla czterotygodniowego Sprintu, ten termin jest proporcjonalny dla innych czasów Sprintu – przykładowo dla dwutygodniowego Sprintu czas trwania Przeglądu będzie wynosić dwie godziny (Kaczor K., 2018, s. 138), (Skomra A., Kuchta D., 2017, s. 7).

Uczestnicy

Uczestnikami przeglądu Sprintu przeważnie są Właściciel produktu (ang. Product Owner), zespół wytwórczy (ang. Development Team), Scrum Master, kierownictwo firmy, bezpośrednio klient (użytkownik końcowy stworzonego produktu lub usługi) oraz developerzy z innych projektów (M.Kieruzel, 2015, s. 489).

Przygotowanie do spotkania

Zespół powinien spędzić nie więcej niż godzinę, przygotowując się do Przeglądu Sprintu. Musi także być przygotowana infrastruktura do demonstracji Produktu, na przykład dla przedstawienia działającego oprogramowania każdy uczestnik spotkania musi mieć laptopa.

Agenda Sprint Review Meeting

• Demonstracja – zespół Deweloperski demonstruje Przyrost produktu potencjalnie możliwy do wysłania oraz wykorzystania przez klienta,
• Co jest zrobione? – właściciel produktu deklaruje (ogłasza) co zostało zrobione,
• Velocity – zespół Deweloperski mierzy velocity (prędkość) dla danego Sprintu,
• Feedback – Informacja zwrotna od interesariuszy oraz zainteresowanych osób, zamykanie Sprintu

Demonstracja

• Bezpośrednie przedstawienie Produktu dla uczestników
• Powinna się odbywać na podstawie zadań, które są opisane w Backlogu Produktu
• Zademonstrowane zadania muszą być całkiem wykonane, a nie "w połowie” wykonane,
• Właściciel produktu może zadeklarować jakie zadania uzna za zakończone.

Podczas demonstracji Zespół Deweloperski identyfikuje wszelkie niekompletne pozycje zaległości (ang. Backlog items).

Co jest zrobione?

• Powinno to zostać określone w Backlogu Refinement lub na spotkaniu Planowania Sprintu,
• Każdy z uczestników powinien dobrze rozumieć istotę Sprintu,
• Właściciel produktu ma ostatnie słowo i decyduje o tym, co dokładnie zostało zrobione.

Właściciel Produktu przenosi i / lub dzieli niekompletne zaległości na kolejny Sprint lub Backlog Produktu, jeśli nie jest to priorytet.

Velocity

• Na Spotkaniu Refleksji Backlogu (ang. Backlog Refinement meeting) zostały wyznaczone Punkty Opowieści (ang. Story points) dla każdego Przedmiotu Backlogu Produktu (ang. Product Backlog Item);
• Dla obliczenia prędkości dla bieżącego Sprintu trzeba zsumować wszystkie punkty z ukończonych funkcjonalności.

Na danym etapie ocenia się prędkość Sprintu oraz prawdopodobna data zakończenia Sprintu

Feedback

• Interesariusze mają możliwość przedstawienia swojej opinii na temat przyrostu,
• Wspólne rozumienie stanu produktu,
• Mogą być zidentyfikowane nowe funkcje i/lub zadania produktu;
• Te nowe zadania I wszystkie zmiany, które zostały omówione na Sprint Review przez uczestników spotkania muszą zostać dodane do Backlogu Produktu,
• Właściciel produktu zamyka Sprint i akceptuje dostarczoną funkcjonalność.

Przykładowe problemy, które zdarzają się podczas Sprint Review Meeting, mogą być następne:

1. Zespół nie zgadza się z tym, co pozostało wyznaczone przez Product Ownera jako "ukończone”,
2. Awarie oprogramowania,
3. Dostępna jest zła wersja systemu.

Po zakończeniu Sprint Review Meeting zostaje zaktualizowany i unowocześniony plan rozwoju Rejestru produktu (ang. Product Backlog). Zatem przed rozpoczęciem następnego planowania Sprintu odbywa się Retrospektywa Sprintu (ang. Sprint Retrospective) (Bukłaha E., 2013, s. 56).

Bibliografia

• Bukłaha E. (2013), Ocena sukcesu projektu na podstawie wytycznych metodyki Scrum, "Prace Naukowe Wyższej Szkoły Bankowej w Gdańsku”, nr 22 "Nowe koncepcje w zarządzaniu organizacją wobec wyzwań otoczenia”, s. 41-57.
• Bukłacha E. (2017). Project controlling in the adaptive perspective of project managementJournal of Modern Management Process, nr 1 Współczesne instrumenty zarządzania projektami I procesami, SCH Warsaw School of Economics, s. 8-17.
• Chrapko M. (2012), Scrum. O zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice, s. 48-50
• Ćwiklicki M. (2010), Scrum – nowa metoda zarządzania złożonymi projektami, "Przegląd Organizacji”, nr 4, 2010, s. 16-19.
• James M., Walter L., Scrum Reference Card, 2010 http://scrumreferencecard.com/ScrumReferenceCard.pdf
• Jędrzejewski K., Dąbrowski W. (2012), Zarządzanie Projektami informatycznymi w metodyce Scrum, Politechnika Warszawska, s. 16
• Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach Agile, Wydanie II, Wydawnictwo naukowe PWN, Warszawa, s. 138
• Kieruzel M. (2015), Integracja metodyki PRINCE2 oraz Scrum przy realizacji informatycznych projektów wytwarzania oprogramowania w e-administracji, "Zeszyty Naukowe Uniwersytetu Szczecińskiego. Ekonomiczne Problemy Usług”, nr 117 "Wirtualizacja gospodarki – spojrzenie interdyscyplinarne”, s. 487-496.
• Kuchta D., Skowron D. (2011), Zastosowanie modelu Time-Driven Activity-Based Costing w metodyce Scrum, "Studia Ekonomiczne”, Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, nr 96. Modelowanie preferencji a ryzyko`11, s. 313
• Schwaber K. (2004), Agile Project Management with Scrum, Microsoft Press, ISBN 978-0-7356-1993-7.
• Schwaber K. (2005), Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa, s. 11.
• Skomra A., Kuchta D. (2017), Model dojrzałości dla podejścia Scrum,” Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach”, ISSN 2083-8611, Nr 340, s. 7.
• Sutherland J.(2004, retrieved 2008), Agile Development: Lessons learned from the first Scrum.
• Sutherland J., Schwaber K. (2013, retrieved 2017), The Scrum guide, https://www.scrumguides.org/
• Sutherland J.(2015), Scrum Czyli jak robić dwa razy więcej dwa razy szybciej, Wydawnictwo naukowe PWN, Warszawa.

Autor: Inga Rasniuk