Nadszedł ten dzień. Rozmawiasz z nową agencją internetową, która ma stworzyć Twój sklep i w trakcie rozmowy dowiadujesz się, że wykorzystują SCRUM. Przytakujesz, idziecie dalej, ale w głębi serca zastanawiasz się, co to dla Ciebie oznacza. Czy to przyspieszy, czy spowolni projekt? Jak to wpłynie na budżet? Co to znaczy dla jakości mojego sklepu? Poznaj SCRUM – jedną z najpopularniejszych metodyk wytwarzania oprogramowania!

SCRUM w kilku zdaniach

SCRUM jest niczym innym jak zbiorem zasad dotyczących prowadzenia projektu. Mówi nam – postępuj “tak”, żeby uzyskać dobre wyniki. Wydziela jasne role i etapy w projekcie, nie jest jednak systemem do zarządzania projektami. Dlaczego? Bo sam SCRUM nie skupia się na tym, żeby dowieźć projekt w terminie i budżecie, a raczej na tym, jak on zostanie dowieziony – jak będzie wyglądał sam proces. SCRUM określa nam, kto jest za co odpowiedzialny, jak wygląda komunikacja w projekcie, jak często są spotkania, kto w nich uczestniczy, a także zapewnia kilka przydatnych narzędzi, pozwalających osiągnąć cel – wytworzenie projektu. SCRUM należy też do tzw. metodyk “zwinnych” (Agile), czyli zezwalających, a nawet promujących wprowadzanie zmian w projekcie.

Podstawy podejścia SCRUM

Ta metodyka opiera się na trzech filarach:

Przejrzystość

Wszyscy członkowie zespołu muszą doskonale wiedzieć, jaki jest cel projektu. Wydaje się to oczywiste, ale w tradycyjnym zarządzaniu projektami IT, często programiści dostają zadania, takie, jak np. “stwórz popup dla newslettera”, ale nie widzą całości projektu, który tworzą – jest to poniekąd oderwane od rzeczywistości podejście, gdzie jedyną osobą, która ma w głowie obraz projektu, jest Project Manager. SCRUM wymusza dostęp do informacji dla całego zespołu – nie tylko poprzez dostęp do backlog’u (o tym później), ale też poprzez stały kontakt z osobą odpowiedzialną za projekt po stronie Klienta.

Dodatkowo – dzięki uwzględnieniu w spotkaniach Product Ownera (czyli tradycyjnie reprezentanta Klienta, odpowiedzialnego za projekt i będącego decydentem w kwestiach rozwoju projektu) – Klient ma też dostęp do prawdziwych postępów projektu, problemów, jakie się pojawiały, uwag zespołu co do rozwiązań technologicznych (a nawet biznesowych), a także do obaw / ryzyk z perspektywy zespołu. Usuwana jest bariera w postaci Project Managera, który może przefiltrować, albo zbyt dyplomatycznie opisać niektóre sytuacje.

Inspekcja

Drugim filarem jest Inspekcja, którą należy rozumieć, jako częsty dostęp do informacji o przebiegu projektu i wpływ na kwestie jakościowe (np. podczas tzw. spotkania Sprintowego programiści mogą zaproponować dwa różne wyjścia i to Product Owner wybierze, w jaki sposób chce, żeby dana rzecz została stworzona).

Innym przejawem Inspekcji, jest wprowadzenie tzw. “Definition of done”, czyli definicji ukończonego zadania. Może wydawać się to oczywiste i wręcz śmieszne, że ktoś chce “tracić” czas na analizowanie tego, jednak w praktyce jest to bardzo ważny element. Żeby podać przykład: Kiedy wg. Ciebie zadanie jest skończone? Kiedy jest na środowisku testowym, gotowe do testów? A może, kiedy potwierdzimy, że poprawnie działa na 5 największych przeglądarkach? A może, kiedy kod zostanie uzupełniony o automatyczne testy? A może, kiedy powstanie dokumentacja dla danej funkcji? Jak widzisz – nie jest to oczywiste i warto zdefiniować co Product Owner i zespoł rozumie jako “oddany produkt”.

Adaptacja

Jednym z głównych założeń SCRUMa jest fakt, że założenia projektu będą się zmieniały. Będzie to następowało w wielu różnych aspektach projektu – od sytuacji, w której w danym Sprincie będą wybierane inne zadania niż oczekiwane przez reprezentanta Klienta, poprzez doprecyzowanie zadań, które zmieni jego wycenę, aż po dodawanie nowych zadań, wynikających z rekomendacji i rozmów z zespołem programistów.

Załóżmy, że jednym z naszych zadań jest stworzenie popupa, który się pojawi na stronie głównej. Podczas rozmów z zespołem, może dość do dyskusji, czy ten popup na pewno zapewni nam cel, który próbujemy osiągnąć. Być może lepiej sprawdzi się popup exit-intent? A może w ogóle zrezygnujemy z popupu na rzecz górnej belki? Idea podejścia SCRUM zakłada, że w każdym momencie (nawet pod koniec projektu) zmiany są mile widziane i oczekiwane.

Jakie występują role w SCRUM?

W tradycyjnym podejściu można wyznaczyć 3 typy ról:

1. Scrum Master – jest to osoba odpowiedzialna za organizację pracy zespołu, upewnienie się, że to, co się dzieje, jest zgodne z metodyką, ale też za rozwiązanie blokerów w projekcie. Scrum Master jest niezależną od zespołu jednostką, której rola to doradzać i doglądać pracy Product Ownera i Zespołu.
2. Product Owner – to rola zewnętrzna, tj. zazwyczaj pełniona przez reprezentanta Klienta. Jest jedynym elementem “obcym”, aczkolwiek w tradycyjnym podejściu SCRUMowym “jedzie na jednym wozie”, tj. nie należy go traktować specjalnie – powinien mieć dostęp do pełnej wiedzy o postępach, ew. problemach w projekcie, czy nawet niezgodach panujących w zespole. Rola ta jest zazwyczaj pełniona przez Klienta, ale wymaga to od niego też dużego zaangażowania i nie każdy Klient jest gotowy podjąć się tej roli – dlatego czasami przejmuje ją Project Manager po stronie agencji, który ma reprezentować i komunikować potrzeby i cele Klienta. Nie jest to tradycyjny SCRUM, ale dosyć często spotyka się takie rozwiązanie.
3. Zespół – oznaczający wszystkie osoby potrzebne do realizacji projektu po stronie agencji – m.in. programistów, architektów, UX-owców, etc.

Jakie są etapy w podejściu SCRUM?

Musisz wiedzieć, że każda firma troszeczkę inaczej podchodzi do zasad tej metodyki i każda będzie wykorzystywała tylko wybrane elementy, albo dostosowywała je do tego, co sprawdza się w jej organizacji. W tradycyjnym podejściu SCRUMowym można wyróżnić następujące etapy:

1. Stworzenie backlogu produktu;
2. Spotkania planujące Sprinty;
3. Daily (codzienne spotkania zespołu);
4. Spotkania analizujące Sprinty;
5. Retrospektywa;

Zanim przejdziemy dalej, prawdopodobnie przydałoby się wyjaśnić, czym jest Sprint. Otóż jest to okres, zazwyczaj między 1–4 tygodniowy (najczęściej 2 tygodniowy), gdzie zespół realizuje wybrane zadania. Każdy Sprint powinien rozpoczynać się od zaplanowania zadań, a skończyć na analizie/podsumowaniu ostatnich tygodni prac.

Stworzenie backlogu produktu (rejestru wymagań)

Pierwszy z elementów jest też jednym z tych, które wymagają najwięcej czasu od Product Ownera – wymaga on stworzenia niekompletnej listy funkcji, które ma spełniać system. Dlaczego niekompletnej? Ponieważ SCRUM jest metodyką zwinną – zakłada, że nie da się stworzyć kompletnego backlogu, ponieważ będzie się on stale zmieniał w trakcie trwania projektu.

Warto też zaznaczyć, jak opisywane będą te funkcje systemu, ponieważ wszystkie powinny zostać utworzone, jako tzw. user-stories, czyli historyjki użytkowników. Przykładowo:

“Jako zalogowany użytkownik, chcę mieć możliwość sprawdzenia statusu moich historycznych zamówień w koncie Klienta.”

lub

“Jako administrator, chcę mieć możliwość zatwierdzenia dostępu dla wybranych użytkowników, zablokowania dostępu dla wybranych istniejących użytkowników, a także ustawienia domen, dla których użytkownicy [którzy pochodzą z danej domeny] będą automatycznie wpuszczani do systemu.”

Po tym, jak powstanie backlog – zespół estymuje wszystkie zadania, zadając jednocześnie Product Ownerowi setki pytań, a następnie Product Owner je priorytetyzuje.

SCRUM POKER

Skoro już jesteśmy przy estymacjach, to chciałem Wam opisać procedurę tzw. SCRUM POKERA, która wprowadza coś magicznego w codziennej pracy.

Każdy z programistów dostaje specjalne karty. Są one oznaczone zgodnie z ciągiem Fibonacciego (1, 2, 3, 5, 8, 13, 21…), występują też specjalne karty: Przerwa i DUŻE ZADANIE. Prowadzący odczytuje dane User-Story, zespół zadaje pytania, a następnie na raz-dwa-trzy, wszyscy rzucają na stół jedną kartę, która ocenia pracochłonność danego zadania wg tej osoby. Załóżmy, że w trzyosobowym zespole wypadnie 3, 3 i 8. Jeżeli wartości się nie zgadzają (albo drastycznie nie zgadzają) – członkowie zespołu omawiają, dlaczego twierdzą, że zajmie to 3, a inni – dlaczego, że zajmie to 8. Po omówieniu rzucają jeszcze raz kartami. I tak aż do momentu, kiedy wszyscy nie są zgodni. W przypadku kiedy pojawi się karta DUŻE ZADANIE, User-Story należy podzielić na mniejsze, ponieważ nie da się go wykonać w ramach jednego Sprintu. W przypadku Przerwy – zespół robi sobie przerwę na kawę, żeby odświeżyć umysł.

Jest to bardzo ciekawe podejście do wycen – gwarantujące świetne wyniki, niestety jest dosyć czasochłonne, dlatego częściej stosuje się metodę mini-maksową, która przy dużym zbiorze zadań gwarantuje dosyć dobry poziom bezpieczeństwa wyceny, przy znacznie mniejszym koszcie.

Spotkania planujące Sprinty

Jest to spotkanie, które poprzedza każdy ze Sprintów, gdzie zespół wybiera zadania, które planuje zrealizować w danym Sprincie. Nie tylko wybiera je ze względu na wcześniej wyestymowaną pracochłonność, ale też ze względu na dostępne zasoby zespołu (być może ktoś jest na urlopie, na chorobowym, etc.). To są zadania, które zespół deklaruje, że powinien skończyć w ciągu jednego Sprintu. To zespół wybiera zadania, które wg nich mają sens (np. stworzenie panelu administracyjnego, zanim powstanie front-endowa warstwa modułu), jednak wybiera je, bazując na priorytetyzacji wprowadzonej przez Product Ownera. Ważne jest to, że nie przypisuje się zadań do konkretnych osób w zespole, tylko do zespołu.

Daily (codzienne spotkanie zespołu)

W każdy dzień roboczy odbywa się bardzo krótkie spotkanie zespołu, w którym każdy z członków opowiada o tym, czym będzie się zajmował i czy są jakieś blokery, które wstrzymują jego pracę (albo, które będą wstrzymywały go w przyszłości). W tym spotkaniu może (ale nie musi) brać udziału Product Owner, zazwyczaj Klienci nie chcą deklarować się na codzienną telekonferencję z zespołem, jednak zdarzają się wyjątki. Ważne, żeby tzw. Daily miało stałe miejsce i czas, żeby każdy z członków zespołu wiedział kiedy, gdzie i po co się tam spotyka. Daily nie powinno zająć więcej niż 15 minut.

Spotkania analizujące Sprinty (Podsumowanie Sprintu)

Pod koniec każdego Sprintu organizuje się spotkanie podsumowujące, podczas którego omawia się, co udało się zrobić z zadań wybranych do Sprintu, jakie były problemy i jak je rozwiązano. Product Owner może też ocenić, jak wygląda postęp projektu oraz ew. wpływ zaakceptowanych zmian na budżet projektu (zgodnie z zasadą Inspekcji).

Retrospektywa

Jest to dodatkowe spotkanie, które zazwyczaj odbywa się między Podsumowaniem Sprintu, a Planowaniu Sprintu. Nie musi odbywać się co dwa tygodnie, w większości firm jest ono robione raz na miesiąc lub raz na kwartał. Ideą retrospektywy jest zidentyfikowanie procesów, które działają dobrze, a które źle. Wymyślenie, jak można zaadresować problemy i jak wzmocnić pozytywne aspekty pracy. Retrospektywa jest ważnym elementem dla motywacji i iteracyjnego poprawiania efektywności zespołu.

Wady i zalety podejścia SCRUM

Jak każda metodyka, SCRUM ma swoje wady i zalety. Obecnie jest bardzo chętnie stosowana przez agencje internetowe, ponieważ programiści chętniej aplikują do firm, które stosują SCRUM w swoich organizacjach. Dla zespołów oznacza to częste wysłuchiwanie ich potrzeb i ew. wprowadzanie rozwiązań, które pomagają zaadresować ich problemy. Co to jednak oznacza dla Klienta?

Zalety SCRUMa

1. Dostosowanie projektu pod Twoje oczekiwania – w trakcie wytwarzania projektu będziesz miał okazję zarówno zmieniać jego zakres, jak i konsultować dane rozwiązania z licznym zespołem, który zaproponuje Ci alternatywne rozwiązania;
2. Częsty dostęp do informacji o postępach projektu – w wersji minimum jest to raz na Sprint, w wersji maksimum codziennie podczas “Daily”. W przypadku większości sztywnych metodyk zarządzania projektami lista punktów kontrolnych jest zdecydowanie rzadsza, przez co istnieje ryzyko, że powstanie coś, co nie jest dla nas idealne;
3. Dużo informacji zwrotnych przekazywanych przez zespół podczas spotkań Sprintowych – dzięki SCRUMowi masz dostęp do informacji o potencjalnych ryzykach, ale też do opinii zespołu o zastosowanych rozwiązaniach. Czy wolisz dostać informację, że coś można zrobić lepiej od zewnętrznego zespołu, czy szefa?
4. Stałe usprawnianie procesu developmentu – dzięki retrospektywom i podsumowaniu Sprintów, można szybko wprowadzić zmiany, które spowodują większą efektywność zespołu. Czysto teoretycznie – każdy Sprint powinien być lepszy od ostatniego.

Wady SCRUMA

1. Zmienny budżet – biorąc pod uwagę, że mówimy o metodyce zwinnej, budżet będzie się zmieniać – może się zarówno rozszerzać, jak i kurczyć. Dużo zależy tutaj od Product Ownera, który będzie dyktować, jakie rozwiązanie przyjąć w niektórych przypadkach. W przypadku niedoświadczonej osoby, łatwo jednak zaakceptować wszystkie fajne funkcje i dodatkowe usprawnienia technologiczne proponowane przez zespół, nie kontrolując tym samym budżetu.
2. Dodatkowa praca dla Klienta – SCRUM wymaga dodatkowego zaangażowania Product Ownera – powinien być on dostępny, żeby odpowiedzieć na pytania zespołu, brać udział w spotkaniach, przygotować Backlog, etc. Żeby tego było mało, może się okazać, że SCRUM wymaga podwojenia części prac – np. stworzenia dodatkowego wykresu Gantt’a z przebiegiem projektu, dla nieSCRUMowego zarządu.
3. Codziennych spotkań – ten punkt dotyczy zarówno Klienta, jak i zespołu. Jeżeli chcemy być na każdym Daily, to jest to dodatkowe 15 minut w ciągu dnia, które musimy poświęcić na telekonferencję. Dla Klienta są to minuty, kiedy programista nie koduje (a trzeba za nie zapłacić), a dla programisty może być to strata czasu (bo powie dwa zdania w ciągu 15 minut, a resztę czasu uzna za stracony).

---

Czy polecałbym więc Wam SCRUMa? Dużo zależy od projektu, który realizujecie. SCRUM sprawdza się wspaniale, jeżeli chodzi o projekty takie jak budowa sklepu internetowego, ale nie polecałbym go w przypadku np. aplikacji bankowych (albo innych projektów, które powinny być poprzedzone bardzo dogłębną analizą i dokumentacją). Odpowiadając krótko – tak, raczej polecałbym go, uważam, że może przynieść więcej korzyści niż szkody dla projektu, wymaga jednak też (jak i każde inne podejście) dobrego Project Managera po stronie Klienta, który będzie nadzorował budżet, czas wdrożenia i rozumie, że więcej, nie znaczy lepiej. Jeżeli chcecie przeczytać SCRUM GUIDE po polsku, to zapraszam tutaj.