Budowanie nowego oprogramowania lub produktu traktujemy jak projekt, który dzielimy na zadania i okresy czasu, w których dane zadanie trzeba wykonać. Istnieją różne metodologie zarządzania projektem, które mają swoje plusy i minusy. W tym artykule dowiesz się co to takiego Scrum, na czym polega podejście zarządzania, dlaczego warto z niego korzystać i jak zacząć.


Scrum jest chętnie wykorzystywany do tworzenia produktów informatycznych, ale z sukcesem wychodzi poza świat IT i stosuje się go do wprowadzania nowych usług czy kampanii marketingowych. Jego główną zaletą jest prostota w użytkowaniu i skuteczność w doprowadzaniu projektu do końca. Scrum opiera się na dostarczaniu produktu w krótkich cyklach (sprintach), które są ograniczane czasowo (1-4 tygodnie). Dzięki temu uzyskujemy gwarancję, że wszyscy zainteresowani (klient i zespół pracujący nad tematem) wiedzą w którym momencie znajduje się projekt, jaki będzie następny krok i czego oczekiwać po ukończonym sprincie. Dodatkowym atutem jest konieczność ustalania definicji działania produktu (Definition of Done - DoD), co eliminuje ryzyko nieporozumień (Dziwne, u mnie działa…).


Role w Scrum


Zespół (Development Team) - odpowiedzialny za dostarczenie działającego produktu. Często składa się z ludzi wzajemnie uzupełniających się kompetencjami (np. programowanie, testowanie, analiza), ale nie mają formalnych ról (tester, analityk, programista). Nie istnieje też liderzy czy managerowie. Zespół jest mały (3-9 osób), samodzielnie oszacowuje i mierzy postęp.

Product Owner (PO) - posiada wizję produktu, którą przekształca w posegregowaną listę oczekiwań (Rejestr Produktowy - Product Backlog) i koncentruje się na ROI (maksymalizacji zysku z inwestycji). Stale analizuje rynek i reaguje na zmiany czy pojawiające się nowe potrzeby względem produktu.


Scrum Master (SM) - rozumie i tłumaczy zasady Scrum i upewnia się, że są stosowane. Wspiera zespół w stosowaniu Scrum poprzez obserwację i identyfikację przyczyn problemów w zespole ze Scrum. Nie narzuca rozwiązań, zadaje pytania, które pomagają Zespołowi odnaleźć własne.


Proces Scrum


  1. 1. Product Owner szereguje listę potrzeb w Rejestrze Produktu (Product Rejestr) w kolejności od najważniejszej do najmniej istotnej na podstawie potrzeb interesariuszy oraz sytuacji na rynku.
  2. 2. PO zarządza spotkanie nazywane Planowaniem Sprintu (Sprint Planning), podczas którego zespół ustala co i w jaki sposób dostarczy z listy Product Backlog. Zespół buduje Sprint Backlog.
  3. 3. Zespół codziennie spotyka się na 15 minut, aby zsynchronizować swoje działania. Nazywamy to Daily Scrum.
  4. 4. Po upływie czasu przeznaczonego na Sprint następuje spotkanie podsumowujące (Sprint Review), gdzie Zespół wraz z PO przedstawia co zostało stworzone w trakcie Sprintu i uzyskują informacje zwrotne na temat swojej pracy.
  5. 5. Zespół i PO w trakcie Retrospektywy Sprintu (Sprint Retrospective) zespół ustala w jaki sposób może pracować skuteczniej.
  6. 6. Po określonej liczbie sprintów klient otrzymuje gotowy i sprawny produkt.

Fundamenty Scrum


Skuteczność pracy w Scrum polega na bazowaniu na trzech filarach. Najważniejszy to Przejrzystość (Transparency). Umożliwia zorientować się co dzieje się w projekcie i nabrać pewności do deklarowanych wykonanych zadań (np. jeśli Zespół deklaruje, że funkcja skanowania kodu QR działa, to znaczy, że tak jest, bo bez tego nie można iść dalej według Spring Backlog i Product Backlog). Także realność realizacji planów i stawianych wymagań przez PO ma szansę być weryfikowana na bieżąco. Jeśli coś jest nie tak, wykaże to opóźnienie w realizacji Sprintów. Ta wiedza pozwala na Inspekcję (Inspect), czyli wyciągnięcie wniosków z popełnionych błędów i wdrożenie działań naprawczych. To z kolei wymusza Adaptację (Adapt) - reorganizację planów i dostosowywanie procesu czy produktu do rzeczywistości (np. zmiana zakresu, technologii czy sposobu).

 

Zasady pracy w Scrum są łatwe i czytelne. Niestety, jak każda nowość w zespole, może spotkać się z niechęcią przy pierwszym potknięciu. Należy wówczas przypominać, że praktyka czyni mistrza, a po skończonym projekcie w Scrum zestawić go z podobnym realizowanym w innej metodologii ze szczególnym naciskiem na komunikację z klientem i jego oczekiwania względem produktu a rzeczywistością po dostarczeniu projektu.