Cały ten Scrum

Praca w IT to nie tylko programowanie, ale też cała masa dodatkowych narzędzi i procesów. Warto je poznać, by padające w pracy terminy nie były obce. Jako pierwszy na tapetę trafia więc Scrum. Co to takiego? O tym właśnie przeczytacie we wpisie.

Przebranżowienie to ważna decyzja, która wymaga nauczenia się wielu nowych rzeczy. Jeśli chcemy zacząć pracę na juniorskim stanowisku, musimy poznać nie tylko język, w którym mamy programować, ale także narzędzia i procesy obecne w projektach IT. Dzisiaj skupię się na Scrumie, który jest sposobem zarządzania procesem powstawania produktu. Zaczynamy!

Ten wpis jest początkiem nowego cyklu, w którym chcę przybliżać bardziej okołoprogramistyczne wątki. W skrócie – nie takie, które bezpośrednio dotyczą kodowania, ale takie, które są obecne w pracy programisty. Cykl nie ma jeszcze nazwy, bo jakoś nie mogę znaleźć czegoś wpadającego w ucho. Na razie roboczo kategoria nazywa się Nie tylko programowanie. Jeśli macie fajne propozycje – dajcie znać w komentarzach. A teraz wróćmy do Scruma 🙂

Dlaczego w ogóle piszę o Scrumie? Otóż jest to nieodłączne narzędzie pracy w zespołach programistycznych, które właściwie organizuje pracę i narzuca jej pewien kanon, o którym zaraz napiszę więcej. Do zrozumienia Scruma trzeba najpierw wiedzieć, czym jest Agile. Otóż Agile Software Development to tzw. programowanie zwinne, jednak w większości przypadków nazwy tej nie tłumaczy się na polski. Stąd też w artykule będę posługiwać się terminami Scrum i Agile, bo ta polska zwinność jakoś średnio mi pasuje. Od razu zaznaczam, że nie jestem specjalistą od zarządzania projektami. Chcę po prostu przedstawić, jak ja rozumiem cały proces i powiedzieć w skrócie o takich jego elementach, z którymi ja, jako junior, spotykam się na co dzień. Na początku bowiem bardzo trudno było mi zrozumieć, czym są te wszystkie sprint planningi czy standupy i co właściwie w projekcie robi Scrum Master. Uważam, że dobrze jest o tym poczytać nawet jeśli dopiero jesteśmy na początku nauki programowania, bo prędzej czy później te sposoby tworzenia produktów w IT gdzieś się pojawią. I wtedy już będziemy o Scrumie mniej więcej coś wiedzieć.

Wspomniany wcześniej Agile to, podając za definicją Wikipedii:

Grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu. Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania.

Tłumacząc dla osób, które wcześniej się z tym nie spotkały – w metodach typu waterfall tworzymy cały projekt od początku do końca, natomiast w metodach typu Agile dzielimy proces na małe części. W pierwszym przypadku dajemy klientowi końcowy projekt, natomiast w drugim, pokazujemy efekty poszczególnych etapów. Dzięki temu klient może wprowadzać poprawki w trakcie, projekt jest bardziej dopasowany do jego potrzeb i proces jest bardziej przejrzysty, zarówno dla klienta, jak i dla zespołu deweloperskiego. Jeśli chcecie zapoznać się bliżej z założeniami Agile, odsyłam Was do Agile Manifesto.

A gdzie w tym wszystkim jest Scrum? Odpowiedź jest prosta – wszędzie. Scrum bowiem jest to tzw. framwork procesu Agile, co znaczy mniej więcej tyle, że Scrum jest wykorzystaniem metodologii Agile w praktyce. Scrum jest więc jedną z metodyk Agile. Scrum dzieli proces powstawania produktu np. aplikacji na tzw. iteracje, czyli sprinty. Jeden sprint trwa zazwyczaj około dwóch tygodni i jego celem jest dostarczenie określonych funkcjonalności. Dla przykładu – celem sprintu może być na przykład zrobienie layoutu aplikacji oraz zaimplementowanie rejestracji, logowania i wylogowywania użytkownika. Cele sprintu zależne są od projektu. Każdy sprint powinien dostarczać kolejne, działające wersje produktu. Chodzi o to, by za każdym razem na końcu sprintu można było pokazać jakąś część aplikacji, która dobrze działa, jest przetestowana i stanowi część końcowego produktu.

W procesie scrumowym mamy trzy główne role. Są to: Product Owner, Scrum Master oraz zespół deweloperski. Product Owner jest osobą, która wie, jak ma wyglądać końcowy produkt, jakie dokładnie ma mieć funkcjonalności. To on podejmuje decyzje, gdy zespół waha się co do sposobu działania albo implementacji jakiejś funkcjonalności. To do niego idziemy z pytaniami typu “gdzie powinien zostać przekierowany użytkownik po zalogowaniu”. Scrum Master z kolei czuwa nad procesem powstawania produktu, to on prowadzi codzienne spotkania, podczas których zespół omawia, na jakim jest etapie tworzenia projektu. On także prowadzi tzw. planningi, sprawdza, czy wszystko idzie zgodnie z planem, interweniuje w razie potrzeby. Co robi zespół, nie muszę raczej tłumaczyć. Zespół deweloperski bowiem tworzy produkt, ale też w specjalnym procesie, o którym w kolejnym akapicie.

Ideą metodologii Agile jest podział procesu powstawania produktu na mniejsze części. W Scrumie dzielimy więc cały proces na mniejsze przebiegi. W trakcie sprintu do zrealizowania są konkretne funkcjonalności, czyli tzw. user stories. User story to może być na przykład logowanie do aplikacji, możliwość usunięcia przedmiotu z listy itp. User story dzielone są na mniejsze zadania, czyli taski. Jedno takie zadanie nie powinno zajmować więcej niż jeden dzień. Podczas sprint planningu zespół dzieli poszczegółne user stories na zadania oraz estymuje, ile czasu zajmie ich wykonanie. Potem deweloperzy pracują nad konkretnymi zadaniami. Codziennie odbywa się daily scrum meeting, czyli tzw. standup, podczas którego każdy mówi, nad czym pracuje, jakie ma problemy, czym zajmie się w następnej kolejności. Są to krótkie, 15 minutowe spotkania.

Po zakończeniu sprintu odbywa się demo, może być to demo z klientem albo po prostu wewnątrz zespołu. Prezentowane są wtedy funkcjonalności dostarczone w danym sprincie. Demo jest częścią sprint review. Sprint review oraz retro, które następuje po nim, pozwalają zespołowi określić obszary poprawy albo do zachowania, jeśli się sprawdziły. W trakcie sprint review można też dodać nowe zadania do projektu, jeśli zespół uznaje, że będzie to konieczne do dalszego rozwoju aplikacji. A potem jest kolejny sprint planning, kolejne user stories, kolejne taski… I tak dopóki produkt nie zostanie skończony.

Mam nadzieję, że w miarę przybliżyłam Wam ten proces. Oczywiście jest on o wiele bardziej złożony i pojawia się w nim jeszcze wiele terminów. Nie chciałam jednak opisać tutaj całej ideologii, ale po prostu te aspekty, z którymi spotykm się na co dzień w mojej pracy. Muszę przyznać, że praca w ten sposób jest naprawdę fajna. Skupianie się tylko na jednej konkretnej funkcjonalności ma dużo plusów. Jeśli chcecie o Scrumie poczytać więcej, odsyłam Was do tej strony. Znajdziecie tam kompendium wiedzy na temat tej metodyki. A gdy macie tylko chwilkę – obejrzycie film Scrum in under 5 minutes.

Chcesz być na bieżąco? Polub fanpage Wake up and Code i dołącz do grupy Programuj, dziewczyno!