Pracujemy według Scrum’a

1. Czym jest Scrum?

To, że wszystko, co dotyczy developmentu, jest już standaryzowane, pewnie już rozumiesz. A co, jeśli powiem Ci, że wszystko jest w ogóle standaryzowane? I nie chodzi tu nawet o nazywanie zmiennych i funkcji, choć i to jest standaryzowane🤦‍♂️.

Istnieje metodologia developmentu — nazywa się Agile i jej popularna implementacja — Scrum. Scrum to też często nazywany framework — on określa wszystkie procesy w zespole. Kiedy mają być spotkania, kto na nich musi być, co ma być omawiane, jakie wyniki spotkań mają być i w jakiej formie mają być zapisane 📋.

"Po co tyle standaryzacji", — zapytasz. No, po pierwsze, pracujesz w high-tech — wszystko musi być nowoczesne. Po drugie, wtedy łatwiej się z sobą dogadać. A po trzecie, w nazwie Twojego zawodu jest .NET Software Engineer — zwróć uwagę na ostatnie słowo — inżynier. I od razu zrozumiesz, skąd to się bierze.

2. Jak wygląda praca według Scrum

Scrum — to elastyczna metodologia zarządzania projektami, często używana w tworzeniu oprogramowania. Opiera się na iteracyjnych i inkrementalnych procesach 🔁

Scrum dzieli projekty na cykle/etapy rozwoju, nazywane sprintami, które zwykle trwają od dwóch do czterech tygodni. Każdy sprint zaczyna się od planowania zadań, które mają być wykonane, a kończy prezentacją, podczas której zespół pokazuje osiągnięte wyniki 🎯.

Kluczowe elementy Scrum to role, wydarzenia i artefakty.

• Podstawowe role — to Product Owner, który ustala wymagania do produktu, Scrum Master, wspierający proces zgodnie z zasadami Scrum, oraz zespół deweloperski, wykonujący pracę.
• Podstawowe wydarzenia — to codzienne spotkania (daily meetings albo daily stand-ups), planowanie sprintów, retrospektywy i prezentacje wyników pracy.
• Artefakty obejmują backlog (listę zadań) produktu, backlog sprintu i inkrement produktu 📋.

Nie bój się! Chociaż regulowanie wszystkiego i wszystkich wygląda trochę strasznie, praca "według Scruma" jest łatwa i przyjemna. Scrum rozwiązał główny konflikt między deweloperami a klientami/właścicielami produktu 🤗

Deweloperzy zawsze prosili, żeby zostawić ich w spokoju i dać im spokojnie pracować. A właściciele produktu musieli szybko dodawać nowe funkcje, coś zmieniać albo przeprowadzać eksperymenty 🧪.

Scrum podzielił development na stabilne okresy — sprinty (zwykle 2 tygodnie). W trakcie jednego okresu deweloperzy robią tylko te zadania, które były zaplanowane na dany sprint. Jeśli klient potrzebuje czegoś pilnie, dodaje te funkcje do następnego sprintu 🗓️.

3. Sprint & Scrum Board

Sprint — to główny cykl rozwoju w Scrum, trwający od jednej do czterech tygodni. Jak już mówiliśmy, w tym czasie zespół pracuje nad konkretnym zestawem zadań z backlog produktu.

Na początku każdego sprintu odbywa się planowanie ⏳, podczas którego zespół wybiera zadania z backlog produktu i zobowiązuje się je wykonać. Sprint kończy się prezentacją wykonanej pracy i retrospektywą, podczas której zespół analizuje proces pracy nad sprintem i szuka sposobów na ulepszenie kolejnego. Taki sposób pozwala na regularne aktualizacje produktu, szybkie reagowanie na zmiany wymagań i priorytetów.

Przez cały sprint deweloperzy i właściciel produktu powinni spotkać się na spotkaniu i omówić zadania na kolejny sprint.

Backlog 📚, czyli backlog, to lista wszystkich zadań do wykonania. W Scrum rozróżnia się backlog produktu, który zawiera wszystkie wymagania do produktu (feature’y), i backlog sprintu, czyli zadania wybrane do realizacji w danym sprincie. Backlog to żywy dokument, który jest regularnie aktualizowany i przeglądany, aby odpowiadać bieżącym celom biznesowym i warunkom rynkowym.

Backlog aktualnego sprintu często wyświetla się na Scrum Board ✅ — to taka tablica z zadaniami i statusami. Tablica jest podzielona na kolumny, które zwykle pokazują etapy realizacji zadań, takie jak "Do zrobienia", "W trakcie", "Na sprawdzeniu" i "Zrobione". To pozwala całemu zespołowi widzieć postęp i łatwo zidentyfikować wszelkie trudności w procesie pracy.