Wszystko, co powinieneś wiedzieć o SCRUM – cz. II

W poprzedniej części artykułu o scrumie dowiedzieliśmy się czym właściwie jest scrum, jaka jest jego historia oraz jakie są wyznawane w nim wartości – pora więc na to abyśmy dowiedzieli się co tak właściwie oznaczają niektóre pojęcia z tej metodyki.  To bardzo ważne – bo tylko rozumiejąc język scruma jesteśmy w stanie w pełni zrozumieć jego istotę i sposób działania. Jest to swego rodzaju esperanto – w praktycznie każdym zespole używane są te same stwierdzenia, które określają elementy oraz role. Nazwy te najczęściej są w języku angielskim, aczkolwiek, w niektórych zespołach w naszym kraju używane są spolszczone nazwy. W poniższym zestawieniu przedstawimy Wam zbiór wybranych, najważniejszych pojęć wraz z krótkim opisem – to zestawienie może okazać się dla Was niezwykle pomocne, jeżeli jesteście nowi w zespole scrumowym i cały czas obce są Wam Burndown Charty oraz Sprinty. Nie ma na co czekać, zaczynajmy!

Agile (metodyki zwinne) – podstawa metodyki scrum! Jest to podejście iteracyjne, w którym zespół zajmuje się rozwiązywaniem problemu kawałek po kawałku – od początku aż do końca projektu. Opiera się ona na zbiorze zasad oraz reguł, które zostały ujęte w „Agile Manifesto” w roku 2001.

Rys.  1 Porównanie tradycyjnego podejścia z podejściem zwinnym w metodologii scrum.

Burndown chart (wykres spalania) – wykres, na którym pokazywana jest pozostała praca względem czasu. Na osi Y pokazana jest ilośc pracy, która pozostała do zakończenia projektu, natomiast czas przedstawiony jest na osi X. Narzędzie to wykorzystuje się do pokazywania postępów poczynionych podczas poszczególnych iteracji, można również odczytać z niego szacowany czas zakończenia projektu.

Chicken (kurczak) – metafora określająca osoby, które biorą udział w procesie tworzenia produktu, ale nie wytwarzają go w fizycznym sensie (tj. Pig (świń)). Najczęściej opisuje osoby z poza zespołu scrumowego. Termin raczej nie jest używany  w oficjalnym scrumowym języku (gdyż mógł zostać odebrany obraźliwie) ale niekiedy spotykany w zespołach. Wziął się ze starego żartu „In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed” (Podczas śniadania z szynką i jajkiem… Kurczak jest wmieszany, ale to świnia jest zaangażowana).

Daily scrum meeting (codzienne spotkania scrumowe) – spotkania, które odbywają się codziennie i trwają maksymalnie piętnaście minut. Nie wchodzimy w nich w szczegóły, odpowiadamy tylko na trzy pytania:

– Co zrobiłem od ostatniego spotkania?

– Co zrobię do następnego spotkania?

– Czy jest coś, co powstrzymuje mnie od pracowania z maksymalną efektywnością?

Development team (zespół programistów) – samoorganizująca się grupa ludzi, którzy są odpowiedzialni za całą prace potrzebną do stworzenia działającego produktu. Jedna z trzech ról zespołów scrumowych.

Epic (epickia [historia użytkownika]) – duża historia użytkownika, która może zając całe wdrożenie lub kilka kolejnych wdrożeń. W swoim czasie powinny być rozdzielane na mniejsze histore użytkowników.

Ideal day (idealny dzień) – jednostka czasu używana do opisu czasochłonności danych punktów z listy produktów do wykonania. Przedstawia on idealny dzień pracy, w którym nie było by żadnych zakłóceń, a wszystkie potrzebne surowce byłyby dostępne od razu.

Ideal hour (idealna godzina) – jednostka czasu jw., tylko w odniesieniu do jednej godziny.

Pig (świnia) – przeciwieństwo do kurczaka, osoby, które bezpośrednio pracują nad rozwojem projektu. Obecnie termin nie jest uwzględniony w oficjalnej terminologii scruma, gdyż przez niektórych może zostać uznany jako obraźliwy. Jego geneza tłumaczona jest żartem „In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed” (Podczas śniadania z szynką i jajkiem… Kurczak jest wmieszany, ale to świnia jest zaangażowana).

Product Backlog (lub backlog) (Rejestr Produktów) – zbiór wymagań klienta odnośnie jednego produktu oraz zbiór wymagań zespołu technicznego. Zadaniem Właściciela produktu jest ustalanie ważności poszczególnych elementów rejestru produktu. Podczas sprintu zespół wybiera, którymi elementami z rejestru chce się zająć – tym samym usuwając je z rejestru.

Product Backlog Item (PBI) (Element Rejestru Produktów) – oznacza pojedynczy produkt zawarty w rejestrze produktu, który jest na tyle mały, że może być wykonany w jednym Sprincie. Elementy maja możliwość rozłączenia na jedno lub więcej zadań do wykonania przez zespół.

Product Backlog Item Effort (Wysiłek Elementu Rejestru Produktów) – szacowany czas potrzebny na ukończenie danego produktu, mierzony najczęściej w dniach lub godzinach idealnych. Są to niedokładne założenia, nie należy ich mylić z dokładnymi godzinami potrzebnymi do ukończenia projektu.

Product Owner (Właściciel Produktu) – jest to osoba, która odpowiada za interesy klienta w procesie produkcji oraz ustalaniu kolejności realizowania elementów z rejestru. Ta osoba musi być zaangażowana w prace oraz działanie zespołu , zwłaszcza podczas planowania sprintu i jego przeglądu na koniec. Warto również podkreślić, że właściciel produktu nie jest odpowiedzialny za zarządzanie developerami, ma on służyć jako głos klienta kontaktując się ze Scrum Masterem. Musi także podejmować ważne decyzje podczas planowania – to on odpowiada za kolejność wprowadzania zmian w projekcie.

Scrum Master (raczej nie tłumaczony ;-)) – scrum master jest swoistym buforem między zespołem deweloperów oraz właścicielem produktu. Współpracuje z jednym i drugim, wspiera ich w działaniach, pomagając im rozwiać wątpliwości i rozwiązując problemy w komunikacji między nimi. Do jego obowiązków należy również dbanie o produktywność zespołu i motywowanie ich do szybszego i lepszego osiągania zamierzonych celów. Ponadto jego rolą jest również informowanie o postępie prac nad produktem i pilnowanie aby wszystkie zmiany były widoczne dla zainteresowanych.

Sprint – pojedyncza iteracja mająca za zadanie dodanie działającej funkcjonalności do produktu. Czas iteracji przyjmowany jest zazwyczaj na dwa tygodnie, aczkolwiek jego długość może być modyfikowana w zależności od tego nad jakim projektem obecnie pracujemy i jaka jest jego złożoność. U podstaw każdego sprintu leży spotkanie pierwszego dnia, podczas którego członkowie z zespołu wybierają swoje zadania. W trakcie sprintu organizowane są poranne piętnastominutowe spotkania, w czasie których prezentowane są wyniki z dnia poprzedniego. Na sam koniec sprintu przewidziany jest Sprint Review (przegląd sprintu), podczas którego prezentowane są wyniki ostatniej, świeżo zakończonej iteracji. Ważne jest aby podczas sprintu zespół mógł skupiać się tylko na konkretnym obranym celu – tylko dzięki temu będzie możliwe dotrzymanie terminów ustalonych podczas spotkań.

Sprint backlog (rejestr sprintu) – podobnie jak w rejestrze produktu znajdują się tutaj zadania do wykonania w czasie trwania sprintu, wraz z ilością czasu potrzebnego na wykonanie ich.

Rys.  2 Przykładowy Rejestr Sprintu

Sprint Goals (Cele sprintu) – Cele sprintu to założenia wypracowane przez właściciela produktu i zespół developerów. Powinny być dokładne i mierzalne, tak aby można było stwierdzić czy zostały osiągnięte. Cele powinny być definiowane tak, aby na koniec każdego sprintu, poczynając od pierwszego, można było przedstawić produkt chociażby z minimalną funkcjonalnością.

Sprint Retrospective (Retrospektywa Sprintu) – jest to spotkanie, które odbywa się za każdym razem na zakończenie obecnego sprintu. Zespół wraz ze scrum Masterem prowadzą dyskusję na temat tego co poszło dobrze podczas obecnego sprintu, oraz co należy poprawić w czasie następnego sprintu.

Velocity (prędkość) – jest to wskaźnik, dzięki któremu jesteśmy w stanie ocenić jak dużo pracy jest w stanie wykonać zespół w czasie jednego sprintu. Zazwyczaj jest szacowany na podstawie poprzednich sprintów. Wykorzystywany jest do przewidywania daty zakończenia projektu oraz odnośnie zakończenia poszczególnych elementów z rejestru elementów.

Test Driven Development (TDD) – nie jest to ściśle scrumowe pojęcie, ale bardzo często jest wykorzystywane w tej metodologii. W TDD na samym początku tworzymy testy, które dopiero później ma przejść napisany przez nas kod. Jeżeli dana funkcjonalność przejdzie wszystkie testy automatyczne, wtedy poddajemy kod refaktoryzacji aby stworzyć kod bardziej optymalny. Zadaniem tej metody jest zmuszenie nas do przemyślenia modelu naszej aplikacji jeszcze przed napisaniem pierwszej linijki kodu, tworząc czysty kod, który zawsze działa.

Rys.  3 Schemat metody TDD

User story (historia użytkownika) – jest to pewien format wyrażania wymagań biznesowych w relacjach klient – właściciel produktu. Są tworzone po to aby w łatwy sposób komunikować ze sobą ludzi, którzy mają technologiczną wiedzę oraz osoby, której tej wiedzy nie posiadają. Rejestr produktu składa się właśnie z historii użytkowników, najprościej można je określić jako wymagania klienta odnośnie produktu. Typowa struktura wygląda tak:

„Jako <rola użytkownika> pragnę osiągnąć <cel> abym mógł <korzyść>”.

Postaraliśmy się wymienić wszystkie najważniejsze pojęcia z zakresu metodologii Scrum, dzięki nim każdemu początkującemu członkowi zespołu będzie się łatwiej odnaleźć i dogadać ze współpracownikami. Teraz skoro wiemy już czym jest scrum i jaki jest jego słownik łatwiej będzie nam się odnaleźć w tej nowej zwinnej metodologii. W następnym artykule spróbujemy przedstawić Wam punkt widzenia osób pracujących w tej metodologii, dzięki temu będziecie mogli zdecydować czy jest sens wprowadzać takie rozwiązanie w Waszym zespole. Do zobaczenia w następnym artykule!

 

Marek Makuch

IT-Leaders.pl to pierwsza na rynku platforma łącząca Specjalistów IT bezpośrednio z pracodawcami. Anonimowy, techniczny profil i konkretnie określone oczekiwania finansowe to tylko niektóre z cech wyróżniających platformę. Zarejestruj się i zobacz jak Cię widzi pracodawca.

You may also like...