Skip to content

Scrum – pierwsze wrażenie

O Scrumie słyszałem już wcześniej, ale dotychczas nie miałem okazji pracować w zespole, który działa w Scrumie. Podczas kursu CodersLab miałem więc okazję zrobić mały projekt w oparciu o Scrum i Agile.

Zdaje sobie sprawę, że to była tylko mała część tego, co dzieje się w projektach scrumowych. Postanowiłem jednak opisać pierwsze wrażenie, a później być może rozwijać ten temat.

O czym we wpisie?

  1. Czym jest Scrum i Agile
  2. Założenia naszego projektu
  3. Wnioski

Czym jest Scrum i Agile?

Zacznę od Agile. To programowanie zwinne – agile software development. Najważniejszym założeniem jest to, że wymagania projektu i klienta zmieniają się podczas tworzenia projektu. Agile ma pomóc w sprostaniu tym wymogom, a także w organizacji pracy firmy tworzącej oprogramowanie. Poszczególne etapy tworzenia projektu zamknięte są w iteracjach. W każdej z nich odbywa się tworzenie i testowanie kodu, zbieranie wymagań oraz planowanie. Co istotne… w zespołach pracujących w metodyce agile bardzo ważna jest komunikacja między członkami zespołu. Później odniosę się do tego we wnioskach po zrealizowanym projekcie.

Podsumowując – realizacja zadań w agile wygląda następująco:

  • planowanie
  • projektowanie
  • programowanie
  • testowanie
  • implementacja
  • informacja zwrotna

Manifest Agile – najważniejszy dokument dotyczący metodyki zwraca uwagę na dostarczanie oprogramowania okresowo, postęp określa się poprzez oprogramowanie, a jeśli pojawią się zmiany, to nie mają złego wpływu na cały proces.

Ogólnie omówiłem Agile, czas przejść do Scruma. To wejście głębiej – działanie w ramach jakiegoś postępowania. Scrum może być realizowany w zgodzie z Agile. Systematyzuje metodykę i poszczególne jej etapy układa w jasną strukturę – Project Backlog, Sprint Backlog, Sprinty, Daily itp.

Założenia naszego projektu

Projekt ScrumLab w ramach CodersLab odbywał się w ciągu dwóch tygodni. Pracowaliśmy w zespołach czteroosobowych, a pieczę nad nami miał opiekun ze szkoły. Do zrealizowania mieliśmy stronę internetową, na której po zalogowaniu użytkownik mógł dodawać, wyświetlać przepisy, plany żywieniowe i konkretne dania.

Projekt był już opisany – zebrano wymagania, rozpisano nam poszczególne elementy Project Backlogu i Sprint Backlogu, a także określono ich poziom trudności w punktach. Całość kodu wisiała na GitHubie. Pierwsze zadania przydzielił nam opiekun, kolejne mieliśmy przyjmować według własnego uznania. Co istotne, pracowaliśmy zdalnie i w różnych godzinach.

Wnioski

To moja pierwsza styczność ze Scrumem i Agile. Dlatego na koniec projektu, spisałem sobie trochę uwag i wniosków, które moim zdaniem są istotne, aby taka forma pracy w zespole była zasadna. Na pewno, z niektórymi problemami nie spotkamy się w zespole pracującym stacjonarnie. Wiem też, że dołączając do jakiegoś zespołu w Scrumie, muszę przyjąć też ustalenia, jakie w nim panują. Zwłaszcza, gdy zespół pracuje sprawnie.

1. Organizacja pracy

Chyba najważniejsza rzecz, która u nas się rozjeżdżała. Nie mieliśmy ustalonych żadnych zasad wewnętrznych dotyczących organizacji pracy. Jak przyjmujemy zadania, kto testuje, kto robi merge na gicie, kiedy oddajemy kod. Właściwie to był dziki zachód i każdy działał według własnych możliwości. Prowadziło to jednak do różnych mniejszych problemów. Na przykład, wiszący i czekający kod do sprawdzenia lub przerwy w pracy, gdy ktoś był uzależniony od kodu innej osoby. Wydaje mi się, że kluczem tu jest określenie od początku zasad.

2. Brak lidera

Brakowało nam przez pewien czas kogoś, kto trzymałby porządek w kodzie i zespole. Osoby, która zwracałaby uwagę na niedociągnięcia, problemy, ale także wzięła na siebie ciężar pilnowania i kontroli nad pracą. W efekcie, odpowiedzialność poszczególnych osób bardzo się rozmyła.

3. Zrozumienie projektu

Na pierwszym spotkaniu przejrzeliśmy poszczególne elementy Project Backlogu, ale było to raczej omówienie ogólne tego, co ma się dziać na stronie. Zabrakło bardziej szczegółowego omówienia problemów, które mogą wyjść w trakcie pracy. Gdybyśmy bardziej szczegółowo omówili projekt, w trakcie pracy pojawiałoby się znacznie mniej pracy i pytań do rozwiązania.

4. Brak znajomości narzędzi

Gita dopiero się uczyliśmy, więc w projekcie tego nie odczuliśmy. Problemem mogło być pojawienie się Trello, tablicy kanban, punktów i przydzielania zadań. W związku z tym, że od długiego czasu sam korzystam z narzędzia do organizacji pracy (Asana), a Trello znam z innych projektów, nie sprawiło mi to problemu, ale w ramach organizacji pracy, powinno się wyjaśnić działanie i możliwości narzędzia. Przy okazji, warto także mieć ustalone, jak i kiedy się konsultujemy. My robiliśmy to na Slacku, w całkowicie różnych godzinach. Raz, konsultowaliśmy temat o 12, raz o 22.

Podsumowując

To dopiero pierwsza przymiarka do Scruma. To także wycinek tego, jak można wykorzystać taką formę pracy w zespole. Dla mnie było to niezwykle pouczające i intensywne wyzwanie i nawet pobieżnie, jestem w stanie bardzo docenić możliwości Scruma i metodyki Agile.

***

Wszystkie teksty poświęcone nauce programowania znajdziesz TUTAJ.

Published inDEV