Przegląd Scrum

Przegląd Scrum

W Scrumie menedżer projektu nazywa się Scrum Master, a zespół projektowy nazywa się zespołem Scrum. Istnieje właściciel produktu, który priorytaryzuje funkcje i wymagania do opracowania na liście produktu.

Metodologia Scrum wykorzystuje sprinty do dostarczania małych przyrostów pracy i zbierania opinii od klientów.

Istnieją trzy (3) filary Scrum:

SCRUMwykorzystuje podejście empiryczne (czasem nazywane empiryzmem), aby dostosować się do stale zmieniających się potrzeb klientów. Empiryzm to praktyka podejmowania decyzji opartych na rzeczywistym doświadczeniu. Podejście empiryczne oznacza pracę w sposób oparty na faktach, doświadczeniu i dowodach — szczególnie tam, gdzie postępy opierają się na obserwacji rzeczywistości, a nie na szczegółowych planach przed rozpoczęciem, opartych na obszernych początkowych wymaganiach.

Krótko mówiąc, uczymy się i poprawiamy się na podstawie wcześniejszych błędów i doświadczeń. Trzy filary Scrum, które wspierają kontrolę procesu empirycznego w każdej implementacji, to: Przejrzystość, Inspekcja i Adapta, jak pokazano na poniższym diagramie:

• Przejrzystość — Wspólna język i standardy zapewniające spójność i wspólną rozumienie.
• Inspekcja — Częste przeglądy postępów Scrum i dostarczonych wyników w celu uzyskania opinii. Ważne jest, aby nie ukrywać postępów projektu.
• Adapta — Łatwo włączać otrzymane opinie i rozwiązywać problemy, gdy one pojawiają się.

Składniki procesu Scrum

Poniższy framework Scrumjest bardzo prosty. Określa tylko kilka ogólnych wytycznych, razem z małą liczbą zasad, role, artefakty, oraz zdarzenia. Jednak każdy z tych elementów jest ważny, spełnia konkretną funkcję i jest kluczowy do skutecznego wykorzystania frameworku.

Główne składniki frameworku Scrum to:

• Role Scrum: Scrum Master, Właściciel produktu, oraz Zespół Scrum
• Artefakty: Backlog sprintu, Backlog produktu, Wykres spalania, logi, itd.
• Zdarzenia Scrum: Planowanie sprintu, Przegląd sprintu, Codzienny Scrum, Retrospektywa sprintu, itd.
• Sprinty

Poniższy diagram ilustruje kluczowe elementy frameworku SCRUM. Ten proces został zaimplementowany w Narzędzie do oprogramowania Agile — Kanwa procesu Scrum.

Role w Scrum

Kiedy organizacja decyduje się na przyjęcie Scrumu, jednym z pierwszych aspektów do zrozumienia jest różnica między rolami Scrum a tradycyjnymi rolami w realizacji projektów. Choć Scrum ma tylko trzy główne role, nie są one automatycznie zgodne z tytułami, z którymi większość z nas jest zapoznana. Zaczniemy od krótkiego wyjaśnienia każdej z nich:

Właściciel produktu

Właściciel produktu to rola Scrum odpowiedzialna za reprezentowanie społeczności biznesowej lub użytkowników oraz współpracę z grupami użytkowników w celu ustalenia, które funkcje zostaną uwzględnione w wydaniach produktu. Głównymi obowiązkami Właściciela produktu są:

• Określanie kierunku i strategii produktu lub usługi, w tym celów krótko- i długoterminowych;
• Dostarczanie lub pozyskiwanie wiedzy na temat produktu lub usługi;
• Pomaganie zespołowi rozwojowemu zrozumieć i zinterpretować potrzeby klientów;
• Zbieranie, priorytetyzacja i zarządzanie wymaganiami dla produktu lub usługi;
• Podejmowanie odpowiedzialności za wszystkie zadania związane z budżetem produktu lub usługi, w tym jego rentowność;
• Określanie dat wydania funkcji produktu lub usługi;
• Odpowiadanie na pytania i podejmowanie decyzji codziennie wraz z zespołem rozwojowym;
• Zaakceptowanie lub odrzucenie ukończonych funkcji związanych z Sprintem;
• Prezentowanie kluczowych wyników pracy zespołu rozwojowego na końcu każdego Sprintu;
• Odpowiedzialność za Backlog Produktu.

Scrum Master

Scrum Master jest koordynatorem zespołu agilnego. Scrum to metoda, która pozwala zespołom na samoorganizację i szybkie zmiany zgodnie z zasadami agilnymi. Scrum Master zarządza procesem wymiany informacji. Głównymi obowiązkami Scrum Mastera są:

• Działanie jako trenera, aby pomóc zespołowi przestrzegać wartości i praktyk Scrum;
• Pomaganie w usuwaniu przeszkód i ochrona zespołu przed zewnętrznym干预;
• Zapewnianie dobrego współpracy między zespołem a stakeholderami;
• Promowanie zdrowego rozsądku wewnątrz zespołu;
• Chronienie zespołu przed干预 organizacyjnym.

Zespół Scrum

Zespół Scrum (znany również jako Zespół Rozwojowy) składa się z 3 do 9 osób, które wspólnie posiadają wszystkie umiejętności techniczne potrzebne do dostarczenia produktu lub usługi. Są bezpośrednio wspierane przez Scrum Mastera, ale nie są bezpośrednio zarządzane. Muszą być samoorganizowane, elastyczne i odpowiedzialne na tyle, by wykonać wszystkie wymagane zadania.

Zespół Rozwojowy jest odpowiedzialny za dostarczanie potencjalnie gotowych do wysyłki fragmentów produktu w każdym Sprintie – od analizy, projektowania, programowania, testowania po pisanie dokumentacji technicznej. Kluczowe cechy zespołu Scrum to:

• Zespół musi być samoorganizowany. Wszyscy członkowie zespołu muszą zarządzać własnymi wysiłkami w celu ukończenia przypisanych zadań. W agilnym Scrumie nie ma lidera zespołu ani menedżera linii. Każdy musi być wystarczająco zaangażowany, by wykonywać swoje zadania i przyczyniać się do sukcesu zespołu. Jeśli jeden się nie uda, wszyscy się nie uda.
• Zespół musi być wieloosobowy. Wszyscy członkowie zespołu muszą posiadać wiedzę i umiejętności niezbędne do dostarczenia kompletnego, gotowego do użycia produktu lub usługi. Eksperci mogą być wykorzystywani, gdy to konieczne, ale tylko jako trenerzy, którzy przekazują wiedzę zespołowi i wypełniają określone luki.
• Product Owner wymaga wizji biznesowej. Product Owner reprezentuje głos klienta i musi przekazywać ich potrzeby Scrum Masterowi i zespołowi rozwojowemu. Jest to zazwyczaj stanowisko pełnoetatowe.
• Scrum Master nie jest menedżerem linii. Udzielają wsparcia potrzebnego zespołowi rozwojowemu i pomagają usuwać wszelkie przeszkody, z którymi się spotykają.

Backlog Produktu

Jest to uporządkowana lista wszystkich zadań do wykonania w projekcie. Prezentowana jest w formie historii, zwanych powszechnie historiami użytkownika.

Historie użytkownika — Różne reprezentacje sposobu, w jaki użytkownicy współdziałają z wynikami projektu (produkt, usługa lub wynik). Poprzez historie użytkownika zespół identyfikuje funkcje i możliwości wymagane dla wyników projektu.

Dlatego Backlog Produktu zawiera uporządkowane historie użytkownika (funkcje i możliwości) dla produktu/usługi/wyniku. Product Owner jest odpowiedzialny za priorytetyzowanie backlogu.

Uwaga: Nie musisz tworzyć wszystkich historii dla całego projektu przed rozpoczęciem pracy (to jedna z zalet podejścia agilnego). Zacznij od historii, które znasz, a w miarę nabywania wiedzy dodawaj do listy zadań i przeprowadzaj ponowne priorytaryzowanie, gdy będzie to konieczne.

Planowanie Sprintu

W przeciwieństwie do podejścia kaskadowego, zespoły agilne nie planują wszystkiego na wstępie. Tutaj zespół planuje trochę: co jest potrzebne w bieżącym Sprintie (Sprinty trwają zazwyczaj od 2 do 4 tygodni), realizuje to, uczy się na tym i ponownie planuje następny Sprint.

Zespół Scrum przegląda listę produktu i wybiera liczbę historii użytkownika, które może zrealizować w czasie Sprintu. Wybrane historie użytkownika stają się listą Sprintu. Lista Sprintu reprezentuje cel Sprintu.

Zdefiniowano również Kryteria Zakończenia. Kryteria Zakończenia można traktować jako kryteria akceptacji dla elementów listy zadań.

Planuj tylko pracę, która mieści się w pojemności zespołu – to znaczy pracę, którą zespół może rzeczywiście zrealizować w każdym Sprintie.

Codzienny spotkanie Scrum (Codzienny stand-up)

Zespół używa tego spotkania, by składać mikroobietnice wobec siebie, identyfikować problemy i zapewnić płynny przepływ pracy Sprintu w obrębie zespołu. Zazwyczaj trwa ono 15 minut. Zespół odpowiada na następujące pytania:

• Co zrealizowałem od ostatniego spotkania Scrum?
• Jaki jest mój plan na dziś? Co mam zamiar zrealizować od teraz do następnego spotkania Scrum?
• Czy są jakieś przeszkody (problemy, kwestie lub ryzyka), które mnie blokują?

Pamiętaj, że to spotkanie nie jest spotkaniem statusowym – nie ma na celu rozwiązywania problemów, ale poznawania ich (jeśli istnieją). Jeśli potrzebne jest spotkanie w celu rozwiązania problemów, zorganizuj je oddzielnie.

Spotkanie przeglądu Sprintu

Na końcu każdego Sprintu zespół prezentuje wszystkie zrealizowane elementy pracy. To spotkanie służy do odbierania opinii od stakeholderów projektu oraz wszelkich żądań zmian.

Ważne jest, by zaznaczyć, że elementy pracy, które nie są w 100% ukończone zgodnie z Kryteriami Zakończenia ustalonymi podczas planowania, nie będą prezentowane, ponieważ nie są „zakończone”.

Spotkanie retrospektywne Sprintu

Odbędzie się po przeglądzie Sprintu. Celem jest pomoc zespołowi w nauce z Sprintu. Proces skupia się na ciągłym doskonaleniu, a nie na obwinianiu zespołu, jeśli coś poszło nie tak podczas Sprintu.

Zespół analizuje, jak stać się bardziej skutecznym, i identyfikuje inne obszary do poprawy.

Prowadzący Scrum ocenia priorytet każdego elementu poprawy, a następnie zespół wybiera odpowiednią liczbę elementów poprawy do wdrożenia w kolejnymSprint.