Historia
Założenia metodyki SCRUM zostały po raz pierwszy opisane w 1986 roku w czasopiśmie Harward Bussines Review, w artykule autorstwa Hirotaka Takeuchi i Ikujiro Nonaka pod tytułem „The New New Product Development Game”. Przedstawione w nim wyniki badań nowego produktu w obserwowanych w trakcie jego wdrażania firmach: Canon, Honda, Fuit-Xerox, Brother,3M, Epson, HP, Xero.
Eeasel Corporation to firma, w której w 1993 roku powstał pierwszy zespół SCRUM, którego doświadczenia przedstawiono w artykule „Agile Development: Lessons Learned from the First Scrum” Kena Schwebera.
Teoria metodyki SCRUM
Bazą SCRUM jest empiryczna teoria sterowania procesem. Wspomniany empiryzm zakłada, że wiedza pochodzi z doświadczenia na podstawie którego są podejmowane decyzje. Istotne są także wyniki wykonania pracy, które na początku projektu nie są do końca zdefiniowane. Aby podtrzymać zasady empirycznej kontroli procesu w SCRUM opracowane zostały trzy filary:
- Inspekcja – częsta kontrola postępu prac, aby w odpowiednim momencie możliwe było wyłapanie możliwości ulepszenia lub potencjalnych błędów na jak najwcześniejszym etapie. Kontrola ta powinna być przeprowadzana przez wykwalifikowanego specjalistę w danej dziedzinie
- Adaptacja – w przypadku wykrycia nieprawidłowości we wcześniejszym filarze (przekroczenie akceptowalnych limitów, utrudnienia w osiągnięciu celu) pojawia się adaptacja, czyli dostosowanie obecnego projektu.
Pomocne w Inspekcji i Adaptacji są: Sprint planning, Daily Scrum, Sprint review, Sprint retrospective
- Przejrzystość – jednakowe rozumienie zagadnień oraz pojęcia „zakończenia pracy” przez wszystkich uczestników, czyli osób odpowiedzialnych za wyniki
Zespół SCRUM
Każdy zespół SCRUM charakteryzuje się autonomią i wielofunkcjonalnością. Poszczególne osoby posiadają indywidualne umiejętności, dzięki czemu zespół posiada wszystkie niezbędne kompetencje do wykonania powierzonego mu projektu. Pozwala to na brak kontroli przez osoby spoza zespołu, co ma przełożenie na lepszą elastyczność, kreatywność i produktywność zespołu.
W zespole SCRUM można wyróżnić kilka głównych stanowisk:
- Właściciela projektu (Projekt Owner) – jest to osoba odpowiedzialna za maksymalizację wartości danego produktu, który stanowi efekt pracy całego zespołu. Właściciel kontroluje każdy etap powstawania produktu, kontroluje czy postawione przez klienta oczekiwania zostają spełnione czy też należy coś w produkcie poprawić. Koordynacja pracy zespołu także należy do odpowiedzialności właściciela projektu. Jest to stanowisko jednoosobowe, którego zadaniem jest także reprezentowanie zdania członków zespołu w rejestrze produktu (product backing). Dokonywanie zmian w założeniach projektu, poszczególnych elementach, priorytecie musi być akceptowane także przez niego. Właściciel projektu jest rozliczany ze swojej pracy jako pojedyncza jednostka.
- Zespół odpowiedzialny za rozwój (Development Team) – jest to zespół składający się ze specjalistów z różnych dziedzin. Odpowiedni dobór członków pozwala na pokrycie wszystkich aspektów potrzebnych do stworzenia konkretnego produktu. Zapewniając tym samym synergię, optymalizację wydajności i efektywności. Realizacja poszczególnych zadań odbywa się w sprintach, których celem jest realizacja poszczególnych celów krótkotrwałych, które w konsekwencji zbliżają do otrzymania końcowego produktu. Zespół sam ustala wyniki końcowe, jakie muszą zostać osiągnięte w poszczególnych etapach prac (sprintach). Odpowiedzialnością zespołu jest wypracowanie finalnego wyniku jakim jest produkt. Dlatego ważne jest, aby nie było w nim podziałów, problemów, wyłamów wpływających na opóźnienie, zmniejszenie wydajności pracy. Zespół jest rozliczany jako całość, bez podziału na poszczególnych profesjonalistów.
Wielkość zespołu powinna wynosić od 3 do 9 osób. Większa ilość osób wpływa na obniżenie koordynacji prac i przepływu informacji miedzy członkami. Mniejsza ilość osób w zespole może wiązać się m.in. z niewystarczającą ilością umiejętności do osiągnięcia celu, czy obniżoną wewnętrzną interakcją.
- Mistrz SCRUM (Scrum Master) – odpowiada za wyjaśnienie w jasny i klarowny sposób zastosowanej metodyki SCRUM w konkretnym projekcie danym członkom zespołu. Dba także, aby w prawidłowy sposób przebiegał proces wytwórczy zgodnie z zasadami nakreślonymi przez SCRUM. Służy swoją wiedzą i umiejętnościami z zakresu SCRUM, jako lider przestrzegający jego zasad i wartości. Mistrz kontroluje, aby osoby spoza zespołu nie wpływały na pracę wykonywaną przez zespół. Co w konsekwencji mogłoby wpłynąć na jego wydajność, opóźnienie lub brak osiągnięcia celu w danym sprincie.
Mistrz SCRUM posiada obowiązki wobec Zespołu odpowiedzialnego za rozwój, są to:
-
-
-
- Usuwanie przeszkód
- Doradzanie w kwestiach współpracy w zespole
- Ułatwianie pracy zespołowi, aby osiąganie celów było optymalne czasowo i zadaniowo
- Dzielenie się swoim doświadczeniem w zakresie samoorganizacji raz wielofunkcyjności
-
-
Obowiązki Mistrza wobec Właściciela projektu są następujące:
-
-
-
- Dbałość o równe zrozumienie zagadnień przez wszystkie jednostki w procesie wytwórczym
- Ułatwienie przeprowadzenie wydarzeń scrumowych, aby ich egzekucja nie wpływała na marnowanie czasu oraz wydajność zespołu
- Pomoc w zarządzaniu rejestrem produktowym
- Wyjaśnienie przejrzystości i jasności w product backlogu
-
-
Mistrz SCRUM posiada także obowiązki wobec danej organizacji:
-
-
-
- Doraźna współpraca z innymi Mistrzami SCRUM
- Planowanie implementacji SCRUM w organizacji
- Pomoc organizacji związaną z adaptacją do zasad SCRUM
- Zwiększanie produktywności zespołu odpowiedzialnego za rozwój
- Zarządzanie SCRUMEM
- Rozwój empiryczny danego produktu
-
-
Postępowanie w metodzie SCRUM
Pierwszym często traktowanym jako opcjonalny etapem prac w metodzie SCRUM jest określenie:
1.Rejestru produktowego
2.Rejestru zadaniowego
Jednak jest on związany z minimalizacją wkładu pracy, zakresu projektu w dalszych fazach. W tym etapie Właściciel Projektu na podstawie wizji klienta określa cechy danego produktu – jego funkcjonalność, znaki szczególne. Mogą one w miarę rozwoju oczywiście ulec zmianie, zostać zaktualizowane, jednak ważne jest określenie na początku zarysu.
Zarządzanie produktem charakteryzuje się: jasno sprecyzowanymi elementami rejestru, optymalizacją wartości pracy wykonywana przez zespół, uporządkowaniem elementów dla jak najlepszego osiągnięcia potencjalnych celów wyznaczonych dla zespołu deweloperskiego.
Kolejnym krokiem po ustaleniu rejestru produktu jest rejestr zadaniowy, w którym Właściciel określa priorytet konkretnych działań. Zespół na tym etapie może zgłaszać swoje uwagi czy pytania, które pomogą w lepszej organizacji prac.
Kolejnym etapem jest Sprint, czyli przeważnie 30 dniowy odcinek czasu, w którym następuje realizacja celów zapisanych w rejestrach. Podczas trwania sprintu nie może następować żadna zmiana w ustaleniach. Zespół ponosi odpowiedzialność w zakresie organizacji codziennego rytmu pracy. Efekty prac są przedstawiane Właścicielowi projektu oraz Mistrzowi podczas spotkań.
Podczas sprintu praktykowany jest Codzienny SCRUM (Daily Scrum), czyli krótkie spotkanie każdego dnia, na którym Mistrz zadaje trzy pytania do Zespołu:
- Co zrobiłeś dla realizacji celu Sprintu
- Co zrobisz dla realizacji celu Sprintu?
- Jakie napotkałeś przeszkody w celu osiągnięcia celu?
Takie codzienne spotkanie pomagają w lepszej organizacji pracy, korekcie pewnych założeń.
Każdy sprint kończy się Przeglądem Sprintu (Sprint Review), którego celem jest omówienie funkcjonalności oraz cech danego produktu, przebieg prac. Etap ten jest zakończony stworzeniem protokołu z podsumowaniem.
Ostatnim etapem jest Retrospektywa Sprintu (Sprint Retrospective) odbywająca się po każdym Sprincie. Członkowie zespołu omawiają podczas spotkanie wszystkie kwestie dotyczące danego produktu, sposobu organizacji pracy. Retrospektywa kończy się wyciągnięciem wniosków, które mogą posłużyć do ulepszenia oraz usprawnienia działań w kolejnych sprintach.
Wprowadzenie założeń SCRUM do organizacji niesie ze sobą bardzo wymierne korzyści dla firmy, jednak nie jest to łatwe zadanie. Wymaga ono samodyscypliny, przeorganizowania pracy pracowników oraz zmiany ich podejścia do zadań.
—
Bibliografia: