Co to jest SCRUM?

Co to jest SCRUM? W jaki sposób pracuje się w SCRUM-e? Jak to funkcjonuje i dlaczego akurat to zostało stworzone w taki, a nie inny sposób? Dzisiaj właśnie o tym opowiem. Serdecznie zapraszam do lektury.

Tekst o tym jak zastosować metodyki zwinne jest dla ludzi z IT ale nie tylko… Bo podejście zwinne da się zastosować praktycznie wszędzie. Tylko trzeba wiedzieć, w jaki sposób to zrobić.

Będę opowiadał jak SCRUM funkcjonuje, jak sobie można zorganizować pracę, w taki sposób, żeby dostarczać projekty… i bardzo ważna rzecz – dlaczego to jest tak skonstruowane, a nie inaczej.

SCRUM – Jak to działa?

SCRUM powstał jako metoda produktowa dostarczania produktów IT. To jest bardzo ważne przy każdej metodzie, aby sobie zadać pytanie „Skąd ona się wzięła i w jaki sposób została wymyślona”. Dzięki temu można prześledzić co Ci ludzie mieli na myśli i dlaczego zorganizowali to w taki sposób.

Wyobraź sobie, że jesteś członkiem zespołu projektowego. Macie wytworzyć jakiś konkretny produkt np. stronę internetową. Jak to działa?

Mamy tzw. Product Ownera – to jest osoba w organizacji, która zna produkt, który mamy wytworzyć. Odpowiada za niego i jest w stanie powiedzieć na czym mu bardziej zależy i mniej więcej jaka jest wizja produktu, który ma powstać. Czyli w naszym przypadku osoba ta mówi nam jakie ma wymagania odnośnie strony strony internetowej, oraz zbiera od całej organizacji ich oczekiwania i wymagania. Po to, żeby ułożyć tzw. Product Backlog.

Product Backlog – to lista elementów, które chcielibyśmy widzieć w naszym produkcie, ułożona od najważniejszych do najmniej istotnych. To w jaki sposób ustalana jest ta ważność decyduje Product Owner. W każdym projekcie będzie to wyglądało inaczej. Nie ma jednej uniwersalnej metody, zasada jest taka, że układamy od elementów produktu, które dają nam największą wartość. W przypadku strony internetowej może to być np. strona główna, formularz kontaktowy, strona z ofertą itd. Lista ta może mieć nawet kilkaset elementów. Pilnujemy, aby ułożyć je od najważniejszych do mniej ważnych.

Kolejny krok – ktoś musi wykonać, to co wymyśliliśmy. Tutaj pojawia się Zespół (Product Owner też jest częścią zespołu). Zespół odpowiada za to, żeby wszystkie pomysły przełożyć później na konkretny produkt. Zespół spotyka się na tzw. Spotkaniu planowania sprintu (sprint planning meeting) i z listy elementów, które chcemy mieć na stronie wybierają ich tak dużo, ile uważają, że są w stanie zrobić w ciągu kolejnego cyklu pracy. To co jest fajne w tym sposobie pracy – Product Owner wie, co jest ważniejsze, a co mniej i nikt nie poważa jego priorytetów. Natomiast Zespół wie ile z tego jest w stanie zrealizować. Ten częsty problem, który się pojawia w pracy „..a to jeszcze to zrobisz, na pewno gdzieś to upchniesz”, a Ty czujesz, że Ci się nie zmieści w kalendarzu i później praca się wysypuje. Tutaj rozwiązanie jest proste – to Ty bierzesz na siebie tyle ile jesteś w stanie dostarczyć.

Co nam powstaje? Powstaje nam tak zwany Sprint Backlog. Z całego Backlogu wszystkich rzeczy, które byśmy chcieli wybieramy te, które dostarczymy w ramach danego Sprintu. Dochodzimy do kluczowego pytania „Czym jest Sprint?”

Sprint to jest czas jaki ustalamy sobie na wykonanie naszych zadań. Według SCRUM Guide`a to jest od 1 do 4 tygodni. Umawiamy się, że nasze Sprinty miały stałą długość i nie zmieniamy tego. Praca w Sprintach stałej długości jest o tyle ważna, że jeżeli pracujemy w stałych cyklach – eliminujesz zmienne. Jest łatwiej nauczyć się lepiej planować, dostarczać i mieć stałe postępy na dobrym poziomie. W przypadku strony internetowej tygodniowy Sprint jest całkiem sensowny, bo w ciągu tygodnia jesteśmy stosunkowo dużo w stanie zrobić, sprawdzić co wykonaliśmy i wyciągnąć wnioski.

Na tym etapie pojawiają się nam zadania. Ze Sprint Backlogu, czyli opisane funkcjonalności jakie byśmy chcieli mieć na stronie przekładamy na konkretne zadania, które zespół wykonuje.

To co jest ważne – co 24 godziny pojawia się nam Daily Standup. Daily Standup to spotkanie na którym zespół na stojąco sprawdza jaki został zrobiony postęp, jaki jest plan, nad czym pracujemy, na jakie problemy napotkaliśmy, żeby móc wrócić do zadań i popychać robotę do przodu. (Spotkania są organizowane na stojąco, żeby się towarzystwo za bardzo nie rozsiadało, a spotkanie poszło szybko i sprawnie ;))

Jest to bardzo istotna rzecz, która przyspiesza pracę i służy szybkiemu rozwiązywaniu napotkanych problemów, aby nie hamowały one pracy.

Jest jeszcze jedna osoba – Scrum Master. Uważam, że to jedna z najlepszych „rzeczy” jakie wymyślono w SCRUMIE. W każdym środowisku potrzebny jest ktoś, kto będzie pilnował zasad i ludzi, aby pracowali w pewien, konkretny sposób, a nie uciekali do tych sposobów, które znają, są dla nich wygodniejsze i łatwiejsze. Scrum Master czuwa nad tym, żeby Zespół przestrzegał zasad. Zasad co do Backlogu, planowania Sprintu, Daily Standupów. Jego odpowiedzialnością jest wspierać Zespół w taki sposób, żeby nauczył się pracować wg. nowej metody.

Po tym jak skończymy sobie nasz Sprint, mamy jakieś ukończone produkty. Ukończona praca – z której powstaje nam produkt. Założeniem Scrum`a w IT jest to, że co Sprint dostarczamy coś, co można oddać klientowi i użyć. W przypadku naszej strony internetowej założenie byłoby np. takie, że mamy już stronę główną, formularz kontaktowy i sekcję z ofertami, którą możemy oddać klientowi, a on może jej zacząć już używać. W kolejnym Sprincie dorobimy pozostałe rzeczy z Backloga.

Dzieją się dwie ważne rzeczy na końcu. Pierwsza z nich to Przegląd. Robimy spotkanie na którym robimy przegląd naszego produktu. Może się na nim pojawić Product Owner, Zespół, ludzie z zewnątrz, którzy mogą być klientami ( nie zawsze Product Owner jest klientem). Na spotkaniu wszyscy sprawdzają co się podoba, co nie, co można zmienić, co dodać, co jest niepotrzebne itd.

To powoduje, że pojawia się nam feedback do Backlogu. Product Owner zarządza tym, co ze zgłoszonych „rzeczy” jest ważniejsze, a co mniej. I prawie zaczynamy kolejny Sprint… Czemu prawie? Bo wg. mnie to sednem całego przedsięwzięcia jest jeszcze jedna rzecz, z którą daje ciała większość Zespołów. Jest to Retrospekcja – wyciąganie wniosków.

Jeżeli zrobiliśmy jakąś część pracy, warto, żebyśmy się spotkali i zastanowili się co poszło nam dobrze, co nie tak i co możemy poprawić, żeby kolejny Sprint był wydajniejszy i lepszy. Jest to naprawdę mega ważne. Retrospekcja trochę przeraża ;) Widziałem kiedyś Retrospekcję, która miała agendę i trwała 1,5 godziny…. Powoduje to wtedy efekt „ranyyyy nie mamy na to czasu, działajmy dalej”.

Później zaczynamy cykl na nowo. Teraz już kilka rzeczy robi się jasnych, bo zbieramy feedback przez cały czas trwania naszego Sprintu. Pojawiają się nowe pomysły co do tego, co jeszcze można zrobić na naszej stronie internetowej. Product Owner pilnuje co z tego jest ważniejsze, a co nie, które pomysły zrealizujemy, a które nie. Pilnuje, abyśmy pracowali nad wartościowymi rzeczami.

Zespół uczy się coraz lepiej planować i dobierać ilość zadań do zrobienia w Sprincie. Zaczyna coraz lepiej rozumieć produkt, a Sprint Backlogi są coraz lepsze. Coraz lepiej się rozumiemy, ludzie sami przychodzą z pomysłami, które czasem są naprawdę dużo lepsze niż coś na co by wpadli ludzie z biznesu.

Siłą SCRUM`a jest powtarzalność i dyscyplina. Potrzebujemy się trzymać zasad, bo jak przestaniemy to wszystko się posypie.