Pracujemy według Scrum'a

4.1 Co to jest Scrum?

Już zrozumiałeś, że wszystko dotyczące programowania jest znormalizowane. A co, jeśli powiem Ci, że znormalizowane jest absolutnie wszystko? I nie mówię nawet o nazwach zmiennych i funkcji, chociaż one też są znormalizowane🤦‍♂️.

Jest metodologia programowania — nazywa się Agile i jej popularna realizacja — Scrum. Scrum nazywany jest też frameworkiem — określa wszystkie procesy w zespole. Kiedy powinny być spotkania, kto na nich powinien być obecny, co powinno być omawiane, jakie mają być rezultaty spotkań i w jakiej formie mają być zapisane.

"Ale po co tyle normalizacji", — zapytasz. No cóż, po pierwsze, pracujesz w zaawansowanym sektorze — high-tech i te sprawy. Po drugie, tak łatwiej jest ze sobą współpracować. A po trzecie, w nazwie Twojej profesji Python Fullstack Software Engineer zwróć uwagę na ostatnie słowo — inżynier. I zrozumiesz, skąd to się bierze.

4.2 Jak wygląda praca według Scrum

Scrum — to elastyczna metodologia zarządzania projektami, często stosowana w programowaniu. Oparta na iteracyjnych i przyrostowych procesach.

Scrum dzieli projekty na cykle rozwojowe, zwane sprintami, które zwykle trwają od jednego do czterech tygodni. Każdy sprint zaczyna się od planowania zadań, które muszą być wykonane, i kończy się prezentacją, na której zespół demonstruje osiągnięte wyniki.

Kluczowe elementy Scrum to role, wydarzenia i artefakty.

Główne role to Product Owner, który określa wymagania produktu, Scrum Master, wspierający proces zgodnie z zasadami Scrum, i zespół deweloperów, który wykonuje pracę.

Główne wydarzenia to codzienne spotkania (daily meetings lub daily stand-ups), planowanie sprintów, retrospekcje i demonstracje wyników pracy. Artefakty to backlog (lista zadań) produktu, backlog sprintu i przyrost produktu.

Nie bój się! Chociaż regulacja wszystkiego może wyglądać trochę przerażająco, praca "według Scrum'a" jest łatwa i przyjemna. Scrum rozwiązał podstawowy konflikt między deweloperami a klientami/właścicielami produktu.

Deweloperzy zawsze prosili, aby zostawić ich w spokoju i pozwolić spokojnie pracować. A właściciele produktu potrzebowali pilnie dodać nowe funkcje, coś zmienić, albo przeprowadzić jakiś eksperyment.

Scrum podzielił programowanie na stabilne okresy — sprinty (zwykle 2 tygodnie). W ciągu jednego okresu deweloperzy realizują tylko te zadania, które zostały zaplanowane na bieżący sprint. Jeśli klientowi trzeba coś pilnie zrobić, dodaje te funkcje do następnego sprintu.

4.3 Sprint & Scrum Board

Sprint — to podstawowy cykl rozwoju w Scrum, trwający od jednego do czterech tygodni. Jak już powiedzieliśmy, w tym okresie zespół pracuje nad wykonaniem konkretnego zbioru zadań z backlogu produktu.

Na początku każdego sprintu odbywa się planowanie, gdzie zespół wybiera zadania z backlogu produktu i zobowiązuje się je wykonać. Sprint kończy się demonstracją wykonanej pracy i retrospekcją, gdzie zespół analizuje proces pracy nad sprintem i szuka sposobów na ulepszenie kolejnego sprintu. To podejście pozwala regularnie aktualizować produkt, szybko reagując na zmiany wymagań i priorytetów.

W trakcie bieżącego sprintu deweloperzy i właściciel produktu powinni spotkać się na spotkaniu i omówić zadania na następny sprint.

Backlog, czy backlog — to lista wszystkich zadań, które muszą być wykonane. W Scrum rozróżniamy backlog produktu, który zawiera wszystkie wymagania produkty (funkcje), oraz backlog sprintu, który składa się z zadań, wybranych do realizacji w bieżącym sprincie. Backlog to żywy dokument, który jest regularnie aktualizowany i przeglądany w celu zapewnienia zgodności z aktualnymi celami biznesowymi i warunkami rynkowymi.

Backlog bieżącego sprintu lubią wyświetlać w postaci Scrum Board — jakiejś tablicy z zadaniami i statusami. Tablica jest podzielona na kolumny, które zwykle przedstawiają etapy wykonywania zadań, takie jak "Do zrobienia", "W trakcie", "Do sprawdzenia" i "Zrobione". To pozwala całemu zespołowi widzieć postęp i łatwo identyfikować wszelkie trudności w procesie pracy.