Scrum to framework procesowy, który zaczął powstawać ponad 30 lat temu. Jest jedną z technik zwinnych (agile’owych). Scrum został stworzony z myślą o tworzeniu i rozwijaniu produktów i spełnia zasady Manifestu Agile. Choć samą ideę Scruma łatwo zrozumieć, to trudno go zastosować w praktyce.
Dlaczego framework? Sami twórcy Scruma, nie chcieli, aby określać go mianem metody. Lepsze określenie uznali strukturę lub szkielet (framework) w ramach którego możemy wytwarzać wartościowe produkty poprzez zarządzanie procesami.
Czym jest Scrum?
Scrum powstał po to, by rozwiązywać złożone problemy, adaptować produkt do wymagań klienta. Scrum umożliwia wydajne i innowacyjne kreowanie produktu, o możliwie jak najwyższej jakości dla klienta. Właśnie tę formę pracy zespołów wybraliśmy dla Codecool. Uczestnicy naszego kursu programowania uczą się Scruma od praktycznej strony, dzięki czemu łatwo im potem wdrożyć się do pracy w nowej firmie IT, bo są przyzwyczajeni do pracy w Scrumie.
Zanim przejdziemy do tego, jak wygląda praca w Scrumie, przyglądnijmy się dawniejszym metodom prowadzenia projektów. Słyszeliście kiedyś o waterfallu? Waterfall czyli wodospad, to idea zainspirowana działaniem procesów w fabrykach, w których wszystko przechodzi z rąk do rąk. Waterfall w programowaniu wyglądałby tak: najpierw analityk rozmawia z klientem o jego potrzebach. Na podstawie ustaleń architekt projektuje architekturę programu, programiści piszą program, testerzy go testują, a na końcu wdrożeniowiec wdraża go u klienta. Brzmi świetnie? Tak, ale… to nie działa. Bo co, jeśli test źle pójdzie? Program musi wrócić do programistów, którzy rozłożą ręce, mówiąc “tak kazał nam architekt”. Takie przerzucanie się odpowiedzialnością oczywiście nie sprawdza się w biznesowych realiach. Dlatego też pojawił się pomysł, aby wymieszać ludzi, którzy stworzą zespół. A w jaki sposób pracują? Już wyjaśniamy!
Zobacz również: Podstawy modelowania systemów w języku UML
Metodyka Scrum
Tak naprawdę Scrum nie określa konkretnego sposobu postępowania, żeby osiągnąć cel i zbudować dobry produkt. Wyznacza nam sposób współpracy między ludźmi zaangażowanymi w projekt i określa wydarzenia, jakie muszą wystąpić, ale nie narzuca, jak ma być napisany program.
Kontrola procesu opiera się na trzech filarach:
- Inspekcja – jak jest teraz? Jak idzie nam osiąganie celów?
- Adaptacja – elastyczne i szybkie dostosowanie się do sytuacji
- Transparentność – wszyscy mają te same dane i dostęp do informacji
Aby możliwa była adaptacja, stosuje się następujące działania:
- Planowanie Sprintu (ang. Sprint Planning)
- Codzienny Scrum (ang. Daily Scrum)
- Przegląd Sprintu (ang. Sprint Review)
- Retrospektywa Sprintu (ang. Sprint Retrospective)
Dodatkową wiedzę, w tym oczywiście praktyczną umiejętność pracy w Scrumie, studenci zdobywają w trakcie naszego kursu programowania.
Przeczytaj również: Ile czasu trwa nauka programowania
Najważniejsze zasady Scrum
Wiecie już, że żeby mówić o pracy w Scrumie, musi zawierać on tak zwane czy ceremonie. Są to innymi słowy cykliczne wydarzenia, dzięki którym praca i komunikacja między wszystkimi osobami zaangażowanymi w projekt jest bardziej efektywna.
Czas realizacji projektu podzielony jest na sprinty. Sprint rozpoczyna się od planowania i może trwać od tygodnia do maksymalnie miesiąca. Po każdym sprincie zespół powinien dostarczyć działającą funkcjonalność programu.
Codziennie rano odbywa się trwający maksymalnie 15 minut standup, zwany też Daily Scrum. Za organizację oraz przebieg spotkania odpowiedzialny jest Scrum Master. Każdy z uczestników spotkania odpowiada na pytania: co zrobiłem wczoraj, jakie napotkałem problemy, co będę robił dzisiaj.
Na koniec sprintu powinno się odbyć spotkanie, na którym team sprawdza, co udało się osiągnąć w trakcie jego trwania. Jest to tak zwany przegląd sprintu. Bierze w nim udział cały zespół scrumowy: team developerów, Scrum Master i Product Owner. Przegląd sprintu pozwala na zrealizowanie dwóch fundamentalnych zasad Scruma: inspekcji i adaptacji.
Po przeglądzie sprintu organizowana jest retrospektywa, w trakcie której członkowie zespołu scrumowego odpowiadają sobie na pytania co poszło dobrze, a co poszło źle w minionym sprincie.
Zainteresuje Cię również: Studia a szkoła programowania: co wybrać?
Podział ról
Jak już wspomnieliśmy, Scrum powstał po to, by tworzyć i rozwijać produkty. W tym procesie bierze udział sporo osób, które przyjmują określone role.
Role w Scrum:
- Interesariusze (Stakeholders) – to oni określają potrzeby i oczekiwania względem produktu.
- Product owner, PO (właściciel produktu) – to jeden z interesariuszy, odpowiedzialny za rozwój produktu. Tworzy jego wizję i zarządza budżetem. Product owner powinien posiadać wiedzę biznesową na temat realiów rynkowych, a także samego produktu i jego użytkowników. Powinien być także osobą decyzyjną. Product owner nie jest programistą.
- Development team (zespół programistów) – Idea Scrum jest taka, by w zespole funkcjonował dobry przepływ informacji. Zespół nie może być więc zbyt liczny. Ile osób może liczyć team Scrumowy? Powinien być tak duży, aby wystarczyły na niego dwie duże pizze. Innymi słowy od 3 do 8 osób. Członkowie zespołu powinni przyjąć te same wartości, które pomogą im w realizacji wspólnego celu: zaangażowanie, odwagę, skupienie, otwartość i poszanowanie. W Scrumie określamy wszystkich mianem developerów, bez względu na specjalizację i aktualnie realizowane zadania. Zespół powinien sam się organizować i posiadać wszystkie umiejętności, potrzebne do zbudowania produktu.
- Scrum Master (Mistrz Scrum) -tak zwany “służalczy kierownik”. Powinien mieć doświadczenie w pracy w Scrumie. Jest mistrzem ceremonii, facilituje procesy, usuwa przeszkody, dba o to, by zespół programistów miał komfort pracy. Nie zarządza zespołem, ale procesem.
- Scrum Team (Zespół Scrum) – w jego skład wchodzą zespół deweloperski, Scrum Master i Product Owner.
Podsumowanie
Sami twórcy Scruma przyznają, że choć łatwo zrozumieć jego zasady, to ich wdrożenie w praktyce jest trudne i wymaga cierpliwości. Prawdopodobnie ciężko by było znaleźć firmę czy zespół, który modelowo, bez żadnych potknięć realizuje pracę w oparciu o framework Scrum. Warto jednak próbować i wdrażać dobre praktyki. Codzienne standupy, określone w czasie sprinty, retrospektywy i transparentna komunikacja to dobre kroki ku wydajniejszej pracy zespołów programistów.