Scrum Team – role i obowiązki

Praca w scrumie to dla osoby związanej z branżą IT chleb powszedni – planowanie, codzienne spotkania, iteracyjne działania w sprintach itd. Wszystko to wygląda książkowo, gdy o tym opowiadamy. Czasem warto jednak swoją praktykę zestawić z teorią. Wyniki takiego porównania mogą być w przypadku pracy w scrumie bardzo zróżnicowane.

Kilka słów o scrumie

Zgodnie z definicją, scrum jest frameworkiem, z wykorzystaniem którego możemy rozwiązywać złożone problemy. Jego równoległym założeniem jest produktywne i kreatywne dostarczanie produktów o możliwie najwyższej wartości. Pracując zgodnie z ramami postępowania, jakie nakłada na nas scrum, jesteśmy w stanie ciągle ulepszać nasz produkt, zespół oraz środowisko, w którym się znajdujemy.

Niewątpliwą zaletą scruma jest jego „bycie na czasie”. Cały proces jest dokładnie opisany, a także systematycznie rozwijany, co pozwala nadążać za zmieniającym się w błyskawicznym tempie rynkiem IT. We wspomnianym opisie znajdziemy informacje na temat tego, jak powinna być zorganizowana praca zespołu projektowego.

Scrum jest oparty na empirycznym sposobie kontroli procesu. Co to oznacza? Wiedza pochodzi z posiadanego doświadczenia, a decyzje podejmowane są na podstawie tego, co wiemy. W podejściu empirycznym nie potrafimy dokładnie przewidzieć wyników wykonania pracy w momencie jej podejmowania. Chcemy kontrolować uzyskane wyniki i zarazem utrzymywać wysoką jakość.

3 filary scruma

Poszczególne kroki w procesie nie zawsze są powtarzalne. Aby podtrzymać zasady empirycznego podejścia do kontroli procesu, w scrumie zostały wprowadzone 3 filary:

• inspekcja,
• adaptacja,
• przejrzystość.

Inspekcja

Jej założenie jest proste – w trakcie sprintu sprawdzaj swoją pracę regularnie. Pozwoli to odpowiednio wcześnie wykryć ewentualne niepożądane odchylenia. Nie należy jednak czynić tego zbyt często, aby owo sprawdzanie nie stawało na przeszkodzie w realizacji celów sprintu. Inspekcje są najbardziej efektywne wtedy, gdy rzetelnie wykonują je odpowiednio wykwalifikowane do tego osoby.

Adaptacja

Jeśli podczas inspekcji zostaną dostrzeżone czynniki, które w realny sposób przekraczają akceptowalne limity i mogą spowodować brak osiągnięcia założonego celu, należy w odpowiedni sposób dostosować trwający proces. Dostosowanie powinno być wykonane tak szybko, jak to możliwe.

Scrum zaleca cztery formalne wydarzenia do inspekcji i adaptacji:

• sprint planning,
• daily scrum,
• sprint review,
• sprint retrospective.

Przejrzystość

Założeniami tego filaru są jednakowe rozumienie zagadnień przez wszystkie strony oraz jednakowe rozumienie „definicji zakończonej pracy”. Spełnienie obu postulatów pozwoli nam uniknąć nieporozumień i sytuacji, w których zainteresowane strony w procesie będą dochodziły swoich racji na podstawie własnych interpretacji wymagań.

Scrum team

Zespół scrum składa się z:

• Product Ownera,
• Development Teamu,
• Scrum Mastera.

Zespoły Scrum są niezależne i wielofunkcyjne. Samoorganizujące się zespoły wybierają, w jaki sposób najlepiej wykonać swoją pracę – nie są przy tym kierowane przez osoby spoza zespołu. Wielofunkcyjność oznacza, że członkowie zespołu mają wszystkie kompetencje potrzebne do wykonania pracy – bez uzależnienia od innych osób, które nie są częścią zespołu. Zastosowany w scrum model zespołu ma na celu optymalizację elastyczności, kreatywności i produktywności.

Product Owner

Właściciel produktu jest odpowiedzialny za maksymalizację wartości produktu będącego efektem pracy zespołu deweloperskiego. Sposób osiągnięcia tego celu może różnic się dla poszczególnych organizacji, zespołów scrumowych oraz jednostek.

Jest to rola jednoosobowa. Może reprezentować zdanie wielu osób w rejestrze produktu (product backlog), jednak jakakolwiek zmiana (np. priorytetu) elementów rejestru produktu musi być zaakceptowana przez Product Ownera (w rezultacie Product Owner jest rozliczany ze swojej pracy jako pojedyncza jednostka).

Aby Product Owner pracował efektywnie, jego decyzje muszą być respektowane wewnątrz organizacji, dla której pracuje. Decyzje te są widoczne w zawartości oraz kolejności elementów product backlogu.

Rejestr prowadzony przez właściciela produktu jest jedynym źródłem wymagań dla zespołu developerskiego. W zarządzaniu rejestrem produktu są zawarte:

• jasno sprecyzowane elementy rejestru produktu,
• uporządkowane elementy z rejestru produktu, by w jak najlepszy sposób osiągać potencjalne cele wyznaczane dla zespołu deweloperskiego,
• optymalizacja wartości pracy wykonywanej przez zespół deweloperski.

Ponadto, product backlog powinien pokazywać faktyczną informację na temat aktualnych prac Development Teamu (oraz ich stanu). Właściciel produktu powinien dbać o to, by elementy zawarte w rejestrze produktu były zdefiniowane w sposób przejrzysty, ułatwiający pełne zrozumienie ich treści przez zespół developerski.

Development Team

Zespół developerski składa się z profesjonalistów realizujących zadania z zakresu sprintu. Jego celem jest dostarczenie potencjalnie gotowego do wydania przyrostu skończonego produktu na koniec każdego ze sprintów. Tylko członkowie Development Teamu biorą udział w tworzeniu nowej wersji produktu (zwanej także przyrostem od angielskiego słowa increment).

Uczestnicy zespołów deweloperskich są dobierani przez organizację, dla której pracują. Wyselekcjonowane grupy specjalistów dostają od swych organizacji zielone światło do zarządzania swoją pracą we własnym zakresie. Uzyskana w takim modelu pracy „synergia” ma w założeniu optymalizować ogólną efektywność i wydajność zespołu developerskiego.

Zespół developerski jest odpowiedzialny za wytworzenie ukończonego, potencjalnie gotowego do wydania produktu na zakończenie każdego sprintu. Podczas planowania prac zespół sam decyduje o liczbie elementów możliwych do realizacji w danym sprincie oraz o planie na wykonanie wyselekcjonowanych zadań.

Niezależnie od kompetencji posiadanych przez poszczególnych członków Development Teamu nie powinno być w nim widocznych wewnętrznych podziałów (wynikłych np. ze stanowiska czy też innych czynników). Podczas przeglądu prac zespół jest rozliczany jako całość bez wyszczególniania dokonań pojedynczych jednostek.

Zgodnie z założeniami scruma rozmiar zespołu developerskiego powinien się zamknąć w przedziale od 3 do 9 osób. Zbyt duże zespoły wymagają zbyt dużej koordynacji i generują zbyt dużą złożoność dla całego procesu organizacji pracy. Zbyt małe zespoły powodują obniżenie wewnętrznych interakcji między członkami oraz są narażone na potencjalne luki w umiejętnościach niezbędnych do osiągnięcia celu sprintu.

Scrum Master

Jest odpowiedzialny za wspieranie członków scrum teamu w odpowiedniej implementacji scruma (zgodnie z definicją w Scrum Guide). Scrum Master pomaga członkom zespołu scrumowego zrozumieć teorię i praktykę scruma uwzględniając jego zasady i wartości.

Dba o prawidłowy przebieg i zrozumienie procesu wytwórczego zgodnie z ramami postępowania nakreślonymi przez scrum. Jest tzw. servant-leaderem dla członków zespołu – służy im wiedzą i umiejętnościami z zakresu scruma, jednocześnie będąc liderem w kwestii przestrzegania i stosowania jego zasad oraz wartości. Ponadto, Scrum Master dba o to, aby osoby spoza scrum teamu nie wpływały w żaden sposób na pracę wykonywaną przez zespół (w szczególności taką, która może mieć wpływ na wydajność poszczególnych członków zespołu i w rezultacie doprowadzić do narażenia osiągnięcia celu sprintu).

Obowiązki Scrum Mastera

Do obowiązków Scrum Mastera należą:

Wobec Development Teamu:

• dzielenie się wiedzą w zakresie jego samoorganizacji oraz wielofunkcyjności,
• usuwanie przeszkód,
• ułatwienie przeprowadzania wydarzeń scrumowych, by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu,
• udzielanie rad w kwestiach współpracy środowiska okołoprojektowego z zespołem.

Wobec Product Ownera:

• pomoc w zarządzaniu rejestrem produktu (np. przez wynajdywanie i sugerowanie efektywnych technik zarządzania),
• wyjaśnianie potrzeby jasnego i przejrzystego product backlogu,
• dbanie o jednolite rozumienie zagadnień przez wszystkie strony procesu wytwórczego,
• ułatwienie przeprowadzania wydarzeń scrumowych, by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu.

Wobec organizacji:

• pomoc dla organizacji w kwestiach jej adaptacji do scruma,
• planowanie sposobu implementacji scruma w organizacji,
• zrozumienie i zarządzanie scrumem oraz empirycznym procesem rozwoju produktu,
• zwiększanie produktywności scrum teamu,
• współpraca z innymi Scrum Masterami.

Podsumowanie

Scrum w swoich założeniach jest lekki i łatwy do zrozumienia. Jego prawidłowa implementacja jest jednak bardzo trudna do wykonania. Czy po zapoznaniu się z powyższymi informacjami możecie nadal z całą pewnością powiedzieć, że na co dzień pracujecie w jedynym i prawdziwym scrumie?

***

Więcej artykułów przygotowanych przez naszych ekspertów z obszaru agile znajdziesz w kategorii Zarządzanie projektami.